Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 СУБД для пересчета больших витрин  [new]
p_vadik
Member

Откуда:
Сообщений: 26
Всем привет!

СУБД MS SQL 2016.
Есть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей.
Из-за запросов с группировкой и экономии места, на таблицах колоночные индексы.
Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость постоянно пересчитывать историю за большой период.

Подозреваю, что есть более эффективные инструменты для таких задач.
Прошу подсказать варианты.
17 дек 19, 17:00    [22042355]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
p_vadik
Member

Откуда:
Сообщений: 26
Сам по себе пересчет представляет тривиальную операцию сложения текущего значения и дельты.
17 дек 19, 17:18    [22042376]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3062
а сейчас в чём проблема?
17 дек 19, 17:30    [22042395]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

p_vadik
Есть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей.
Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость
постоянно пересчитывать историю за большой период.

Вообще-то витрины на 2 миллиарда записей это что-то странное. Может, стоит гранулярность
уменьшить до требуемой отчётами?..

Posted via ActualForum NNTP Server 1.5

17 дек 19, 17:50    [22042421]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
p_vadik
Всем привет!

СУБД MS SQL 2016.
Есть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей.
Из-за запросов с группировкой и экономии места, на таблицах колоночные индексы.
Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость постоянно пересчитывать историю за большой период.

Подозреваю, что есть более эффективные инструменты для таких задач.
Прошу подсказать варианты.


А погуглить?!
Вроде бы сейчас предложена куча способов решения проблемы.
Например, начиная от Hadoop, заканчивая лямбда-архитектурой.
:-)
18 дек 19, 05:54    [22042691]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
p_vadik
Member

Откуда:
Сообщений: 26
Бумбараш
а сейчас в чём проблема?


Проблема в неприемлемой продолжительности операции пересчета. Нужно значительно ускорить, в разы.
Можно конечно по мелочи оптимизировать, но значительного прогресса думаю не будет.
Поэтому и решил спросить у знатоков о других технологиях, которые используются для решения подобных задач.

Dimitry Sibiryakov

p_vadik
Есть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей.
Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость
постоянно пересчитывать историю за большой период.

Вообще-то витрины на 2 миллиарда записей это что-то странное. Может, стоит гранулярность
уменьшить до требуемой отчётами?..


Чтобы покрыть основную массу отчетов, как раз и были сделаны агрегатные таблицы.
Но и эти витрины нужны, так как возникают масса разнообразных кейсов при анализе данных.

mad_nazgul
p_vadik
Всем привет!

СУБД MS SQL 2016.
Есть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей.
Из-за запросов с группировкой и экономии места, на таблицах колоночные индексы.
Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость постоянно пересчитывать историю за большой период.

Подозреваю, что есть более эффективные инструменты для таких задач.
Прошу подсказать варианты.


А погуглить?!
Вроде бы сейчас предложена куча способов решения проблемы.
Например, начиная от Hadoop, заканчивая лямбда-архитектурой.
:-)


Читаю конечно, но опыт форумчан также интересен)
18 дек 19, 09:40    [22042764]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
p_vadik


Читаю конечно, но опыт форумчан также интересен)


ИМХО лучше самому попробовать сделать proof of concept и посмотреть подходит или нет под вашу задачу.
18 дек 19, 13:52    [22043134]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35847
Блог
p_vadik
Всем привет!

СУБД MS SQL 2016.
Есть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей.
Из-за запросов с группировкой и экономии места, на таблицах колоночные индексы.
Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость постоянно пересчитывать историю за большой период.

Подозреваю, что есть более эффективные инструменты для таких задач.
Прошу подсказать варианты.


У меня было абсолютно то же самое, прям один в один, в том числе и субд, только объем до 12 млрд строк - все отлично работало. Пересчитывал в цикле по 1 секции во внерабочее время. Не каждый день, раз в месяц примерно.
18 дек 19, 18:09    [22043483]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35847
Блог
На секцию в 200 млн со сжатием до 100 млн уходило где-то минут 20, хотя конечно тут все зависит от ширины вашей таблицы и от оборудования. Ну и от алгоритма пересчета конечно - у меня все это считалось отдельно, в конце вешался колоночный индекс, а потом секция переключалась в основную таблицу.

