Имеет таблицу на миллиард записей, количество столбцов в записи порядка 500. Потенциально в столбце может быть массив. Данные не изменяются. То есть строим одну большую таблицу, и далее над ней делается произвольная аналитика.
Нужно произвольно делать агрегации и группировки по произвольному набору столбцов (то есть) что то вроде sekect sum()... from big table group by (произвольное количество столбцов). Возможно с фильтрами предварительными, возможно без фильтров на всем наборе данных. Делать это нужно в реальном времени. Условие агрегации потенциально может быть весьма хитрым.
То есть по существу это OLAP. Но такой, что куб хрен построишь, ибо число dimensions до черта. У нас не получилось это сделать на более простой задаче.
Какие можете подсказать технологии, позволяющие решить эту задачу? Сейчас смотрю на Clickhouse, различные GPU database как основные кандидаты, плюс есть самописное кое что, неплохо себя показавшее на похожих задачах. Понятно, что будет кластер, но важна максимальная скорость на одной ноде. ИМХО одна нода на средненьком серваке должна влегкую выполнять произвольный запрос в пределах 10 секунд. Плевать на горизонтальное масштабирование из коробки — если нет, это не проблема достичь другими средствами. Если есть технологии, которые это смогут быстрее — отлично, вот именно они и нужны. Смотрел когда то на DataGrid вроде Ignite, как то не впечатлился — данные хрен влезают в память, а то, что влезает, агрегируются очень сильно не быстро.
Здравствуйте, elmal, Вы писали:
E>Есть задача:
E>Имеет таблицу на миллиард записей, количество столбцов в записи порядка 500. Потенциально в столбце может быть массив. Данные не изменяются. То есть строим одну большую таблицу, и далее над ней делается произвольная аналитика.
E>Нужно произвольно делать агрегации и группировки по произвольному набору столбцов (то есть) что то вроде sekect sum()... from big table group by (произвольное количество столбцов). Возможно с фильтрами предварительными, возможно без фильтров на всем наборе данных. Делать это нужно в реальном времени. Условие агрегации потенциально может быть весьма хитрым.
E>То есть по существу это OLAP. Но такой, что куб хрен построишь, ибо число dimensions до черта. У нас не получилось это сделать на более простой задаче.
E>Какие можете подсказать технологии.
1. Microsoft PDW (Parallel Data Warehouse)
2. Snowflake (работает ну очень быстро, сами его хотим в будущем...)
Здравствуйте, Milena, Вы писали:
M>1. Microsoft PDW (Parallel Data Warehouse) M>2. Snowflake (работает ну очень быстро, сами его хотим в будущем...)
Да, еще. Должно быть свободным для использования решением, хотя возможно с какими то ограничениями по функциональности по сравнению с платной версией. То есть чтоб без возни с лицензиями и тому подобным. Развертываться должно во внутренней сети.
Здравствуйте, elmal, Вы писали:
E>Какие можете подсказать технологии, позволяющие решить эту задачу? Сейчас смотрю на Clickhouse, различные GPU database как основные кандидаты, плюс есть самописное кое что, неплохо себя показавшее на похожих задачах. Понятно, что будет кластер, но важна максимальная скорость на одной ноде. ИМХО одна нода на средненьком серваке должна влегкую выполнять произвольный запрос в пределах 10 секунд. Плевать на горизонтальное масштабирование из коробки — если нет, это не проблема достичь другими средствами. Если есть технологии, которые это смогут быстрее — отлично, вот именно они и нужны. Смотрел когда то на DataGrid вроде Ignite, как то не впечатлился — данные хрен влезают в память, а то, что влезает, агрегируются очень сильно не быстро.
В смысле, а зачем что-то изобретать? Такие скорости уже в мейнстриме достижимы
Вот mssql 2017, 0.133B записей ~250колонок. Сервачок вполне обычнычный, старенький, 12физ ядер х2.2GHz
1476 ms elapsed time
если отмасштабировать на новое железо и твой объем будет ~5sec на ноду как ты и хотел
пруф https://snag.gy/GRm0al.jpg
Здравствуйте, rm822, Вы писали:
R>Вот mssql 2017, 0.133B записей ~250колонок. Сервачок вполне обычнычный, старенький, 12физ ядер х2.2GHz
0.133B записей это 133 миллиона? groupby запрос по одной таблице без having и индексов, и на них это будет полторы секунды, причем на таком объеме скорее всего этот запрос полностью в памяти будет делаться. На деле, да, похоже на правду, я скорость ms sql первым делом посмотрел. Это базовая скорость. Хотелось бы решение, которое на одну ноду работает шустрее (и оно у меня, кстати, есть, самописное на Java, правда не намного там шустрее получается, но зато я могу в сложных случаях оптимизировать все ручками и получать на порядки большую скорость), в идеале хотелось бы упереться в теоретический максимум.
Там дополнительно еще будут случаи более сложные, чем просто одна большая таблица, каждой ячейке этой таблице могут соответствовать несколько (порядка 100) дополнительных значений. Например основная таблица у меня накладная, у накладной есть набор услуг, и набор контрагентов, а группироваться я могу хотеть как по полям накладной, так и по полям по контрагентов и полям таблицы услуг. Плюс аггрегации могут быть навороченными, с формулами и ifами, потому если влегкую получается достичь скорости ms sql, но на Java, Java лисапед будет предпочтительнее.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, rm822, Вы писали:
R>>Вот mssql 2017, 0.133B записей ~250колонок. Сервачок вполне обычнычный, старенький, 12физ ядер х2.2GHz E>0.133B записей это 133 миллиона? groupby запрос по одной таблице без having и индексов, и на них это будет полторы секунды, причем на таком объеме скорее всего этот запрос полностью в памяти будет делаться.
оно в любом случае будет все в памяти, даже на 1млрд. https://snag.gy/nS1Jct.jpg
E>Там дополнительно еще будут случаи более сложные, чем просто одна большая таблица, каждой ячейке этой таблице могут соответствовать несколько (порядка 100) дополнительных значений. Например основная таблица у меня накладная, у накладной есть набор услуг, и набор контрагентов, а группироваться я могу хотеть как по полям накладной, так и по полям по контрагентов и полям таблицы услуг. Плюс аггрегации могут быть навороченными, с формулами и ifами, потому если влегкую получается достичь скорости ms sql, но на Java, Java лисапед будет предпочтительнее.
С наворотами она обычно падает с 1.5 до 4-5с, это уже на готовом продукте.
Ты вилосипед свой тестил на нормальном объеме данных и нормальном железе? Если нет — жди чудных открытий
