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