|
Выбор СУБД
|
|||
---|---|---|---|
#18+
Всем привет!!! Прошу помочь в выборе СУБД для реализации следующей задачи 1) Справочники: на входе в программу поступает изначально неизвестное количество справочников с неизвестным количеством реквизитов в виде XML файла. Единственный реквизит который будет у всех - это id. Структура XML как-раз и определяет структуру наших будущих справочников (Название справочника, Название реквизитов, и соответственно количество реквизитов) Например <object class="nomenklatura"> <void property="guid"><string>90fb867c-1669-11e8-bf56-6c71d9a36bc0</string></void> <void property="kod"><string>00-00000001</string></void> <void property="naimenovanie"><string>шкаф-купе</string></void> </object> <object class="kontragenti"> <void property="guid"><string>0e016a1f-be1f-11e7-a20e-00155d33f636</string></void> <void property="naimenovanie"><string>сковороднева анна викторовна</string></void> <void property="inn"><string>778945656</string></void> <void property="kpp"><string>566246778</string></void> </object> 2) Аналитические данные: так же на входе в виде XML поступает набор <дата>, <сумма>, <id показателя>, <id элемента справочника 1>, <id элемента справочника 2>, <id элемента справочника 3>,... <id элемента справочника N> где дата - время когда был произведена операция, сумма - численное значение (количество чего-то), id показателя - это элемент справочника показателей, <id элемента справочника а> - элемент какого-то справочника а (либо номенклатура, либо контрагент, либо еще какой-то). Показатель же в этом случае выступает в качестве идентификатора произведенной операции и набора справочников. Пример справочника показателей: id=1 , наименование=Выручка, Справочники=[kontragenti, nomenklaturi, podrazdelenie] id=2 , наименование=Маржинальный доход , Справочники = [kontragenti, nomenklaturi , podrazdelenie , sklad ] id=3 , наименование=Запасы готовой продукции , Справочники = [podrazdelenie, sklad, nomenklaturi] В итоге в таблице аналитических данных должно сконцентрироваться описание произведенных операций в разрезе аналитических данных, количество которых у всех операций разное в зависимости от показателя. Количество показателей может достигать 15 - 20, и соответственно учитывая количество номенклатур, контрагентов, складов, подразделений и т.д. количество строк аналитической информации может накапливаться 1 - 100 млн. в год. 3) Необходимо будет составлять отчеты в разрезе показателя, в разрезе одного или нескольких справочников и самое главное быстро. Вопрос: какую СУБД посоветуете для реализации данной задачи и не менее важное условие - бесплатная СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2019, 11:31 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
MySQL или PostGre бери. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2019, 13:31 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
trualкакую СУБД посоветуете для реализации данной задачи Ту, которую знает тот, кто будет эту задачу решать. Ибо СУБД как таковая тут сугубо перпендикулярна и всё зависит от рук программиста. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2019, 13:49 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
trual, Не структурированные данные плохо ложатся на РМД. Тут вам либо EAV делать, тогда ни о какой скорости говорить нельзя. Либо таки углубятся в предметную область и строить РМД. Можно попробовать взять PostgreSQL и работать с JSON-ами, но опять же ни о какой скорости нельзя говорить. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2019, 14:46 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
mad_nazgul, Как раз скорость очень важна. Но идея имеет место быть потому что по реквизитам не будет фильтрации. Фильтрация по id элементов справочников-аналитик и по id показателей. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2019, 15:48 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
С колоночными СУБД никто не сталкивался? ClickHouse например ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2019, 15:50 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
mad_nazgulТут вам либо EAV делать, тогда ни о какой скорости говорить нельзя. Можно. Но, как я и сказал, нужны правильно заточенные под неё мозги разработчика. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2019, 16:12 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
trualmad_nazgul, Как раз скорость очень важна. Но идея имеет место быть потому что по реквизитам не будет фильтрации. Фильтрация по id элементов справочников-аналитик и по id показателей. монго.... ничего не умеет кроме как быстро хранить такие вот доки... и только по id искать ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 09:00 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
trualmad_nazgul, Как раз скорость очень важна. Но идея имеет место быть потому что по реквизитам не будет фильтрации. Фильтрация по id элементов справочников-аналитик и по id показателей. MongoDB умеет хранить неизвестное количество реквизитов и очень быстро доставть по id также поддерживает различные индексы, представления, агрегацию, свой язык запросов, которые также быстрые, если используются индексы, а не полное сканирование в 4-й версии появились транзакции ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 09:06 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
Также из коробки Replica Set для надёжности и Sharding для масштабирования ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2019, 09:08 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
На хабре деятель все-таки скрестил ежа с ужом в MySQL https://habr.com/ru/company/oleg-bunin/blog/443422/ До того, как появился MySQL 5.7, люди тоже хранили JSON, но как поле text. Поле JSON в MySQL позволяет хранить сам JSON наиболее эффективно. Кроме того, на основе JSON можно создать виртуальные колонки и на их основе индексы. Его там поругивают, но не очень активно. Ибо прогеры в основном за JSON в любой бочке ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2019, 12:20 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
недавно у яндекса смотрел видео, как они собирают метрики,хранят их и выводят аналитику. Поищите -там ваш случай. Причем там как было и как стало. Возможно вам как было будет интереснее. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2019, 13:36 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
Озверин, искать-то как? По "Озверин недавно у яндекса смотрел видео"? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2019, 21:04 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
Дмитрий МухОзверин, искать-то как? По "Озверин недавно у яндекса смотрел видео"? :) https://google.gik-team.com/?q=яндекс доклад метрики высокая нагрузка ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2019, 09:41 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
ОзверинДмитрий МухОзверин, искать-то как? По "Озверин недавно у яндекса смотрел видео"? :) https://google.gik-team.com/?q=яндекс доклад метрики высокая нагрузка Не могли бы вы теперь дать прямую ссылку на видео, о котором писали выше? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2019, 10:11 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
skyANAОзверинпропущено... https://google.gik-team.com/?q=яндекс доклад метрики высокая нагрузка Не могли бы вы теперь дать прямую ссылку на видео, о котором писали выше? нет, конечно. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2019, 10:38 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
trualВсем привет!!! Прошу помочь в выборе СУБД для реализации следующей задачи 1) Справочники: ... 2) Аналитические данные: ... Пример справочника показателей: id=1 , наименование=Выручка, Справочники=[kontragenti, nomenklaturi, podrazdelenie] id=2 , наименование=Маржинальный доход , Справочники = [kontragenti, nomenklaturi , podrazdelenie , sklad ] id=3 , наименование=Запасы готовой продукции , Справочники = [podrazdelenie, sklad, nomenklaturi] В итоге в таблице аналитических данных должно сконцентрироваться описание произведенных операций в разрезе аналитических данных, количество которых у всех операций разное в зависимости от показателя. Количество показателей может достигать 15 - 20, и соответственно учитывая количество номенклатур, контрагентов, складов, подразделений и т.д. количество строк аналитической информации может накапливаться 1 - 100 млн. в год. 3) Необходимо будет составлять отчеты в разрезе показателя, в разрезе одного или нескольких справочников и самое главное быстро. Вопрос: какую СУБД посоветуете для реализации данной задачи и не менее важное условие - бесплатная СУБД. Вообще описание задачи (а в особенности примеры))) очень похоже на OLAP. Измерения, факты... Вы, кстати, вероятно забыли упомянуть, что ваши справочники имеют иерархию, и надо будет строить отчеты по разным уровням иерархии. Та же номенклатура. Посмотрите на Pentaho. Может, то что надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2019, 15:52 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
s_ustinovtrualВсем привет!!! Прошу помочь в выборе СУБД для реализации следующей задачи 1) Справочники: ... 2) Аналитические данные: ... Пример справочника показателей: id=1 , наименование=Выручка, Справочники=[kontragenti, nomenklaturi, podrazdelenie] id=2 , наименование=Маржинальный доход , Справочники = [kontragenti, nomenklaturi , podrazdelenie , sklad ] id=3 , наименование=Запасы готовой продукции , Справочники = [podrazdelenie, sklad, nomenklaturi] В итоге в таблице аналитических данных должно сконцентрироваться описание произведенных операций в разрезе аналитических данных, количество которых у всех операций разное в зависимости от показателя. Количество показателей может достигать 15 - 20, и соответственно учитывая количество номенклатур, контрагентов, складов, подразделений и т.д. количество строк аналитической информации может накапливаться 1 - 100 млн. в год. 3) Необходимо будет составлять отчеты в разрезе показателя, в разрезе одного или нескольких справочников и самое главное быстро. Вопрос: какую СУБД посоветуете для реализации данной задачи и не менее важное условие - бесплатная СУБД. Вообще описание задачи (а в особенности примеры))) очень похоже на OLAP. Измерения, факты... Вы, кстати, вероятно забыли упомянуть, что ваши справочники имеют иерархию, и надо будет строить отчеты по разным уровням иерархии. Та же номенклатура. Посмотрите на Pentaho. Может, то что надо. Pentaho и иже с ними работает по готовым таблицам- а тут эти таблицы "сваливаются на голову" и нужно как то динамически под них таблицы создавать по структуру пришедшую в xml. Если поток данных большой- EAV не вариант, чего бы не говорили его апологеты. Вообще вопрос имеет мало отношение к выбору СУБД,поскольку обработка приходящего потока данных будет за пределами СУБД. Ну а СУБД нужно использовать ту, которую хорошо знаете. 100 млн. в год. это ни о чем объем. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2019, 23:35 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
Sergueis_ustinovпропущено... Вообще описание задачи (а в особенности примеры))) очень похоже на OLAP. Измерения, факты... Вы, кстати, вероятно забыли упомянуть, что ваши справочники имеют иерархию, и надо будет строить отчеты по разным уровням иерархии. Та же номенклатура. Посмотрите на Pentaho. Может, то что надо. Pentaho и иже с ними работает по готовым таблицам- а тут эти таблицы "сваливаются на голову" и нужно как то динамически под них таблицы создавать по структуру пришедшую в xml. Если поток данных большой- EAV не вариант, чего бы не говорили его апологеты. Вообще вопрос имеет мало отношение к выбору СУБД,поскольку обработка приходящего потока данных будет за пределами СУБД. Ну а СУБД нужно использовать ту, которую хорошо знаете. 100 млн. в год. это ни о чем объем. Данные о продажах никогда не "самозарождаются" в виде xml файлов. То, что ТС написал - это описание OLAP. И изобретать велосипед - не лучшее решение. Самый правильный вариант - перейти в соседний раздел форума и почитать там, что и как делать. Впрочем, если надо решать задачу "копать от забора до обеда" - можно выбрать хоть "Стебелек". ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2019, 00:19 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
s_ustinovДанные о продажах никогда не "самозарождаются" в виде xml файлов. То, что ТС написал - это описание OLAP. И изобретать велосипед - не лучшее решение. Самый правильный вариант - перейти в соседний раздел форума и почитать там, что и как делать. Впрочем, если надо решать задачу "копать от забора до обеда" - можно выбрать хоть "Стебелек". олап уже какое-то время отмирает, у майкрософта часть что класический олап лет 5 уже не развивается. имхо проблема у задачки не куда писать, объемы крошечные, а то что по большому счету хранилище строить надо бы. данные явно валидировать и чистить, не понятно что делать если факт пришел а справочника к нему не пришел. как выглядит исправленный факт, что с этим делать ? история то наверно тоже ? я бы apache spark вычитывал xml и импортировал валидированные данные в файлики колончатой структуры типа parquet или orc. структуры типа снежинка или звезда вроде уже не модно, наверно клал бы в какой-нить вариант Slowly Changing Dimension (SCD). и уже обработанные данные писал бы в рсубд для отчетной системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2019, 08:49 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
H5N1s_ustinovДанные о продажах никогда не "самозарождаются" в виде xml файлов. То, что ТС написал - это описание OLAP. И изобретать велосипед - не лучшее решение. Самый правильный вариант - перейти в соседний раздел форума и почитать там, что и как делать. Впрочем, если надо решать задачу "копать от забора до обеда" - можно выбрать хоть "Стебелек". олап уже какое-то время отмирает, у майкрософта часть что класический олап лет 5 уже не развивается. имхо проблема у задачки не куда писать, объемы крошечные, а то что по большому счету хранилище строить надо бы. данные явно валидировать и чистить, не понятно что делать если факт пришел а справочника к нему не пришел. как выглядит исправленный факт, что с этим делать ? история то наверно тоже ? я бы apache spark вычитывал xml и импортировал валидированные данные в файлики колончатой структуры типа parquet или orc. структуры типа снежинка или звезда вроде уже не модно , наверно клал бы в какой-нить вариант Slowly Changing Dimension (SCD). и уже обработанные данные писал бы в рсубд для отчетной системы. Модно - не модно... :) Если нужен результат - почему бы не воспользоваться чем то пусть не модным, но тем не менее работающим? И очень-очень похожим на то ТЗ, которое ТС описал? В первом сообщении топика ведь как раз описание классической структуры "звезда". Если им надо именно такое - почему бы и не дать именно такое? Пытаться всегда использовать самое "модное" - не лучшая идея. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2019, 13:34 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
s_ustinovМодно - не модно... :) Если нужен результат - почему бы не воспользоваться чем то пусть не модным, но тем не менее работающим? И очень-очень похожим на то ТЗ, которое ТС описал? хотя бы потому что олап это не бесплатно и уже собственно самими производителям не интересен как технология. зачем тратить на это время, даже если оно какое-то время еще будет работать? s_ustinovВ первом сообщении топика ведь как раз описание классической структуры "звезда". Если им надо именно такое - почему бы и не дать именно такое? Пытаться всегда использовать самое "модное" - не лучшая идея. потому что звезду не сунешь потом бизнес пользователю типа у нас тут self bi, давайте дальше сами. а вот витрины напоминающие таблички какие он у себя в системе видит много больше шансов подсунуть под соусом self bi и не погружаться в адъ репортиков ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2019, 15:33 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
H5N1s_ustinovМодно - не модно... :) Если нужен результат - почему бы не воспользоваться чем то пусть не модным, но тем не менее работающим? И очень-очень похожим на то ТЗ, которое ТС описал? хотя бы потому что олап это не бесплатно и уже собственно самими производителям не интересен как технология. зачем тратить на это время, даже если оно какое-то время еще будет работать? Pentaho - бесплатная версия есть. H5N1s_ustinovВ первом сообщении топика ведь как раз описание классической структуры "звезда". Если им надо именно такое - почему бы и не дать именно такое? Пытаться всегда использовать самое "модное" - не лучшая идея. потому что звезду не сунешь потом бизнес пользователю типа у нас тут self bi, давайте дальше сами. а вот витрины напоминающие таблички какие он у себя в системе видит много больше шансов подсунуть под соусом self bi и не погружаться в адъ репортиков Оооо... А можно вот с этого места поподробнее? Как звезду сунуть пользователям для самостоятельного ковыряния я представляю очень хорошо. Если одна группа мер + измерения в SSAS - подключаем через ексель и говорим пользователям - а это такой pivot table - и они работают и никого не трогают. А вот как H5N1подсунуть под соусом self bi вот это: H5N1обработанные данные писал бы в рсубд для отчетной системы? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2019, 19:21 |
|
Выбор СУБД
|
|||
---|---|---|---|
#18+
s_ustinovPentaho - бесплатная версия есть. третий эшелон увядающей технологии. я бы не стал тратить время. s_ustinovОооо... А можно вот с этого места поподробнее? Как звезду сунуть пользователям для самостоятельного ковыряния я представляю очень хорошо. Если одна группа мер + измерения в SSAS - подключаем через ексель и говорим пользователям - а это такой pivot table - и они работают и никого не трогают. ну вот тебе прилетают xml. выглядело что счета и платежи это факты. а потом выясняется что пользователю нужны платежи в разрезе, т.е. счет это измерение для платежа. и начинается ... т.е. с фактами и дименсиями нужно хорошо понимать бизнес и если что-то не продумал - попа. s_ustinovА вот как H5N1подсунуть под соусом self bi вот это: H5N1обработанные данные писал бы в рсубд для отчетной системы? в oracle bi и sap bo дефайнются связи между таблицами, пользователь просто накидывает колонки из таблиц в тот же пивот. зачастую не особо понимая как там таблички между собой связанны. подозреваю нечто подобное в любом bi инструменте. имхо пирожки, графики kpi светофоры гораздо наглядней унылых экселевских таблиц, которые я зачастую прочесть не могу, т.к. без понятия о бизнесе и о чем эти цифры сигнализируют попросту не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2019, 16:42 |
|
|
start [/forum/topic.php?fid=32&msg=39786394&tid=1539951]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
142ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 261ms |
0 / 0 |