|
Аналитика из JSON
|
|||
---|---|---|---|
#18+
Добрый день! Нужен совет. Может быть, кто-то уже сталкивался с подобным. Может быть, кто-то так уже работает. Может быть, кто-то сейчас в такой-же ситуации. Ситуация в следующем: Буду описывать своими словами (просьба не кидаться камнями), потому что работаю только с уровнем БД. Есть система, которая обрабатывает 2 вида заявок. Всю обработку (шаги, расчет, дополнительные манипуляции) пишет в БД. Операционная БД реплицируется на аналитическую БД. Соответственно, с аналитической БД проводятся все необходимые выгрузки для дальнейшего анализа. Данную систему постепенно переводят на микросервисную архитектуру. Каждый микросервис (насколько я осведомлен) общается с другими посредством обмена json-файлами (какой структуры и какого объема - не знаю). Соответственно, для аналитической БД, чтобы проводить какой-либо анализ, хотят в БД грузить именно json. Я не знаю, это json-ответ какого-то одного микросервиса, или это общий json, собранный по всем этапам прохождения заявки, но... - Сам объем json-файла (видимо в зависимости от прохождения каких-либо этапов) примерно от 2000 до 8000 строк (это то, что я пока наблюдал, но предположу, что может быть чуть меньше или значительно больше) - Общая структура планируемого загружаемого json-файла состоит из 2-х частей, грубо говоря 1-я часть это какие-то входные данные, а 2-я это результаты прохождения каких-либо шагов обработки - Т.к. заявок 2 вида, то они подразделяются по следующему критерию: 1-й вариант это один участник заявки, 2-й это два и более участника и на этом этапе я наблюдаю следующие отличия (возможно не все, но что успел заметить) -- Если первый вариант заявки, то у участника есть блок параметров расчета, который представляет собой массив, состоящий из нескольких объектов-параметров "Расчет": [ { "Расчет": [ {параметры}, ..., {параметры} ], "Тип": type }, { "Расчет": [ {параметры}, ..., {параметры} ], "Тип": type } ] -- Если второй вариант заявки, то у каждого участника есть блок параметров расчета, который представляет собой объект, в котором содержатся объекты-параметры "Расчет": { { "Расчет": [ {параметры}, ..., {параметры} ], "Тип": type }, доппараметры } -- Так же при втором варианте заявки во второй части (результаты прохождения каких-либо шагов обработки) появляется дополнительная вложенность из-за количества участников заявки, а именно если в 1-м варианте (где один участник) вы видим такое "Результат": { "Шаг_1": {...}, ..., "Шаг_N": {...} } то во втором варианте (где могут быть 2 и более участника) наблюдаем следующее "Результат": { "Шаг_1": {...}, "Участник_1": { параметры, "Результат": { "Шаг_2":{...}, ..., "Шаг_N": {...} } }, ..., "Участник_N": { параметры, "Результат": { "Шаг_2":{...}, ..., "Шаг_N": {...} } } } Это пока что все, что я успел заметить. На основании вышеизложенного хотелось бы получить совет от тех, кто, как я писал, или уже с таким работает, или планирует и т.д. - Грузить ли в БД один общий json - Дробить отдельно на входную часть и результаты При таком подходе думаем использовать или времянки, или cte, или пытаться джойнить на саму себя.. - Может быть дробить общий json еще больше? - Или отказаться от этой затеи и все необходимые данные для аналитики писать по таблицам БД? Вообщем, прошу совета, помощи, наставления на правильный путь и все в таком роде. Заранее спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2023, 12:26 |
|
|
start [/forum/topic.php?fid=53&tid=2186887]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
26ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
others: | 232ms |
total: | 352ms |
0 / 0 |