p_vadik,

Ентерпрайзы под такие задачи используют хадуп, майкрософт тоже туда клонит. В мсскл 2019 идет хадуп в комлекте, видимо самое разумное смотреть на хадуп из мсскл

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

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


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

тесты показывали в разы не займет. плюс колумнстор в мсскл не отменяет 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

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


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

так ты же тогда схитрил и тестировал на рам диске.
scale factor 100 уже 92.3 GB в колумнсторе занимают, scale factor 500 явно поболее займет :)

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



я же дал ссылку на статью и даже процитировал
автор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 это в пять раз больший датасет, он потребует от мсскл без малого терабайт записать.

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


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


а у майкрософта есть свежее продукт ? что изменилось в формате хранения с версии 2012 ?

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

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

нет. Инмон предлагает сырые данные и источников интегрировать на хадупе в единый application pond, т.е. в единую аля реляционную модель. потом от туда уже генерить витрины. мы тоже примерно к этому пришли.

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

[sarcasm off]
в хадупе как раз проще гарантировать атомарность и соответственно консистентность. много проще. а вот у майкрософт. особенно майкрсофт, на блокировочном RC можно вычитать неконсистентную кашу.