Сообщение было отредактировано: 18 дек 19, 18:14
18 дек 19, 18:14    [22043486]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 589
p_vadik,

Ентерпрайзы под такие задачи используют хадуп, майкрософт тоже туда клонит. В мсскл 2019 идет хадуп в комлекте, видимо самое разумное смотреть на хадуп из мсскл
19 дек 19, 10:09    [22043914]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3062
хадуп считать быстрее ms sql не будет на одинаковых ресурсах

можно mpp посмотреть, тот же greenplum. Но тут опять вопрос про ресурсы. Если сейчас вычислительные ресурсы нищие, то и другая система на таких ресурсах далеко не улетит.

Я бы смотрел на архитектуру текущего ETL. Может быть просто у текущей конфигурации слабые ресурсы. Может быть ETL криво сделан. Еще непонятна, какая нужна оптимизация. Грузится один день, а нужно, чтобы грузилось два часа. Или грузится один день, а нужно, чтобы грузилось 10 минут.
19 дек 19, 11:36    [22044021]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 589
Бумбараш
хадуп считать быстрее ms sql не будет на одинаковых ресурсах.

Будет, за счет много большей параллелизации, более примитивной структуры файлика (parquet). Опять же колумн сторидж. Даже в виде one node cluster будет быстрее, на оракле проверял

Сообщение было отредактировано: 19 дек 19, 13:39
19 дек 19, 13:37    [22044280]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3062
хадуп он вообще не про скорость, в книжке по хадупу написано в первом предложении

для параллелизиации нужно докуя машин, что уже видимо предполагает увеличение ресурсов

колумн сторадж на загрузку не особо влияет, если на 1-3%, то хорошо. тестировал его. К тому же в мсскуль свой колумн сторадж и не факт, что хуже
19 дек 19, 15:06    [22044398]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 589
Бумбараш
хадуп он вообще не про скорость, в книжке по хадупу написано в первом предложении

хадуп про массовую параллельность, из которой растет и скорость в том числе. даже на машинке с 8 vcpu всякие спарки и мап-редюсы поднимут многие десятки если сотни параллельных тредов и будут как минимум пытаться писать параллельно.
на ETL задачках даже one node cluster даст фору мсскл в разы. из-за параллельности и много меньшей писанины.

Бумбараш

колумн сторадж на загрузку не особо влияет, если на 1-3%, то хорошо. тестировал его. К тому же в мсскуль свой колумн сторадж и не факт, что хуже

на стареньком i7 и one node cluster я загрузил 480 Гб текстовых файликов от теста tpc-ds в паркет за 2 часа, сколько уйдет загрузить 480 гб csv в mssql таблички ? что-то мне подсказывает на десктопе и за 12 часов шансов мало уложится, а размер датафайлов далеко за ТБ перевалят.
19 дек 19, 16:50    [22044543]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
msLex
Member

Откуда:
Сообщений: 9541
H5N1
а размер датафайлов далеко за ТБ перевалят.

с чего бы это? наоборот, в columnstore займет меньше (в разы, а то и на порядок) чем исходный csv.
19 дек 19, 20:13    [22044691]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
bluestreak
Member

Откуда:
Сообщений: 108
Каким образом отчётность прикручена к витринам? Это случайно не business objects?
20 дек 19, 08:59    [22044919]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 589
msLex
H5N1
а размер датафайлов далеко за ТБ перевалят.

с чего бы это? наоборот, в columnstore займет меньше (в разы, а то и на порядок) чем исходный csv.


тесты показывали в разы не займет. плюс колумнстор в мсскл не отменяет secondary индексы
https://15721.courses.cs.cmu.edu/spring2017/papers/09-olapindexes/p1177-larson.pdf

автор
Four queries against a TPC-DS [10] database at scale factor 100 are included.
A TPC-DS database at scale factor 100 is intended to require about 100GB for the base tables. For SQL Server the space
requirements were 92.3 GB for data, 15.3GB for secondary (row store) indexes and 36.6GB for column store indexes covering all
columns on every table.

scale factor 100 это чуть меньше 100 Gb, т.е. base tables заняли примерно столько же сколько csv файлики. у меня scale factor 500 был, csv заняли 480Gb

