|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
-повтор- ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2019, 23:44 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
Критик Ну естественно "схитрил", ибо иначе все в обычный потребительский 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.12.2019, 00:18 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
H5N1, 8.6 Гб по ссылке выше в загруженном виде весили 6.5 Гб (это вообще без сжатия), с колоночным сжатием - до 2 Гб, есть еще архивное колоночное сжатие - там я его не тестировал, но оно сжимает еще сильнее. И странно, почему ты индексы тянешь в обсуждение? Они легко могут раздуть требуемое место в десять-двадцать раз. Собственно, даже в твоем примере видно, что сжатие - х3, ибо "36.6GB for column store indexes covering all columns" это и есть вся сжатая таблица. Только эти "хитрецы" строили некластерный колоночный индекс, то есть фактически это было дублирование данных. Ps я понял, твоя статья касается SQL Server 2012 это довольно странно, обсуждать продукт почти десятилетней давности, сравнивая его с современными, например, тот случай, где ты что-то грузил ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2019, 01:11 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
Критик И странно, почему ты индексы тянешь в обсуждение? Они легко могут раздуть требуемое место в десять-двадцать раз. потому что в реальном проекте мсскл потребует раздуть место и облепить индексами таблицы на 2-3 млрд Критик Собственно, даже в твоем примере видно, что сжатие - х3, ибо "36.6GB for column store indexes covering all columns" это и есть вся сжатая таблица. Только эти "хитрецы" строили некластерный колоночный индекс, то есть фактически это было дублирование данных. ок, тогда я их не понял. решил, что 92.3 GB это колумнстор. Критик Ps я понял, твоя статья касается SQL Server 2012 это довольно странно, обсуждать продукт почти десятилетней давности, сравнивая его с современными, например, тот случай, где ты что-то грузил а у майкрософта есть свежее продукт ? что изменилось в формате хранения с версии 2012 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2019, 11:15 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
H5N1, Изменений куча, хотя бы то, что колоночный кластерный индекс с тех пор стал поддерживать редактирование, все же в 2012 это была первая версия с кучей ограничений. Ну и если требовать наличие индексов в ms sql, то и в другой системе нужно сравнивать с имеющимися индексами. Иначе получается какая-то профанация. Или у тебя без индексов миллиардные таблицы ворочаются? Особенно, если нужно выбрать сотню записей из миллиарда? (на одинаковом железе) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2019, 04:58 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
Критик Ну и если требовать наличие индексов в ms sql, то и в другой системе нужно сравнивать с имеющимися индексами. Иначе получается какая-то профанация. Или у тебя без индексов миллиардные таблицы ворочаются? Особенно, если нужно выбрать сотню записей из миллиарда? (на одинаковом железе) да, на хадупах миллиардные таблицы ворочаются без каких-либо индексов, в том числе и у меня. на хадупах случаются задачи где нужно какие-нить агрегаты/kpi на нагруженном сайтике показать, вот тогда можно в какой-нить solar индекс записать. но в аналитке хадупы без индексов справляются. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2019, 10:43 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
H5N1, За счет чего? Полное сканирование? Или все же распараллеливание по нодам? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2019, 14:19 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
Критик За счет чего? за счет отсутствия FK, за счет отсутствия tempdb где мсскл строит хеши для джоина и сортирует, за счет отсутствия transaction лога, за счет денормализации, за счет много, много большей параллельности. распараллеливание по нодам это уже следующий этап. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2019, 21:53 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
H5N1, Таки ЧАЛ был прав - матмодель это лишнее звено? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2019, 11:20 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
SergSuper Таки ЧАЛ был прав - матмодель это лишнее звено? нет. Инмон предлагает сырые данные и источников интегрировать на хадупе в единый application pond, т.е. в единую аля реляционную модель. потом от туда уже генерить витрины. мы тоже примерно к этому пришли. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2019, 13:11 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
H5N1 Критик За счет чего? за счет отсутствия FK, за счет отсутствия tempdb где мсскл строит хеши для джоина и сортирует, за счет отсутствия transaction лога, за счет денормализации, за счет много, много большей параллельности. распараллеливание по нодам это уже следующий этап. Все это реализуется и в реляционной субд, ну разве что кроме отсутствия tempdb для mssql. А отсутствие лога - довольно спорное решение, будет весьма трудно говорить заказчику что-то вроде "получилась конечно фигня, но ведь быстро же" ) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2019, 17:17 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
- ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2019, 17:17 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
p_vadik Всем привет! СУБД MS SQL 2016. Есть несколько витрин по 2-4 млрд. записей + несколько агрегатных таблиц по ~1 млрд. записей. Из-за запросов с группировкой и экономии места, на таблицах колоночные индексы. Исторические данные на которых строятся витрины изменяются, поэтому есть необходимость постоянно пересчитывать историю за большой период. Подозреваю, что есть более эффективные инструменты для таких задач. Прошу подсказать варианты. DDL надо (для представления о размерах) и ещё не помешал бы пример - что должно получиться в итоге (после расчётов) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2019, 19:46 |
|
СУБД для пересчета больших витрин
|
|||
---|---|---|---|
#18+
Критик Все это реализуется и в реляционной субд, ну разве что кроме отсутствия tempdb для mssql. А отсутствие лога - довольно спорное решение, будет весьма трудно говорить заказчику что-то вроде "получилась конечно фигня, но ведь быстро же" ) черт, точно. ты открыл мне глаза. все же можно и на мсскл ! вот всегда подозревал, что майкрософт - сплошная индюшатина. все можно на мсскл, а они хадуп в ядро мсскл затолкали. ну ведь точно по незнанию, белых спецов же не осталось. [sarcasm off] в хадупе как раз проще гарантировать атомарность и соответственно консистентность. много проще. а вот у майкрософт. особенно майкрсофт, на блокировочном RC можно вычитать неконсистентную кашу. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2019, 20:36 |
|
|
start [/forum/topic.php?fid=35&gotolast=1&tid=1552179]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 145ms |
0 / 0 |