powered by simpleCommunicator - 2.0.18     © 2024 Programmizd 02
Map
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / СУБД для пересчета больших витрин
25 сообщений из 39, страница 1 из 2
СУБД для пересчета больших витрин
    #39904216
p_vadik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет!

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

Подозреваю, что есть более эффективные инструменты для таких задач.
Прошу подсказать варианты.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904232
p_vadik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сам по себе пересчет представляет тривиальную операцию сложения текущего значения и дельты.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904245
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а сейчас в чём проблема?
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904262
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p_vadikЕсть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей.
Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость
постоянно пересчитывать историю за большой период.

Вообще-то витрины на 2 миллиарда записей это что-то странное. Может, стоит гранулярность
уменьшить до требуемой отчётами?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904434
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p_vadik
Всем привет!

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

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


А погуглить?!
Вроде бы сейчас предложена куча способов решения проблемы.
Например, начиная от Hadoop, заканчивая лямбда-архитектурой.
:-)
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904486
p_vadik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бумбараш
а сейчас в чём проблема?


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

Dimitry Sibiryakov

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

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


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

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

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

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


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


Читаю конечно, но опыт форумчан также интересен)
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904759
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p_vadik


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


ИМХО лучше самому попробовать сделать proof of concept и посмотреть подходит или нет под вашу задачу.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904986
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p_vadik
Всем привет!

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

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


У меня было абсолютно то же самое, прям один в один, в том числе и субд, только объем до 12 млрд строк - все отлично работало. Пересчитывал в цикле по 1 секции во внерабочее время. Не каждый день, раз в месяц примерно.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39904989
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На секцию в 200 млн со сжатием до 100 млн уходило где-то минут 20, хотя конечно тут все зависит от ширины вашей таблицы и от оборудования. Ну и от алгоритма пересчета конечно - у меня все это считалось отдельно, в конце вешался колоночный индекс, а потом секция переключалась в основную таблицу.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905259
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p_vadik,

Ентерпрайзы под такие задачи используют хадуп, майкрософт тоже туда клонит. В мсскл 2019 идет хадуп в комлекте, видимо самое разумное смотреть на хадуп из мсскл
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905337
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хадуп считать быстрее ms sql не будет на одинаковых ресурсах

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

Я бы смотрел на архитектуру текущего ETL. Может быть просто у текущей конфигурации слабые ресурсы. Может быть ETL криво сделан. Еще непонятна, какая нужна оптимизация. Грузится один день, а нужно, чтобы грузилось два часа. Или грузится один день, а нужно, чтобы грузилось 10 минут.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905514
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бумбараш
хадуп считать быстрее ms sql не будет на одинаковых ресурсах.

Будет, за счет много большей параллелизации, более примитивной структуры файлика (parquet). Опять же колумн сторидж. Даже в виде one node cluster будет быстрее, на оракле проверял
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905603
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хадуп он вообще не про скорость, в книжке по хадупу написано в первом предложении

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

колумн сторадж на загрузку не особо влияет, если на 1-3%, то хорошо. тестировал его. К тому же в мсскуль свой колумн сторадж и не факт, что хуже
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905715
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бумбараш
хадуп он вообще не про скорость, в книжке по хадупу написано в первом предложении

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

Бумбараш

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

на стареньком i7 и one node cluster я загрузил 480 Гб текстовых файликов от теста tpc-ds в паркет за 2 часа, сколько уйдет загрузить 480 гб csv в mssql таблички ? что-то мне подсказывает на десктопе и за 12 часов шансов мало уложится, а размер датафайлов далеко за ТБ перевалят.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905795
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1
а размер датафайлов далеко за ТБ перевалят.

с чего бы это? наоборот, в columnstore займет меньше (в разы, а то и на порядок) чем исходный csv.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905929
bluestreak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Каким образом отчётность прикручена к витринам? Это случайно не business objects?
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39905941
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906053
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1
тесты показывали в разы не займет.


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



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


если они не нужны, то зачем?
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906059
bluestreak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLex
H5N1
тесты показывали в разы не займет.


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


Это зависит от того что в CSV.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906066
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bluestreak
msLex
пропущено...


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


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

Безусловно.
Порядки компрессии на наших реальных данных я уже приводил.
Кстати, они совпадают с тем, что указанно в статье, ссылку на которую дал H5N1.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906244
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
H5N1
тесты показывали в разы не займет.

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

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

msLex

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


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

мсскл не массивно параллельная субд, без secondary индексов он просто будет тошнить годами выкачивая фуллсканом и nested loop всю базу силами пары тредов.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906268
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1
я тут столько майкрософт гайз повидал с их тестами блокировочник vs версионник. тоже как один втирали что у них все по другому.

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


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


Все, что вы написали - полнейший бред.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906397
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 Гб
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906401
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик

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

так ты же тогда схитрил и тестировал на рам диске.
scale factor 100 уже 92.3 GB в колумнсторе занимают, scale factor 500 явно поболее займет :)
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906412
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1,

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

Про scale factor я не понял, что ты зотел сказать.
Для того пример по ссылке сжатие - более 4 раз, мне встречались данные, которые сжимались как х10.
...
Рейтинг: 0 / 0
25 сообщений из 39, страница 1 из 2
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / СУБД для пересчета больших витрин
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (1): Анонимы (1)
Читали форум (2): Анонимы (2)
Пользователи онлайн (9): Анонимы (7), Yandex Bot 6 мин., Bing Bot 9 мин.
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]