Сообщение было отредактировано: 20 дек 19, 09:50
20 дек 19, 09:41    [22044945]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
msLex
Member

Откуда:
Сообщений: 9541
H5N1
тесты показывали в разы не займет.


А наши тесты показывают, что займет



H5N1
плюс колумнстор в мсскл не отменяет secondary индексы


если они не нужны, то зачем?
20 дек 19, 12:15    [22045085]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
bluestreak
Member

Откуда:
Сообщений: 108
msLex
H5N1
тесты показывали в разы не займет.


А наши тесты показывают, что займет


Это зависит от того что в CSV.
20 дек 19, 12:20    [22045092]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
msLex
Member

Откуда:
Сообщений: 9541
bluestreak
msLex
пропущено...


А наши тесты показывают, что займет


Это зависит от того что в CSV.

Безусловно.
Порядки компрессии на наших реальных данных я уже приводил.
Кстати, они совпадают с тем, что указанно в статье, ссылку на которую дал H5N1.

К сообщению приложен файл. Размер - 28Kb


Сообщение было отредактировано: 20 дек 19, 12:30
20 дек 19, 12:30    [22045107]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 589
msLex
H5N1
тесты показывали в разы не займет.

А наши тесты показывают, что займет

я тут столько майкрософт гайз повидал с их тестами блокировочник vs версионник. тоже как один втирали что у них все по другому.

msLex

H5N1
плюс колумнстор в мсскл не отменяет secondary индексы


если они не нужны, то зачем?

мсскл не массивно параллельная субд, без secondary индексов он просто будет тошнить годами выкачивая фуллсканом и nested loop всю базу силами пары тредов.
20 дек 19, 16:42    [22045412]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
msLex
Member

Откуда:
Сообщений: 9541
H5N1
я тут столько майкрософт гайз повидал с их тестами блокировочник vs версионник. тоже как один втирали что у них все по другому.

Причем здесь "майкрософт гайз", я говорю про наши тесты, на наших данных


H5N1
мсскл не массивно параллельная субд, без secondary индексов он просто будет тошнить годами выкачивая фуллсканом и nested loop всю базу силами пары тредов.


Все, что вы написали - полнейший бред.
20 дек 19, 17:14    [22045447]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35847
Блог
H5N1
Бумбараш
хадуп он вообще не про скорость, в книжке по хадупу написано в первом предложении

хадуп про массовую параллельность, из которой растет и скорость в том числе. даже на машинке с 8 vcpu всякие спарки и мап-редюсы поднимут многие десятки если сотни параллельных тредов и будут как минимум пытаться писать параллельно.
на ETL задачках даже one node cluster даст фору мсскл в разы. из-за параллельности и много меньшей писанины.

Бумбараш

колумн сторадж на загрузку не особо влияет, если на 1-3%, то хорошо. тестировал его. К тому же в мсскуль свой колумн сторадж и не факт, что хуже

на стареньком i7 и one node cluster я загрузил 480 Гб текстовых файликов от теста tpc-ds в паркет за 2 часа, сколько уйдет загрузить 480 гб csv в mssql таблички ? что-то мне подсказывает на десктопе и за 12 часов шансов мало уложится, а размер датафайлов далеко за ТБ перевалят.


2 часа где-то с колоночным сжатием, вот тестировали как-то 19771498
в приемнике данные будут весить ориентировочно 50-100 Гб
20 дек 19, 21:59    [22045691]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 589
Критик

2 часа где-то с колоночным сжатием, вот тестировали как-то 19771498
в приемнике данные будут весить ориентировочно 50-100 Гб

так ты же тогда схитрил и тестировал на рам диске.
scale factor 100 уже 92.3 GB в колумнсторе занимают, scale factor 500 явно поболее займет :)
20 дек 19, 22:24    [22045700]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35847
Блог
H5N1,

Ну естественно "схитрил", ибо иначе все в обычный потребительский HDD упиралось.
То есть платформ не особо важна, если железо создает узкие места.

Про scale factor я не понял, что ты зотел сказать.
Для того пример по ссылке сжатие - более 4 раз, мне встречались данные, которые сжимались как х10.

Сообщение было отредактировано: 20 дек 19, 23:44
20 дек 19, 23:41    [22045723]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить