powered by simpleCommunicator - 2.0.18     © 2024 Programmizd 02
Map
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / СУБД для пересчета больших витрин
14 сообщений из 39, страница 2 из 2
СУБД для пересчета больших витрин
    #39906413
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-повтор-
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906420
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик

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

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

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

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

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

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

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

Критик

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

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

Критик

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

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

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

Ну и если требовать наличие индексов в ms sql, то и в другой системе нужно сравнивать с имеющимися индексами. Иначе получается какая-то профанация. Или у тебя без индексов миллиардные таблицы ворочаются? Особенно, если нужно выбрать сотню записей из миллиарда? (на одинаковом железе)
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39906646
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик

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

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

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

За счет чего?


за счет отсутствия FK, за счет отсутствия tempdb где мсскл строит хеши для джоина и сортирует, за счет отсутствия transaction лога, за счет денормализации, за счет много, много большей параллельности.
распараллеливание по нодам это уже следующий этап.
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39907797
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1,

Таки ЧАЛ был прав - матмодель это лишнее звено?
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39907867
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper

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

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

За счет чего?


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


Все это реализуется и в реляционной субд, ну разве что кроме отсутствия tempdb для mssql. А отсутствие лога - довольно спорное решение, будет весьма трудно говорить заказчику что-то вроде "получилась конечно фигня, но ведь быстро же" )
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39907980
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-
...
Рейтинг: 0 / 0
СУБД для пересчета больших витрин
    #39908033
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p_vadik
Всем привет!

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

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

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

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


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

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


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