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

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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 5688
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

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


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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

хадуп про массовую параллельность, из которой растет и скорость в том числе. даже на машинке с 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

Откуда:
Сообщений: 9014
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.! из "Сравнения субд"
Сообщений: 515
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

Откуда:
Сообщений: 9014
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

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


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


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

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

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


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

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

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

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

msLex

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


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

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

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

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


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


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

Откуда: Москва / Калуга
Сообщений: 35143
Блог
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.! из "Сравнения субд"
Сообщений: 515
Критик

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

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

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

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

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

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

Откуда: Москва / Калуга
Сообщений: 35143
Блог
-повтор-

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

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

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

важна. именно платформа определяет какого размера данные будут записаны и нужны ли платформе еще мульон индексов, что бы хоть как-то потом этими данными ворочить.

Критик

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


я же дал ссылку на статью и даже процитировал
автор
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 - нифигна мсскл упаковать не смог. 92.3 GB + 15.3GB + 36.6GB. т.е. в мсскл пришлось записать много больше чем весили сырые csv. scale factor 500 это в пять раз больший датасет, он потребует от мсскл без малого терабайт записать.
21 дек 19, 00:18    [22045744]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

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

8.6 Гб по ссылке выше в загруженном виде весили 6.5 Гб (это вообще без сжатия), с колоночным сжатием - до 2 Гб, есть еще архивное колоночное сжатие - там я его не тестировал, но оно сжимает еще сильнее.

И странно, почему ты индексы тянешь в обсуждение? Они легко могут раздуть требуемое место в десять-двадцать раз.

Собственно, даже в твоем примере видно, что сжатие - х3, ибо "36.6GB for column store indexes covering all columns" это и есть вся сжатая таблица. Только эти "хитрецы" строили некластерный колоночный индекс, то есть фактически это было дублирование данных.

Ps я понял, твоя статья касается SQL Server 2012
это довольно странно, обсуждать продукт почти десятилетней давности, сравнивая его с современными, например, тот случай, где ты что-то грузил
21 дек 19, 01:11    [22045750]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

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

И странно, почему ты индексы тянешь в обсуждение? Они легко могут раздуть требуемое место в десять-двадцать раз.

потому что в реальном проекте мсскл потребует раздуть место и облепить индексами таблицы на 2-3 млрд

Критик

Собственно, даже в твоем примере видно, что сжатие - х3, ибо "36.6GB for column store indexes covering all columns" это и есть вся сжатая таблица. Только эти "хитрецы" строили некластерный колоночный индекс, то есть фактически это было дублирование данных.

ок, тогда я их не понял. решил, что 92.3 GB это колумнстор.

Критик

Ps я понял, твоя статья касается SQL Server 2012
это довольно странно, обсуждать продукт почти десятилетней давности, сравнивая его с современными, например, тот случай, где ты что-то грузил

а у майкрософта есть свежее продукт ? что изменилось в формате хранения с версии 2012 ?
21 дек 19, 11:15    [22045826]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

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

Изменений куча, хотя бы то, что колоночный кластерный индекс с тех пор стал поддерживать редактирование, все же в 2012 это была первая версия с кучей ограничений.

Ну и если требовать наличие индексов в ms sql, то и в другой системе нужно сравнивать с имеющимися индексами. Иначе получается какая-то профанация. Или у тебя без индексов миллиардные таблицы ворочаются? Особенно, если нужно выбрать сотню записей из миллиарда? (на одинаковом железе)
22 дек 19, 04:58    [22046169]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

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

Ну и если требовать наличие индексов в ms sql, то и в другой системе нужно сравнивать с имеющимися индексами. Иначе получается какая-то профанация. Или у тебя без индексов миллиардные таблицы ворочаются? Особенно, если нужно выбрать сотню записей из миллиарда? (на одинаковом железе)

да, на хадупах миллиардные таблицы ворочаются без каких-либо индексов, в том числе и у меня.
на хадупах случаются задачи где нужно какие-нить агрегаты/kpi на нагруженном сайтике показать, вот тогда можно в какой-нить solar индекс записать. но в аналитке хадупы без индексов справляются.
22 дек 19, 10:43    [22046206]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

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

За счет чего?
Полное сканирование? Или все же распараллеливание по нодам?
24 дек 19, 14:19    [22047765]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

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

За счет чего?


за счет отсутствия FK, за счет отсутствия tempdb где мсскл строит хеши для джоина и сортирует, за счет отсутствия transaction лога, за счет денормализации, за счет много, много большей параллельности.
распараллеливание по нодам это уже следующий этап.
24 дек 19, 21:53    [22048063]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
H5N1,

Таки ЧАЛ был прав - матмодель это лишнее звено?
25 дек 19, 11:20    [22048289]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

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

Таки ЧАЛ был прав - матмодель это лишнее звено?

нет. Инмон предлагает сырые данные и источников интегрировать на хадупе в единый application pond, т.е. в единую аля реляционную модель. потом от туда уже генерить витрины. мы тоже примерно к этому пришли.
25 дек 19, 13:11    [22048398]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

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

За счет чего?


за счет отсутствия FK, за счет отсутствия tempdb где мсскл строит хеши для джоина и сортирует, за счет отсутствия transaction лога, за счет денормализации, за счет много, много большей параллельности.
распараллеливание по нодам это уже следующий этап.


Все это реализуется и в реляционной субд, ну разве что кроме отсутствия tempdb для mssql. А отсутствие лога - довольно спорное решение, будет весьма трудно говорить заказчику что-то вроде "получилась конечно фигня, но ведь быстро же" )
25 дек 19, 17:17    [22048628]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
Критик
Member

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

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

Откуда: планета орков, г.Зверополис
Сообщений: 1350
p_vadik
Всем привет!

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

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

DDL надо (для представления о размерах)
и ещё не помешал бы пример - что должно получиться в итоге (после расчётов)
25 дек 19, 19:46    [22048769]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для пересчета больших витрин  [new]
H5N1
Member

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

Все это реализуется и в реляционной субд, ну разве что кроме отсутствия tempdb для mssql. А отсутствие лога - довольно спорное решение, будет весьма трудно говорить заказчику что-то вроде "получилась конечно фигня, но ведь быстро же" )


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

[sarcasm off]
в хадупе как раз проще гарантировать атомарность и соответственно консистентность. много проще. а вот у майкрософт. особенно майкрсофт, на блокировочном RC можно вычитать неконсистентную кашу.
25 дек 19, 20:36    [22048821]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Сравнение СУБД Ответить