|
Отчёт, большие данные, запрос по частям
|
|||
---|---|---|---|
#18+
Доброе время суток. Есть таблица с огромным кол-вом данных, сотни миллионов строк. В рамках запроса для отчёта, к этой таблице джойнятся ещё несколько таблиц. Индексы расставлены соответственно. Клиент хочет получить отчёт за год+, а это десятки/сотни лямов строк. Чтобы учесть то что скрипт на каком-то этапе может сдохнуть, конект к бд может упасть, что случается сравнительно часто, нужно получать данные по частям, чтобы потом следующий процесс подобрал отчёт там где предыдущий сдох. Была идея брать отчёты за день, а потом склеивать. Но дело в том что сортировка для отчёта может идти как по дате, так и по разным int/строковым колонкам. Как мерять отрезки в этом случае, так чтобы они были в разумных пределах (max 50k строк за итерацию, например) я не придумал. Брать лимит+offset с таким кол-вом данных выйдет слишком долго. Есть какие-нибудь идеи/варианты, может кто сталкивался с подобной задачей? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2019, 19:23 |
|
Отчёт, большие данные, запрос по частям
|
|||
---|---|---|---|
#18+
alexlucas007Клиент хочет получить отчёт за год+, а это десятки/сотни лямов строк.интересно клиент читает эти лямы строк? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2019, 20:45 |
|
Отчёт, большие данные, запрос по частям
|
|||
---|---|---|---|
#18+
alexlucas007Чтобы учесть то что скрипт на каком-то этапе может сдохнуть, конект к бд может упастьСтройте отчет независимо от скриптов и коннектов. Например,через Scheduler . Или используя локальный коннект на сервере мимо сети. alexlucas007что случается сравнительно частоЭто надо исправлять. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2019, 21:15 |
|
Отчёт, большие данные, запрос по частям
|
|||
---|---|---|---|
#18+
alexlucas007Клиент хочет получить отчёт за год+, а это десятки/сотни лямов строк.При таком раскладе: а) Мозг среднестатистического индивидуума не в состоянии воспринять/оценить такое количество данных. Скорее всего, в реальном отчете будут десятки или небольшие сотни строк. б) Изменение значения какого-то параметра в одной строке исходных таблиц, кои, можно предположить, состоят из сотен лямов записей, в большинстве случаев вряд ли будет вообще заметно, ну или накрайняк, можно приравнять к статистической погрешности или погрешности вычислений. Это к вопросу данных для формирования отчета. alexlucas007Была идея брать отчёты за день, а потом склеивать. Но дело в том что сортировка для отчёта может идти как по дате, так и по разным int/строковым колонкам.Хорошая идея, только повернули не туда. Есть смысл подготовить и хранить заранее подготовленные данные для формирования отчета в дополнительных таблицах, из которых можно сделать выборки с необходимой сортировкой/группировкой "как по дате, так и по разным int/строковым колонкам". Особенно это касается прошедших временных промежутков, на которые будущее уже никак не повлияете. Возможно, для каких-то отчетов более приемлемыми будут таблицы с дискретностью в один год, для других в один квартал, месяц или день. Возможно, есть смысл группировать статистические данные по каким-то иным признакам, а не только по дате. Общий смысл состоит в том, что: 1) промежуточные данные для сборки готового отчета можно подготовить заранее и в фоновом режиме (а не во время формирования отчета). 2) эти данные своей структурой максимально пригодны для составления отчета. Если же все отчеты заранее точно известны (строго прописаны в ТЗ) и пользователь не выбирает заранее неведомые произвольные сочетания ограничений/фильтров (например, а покажи-ка продажи с июня 2016 по сентябрь 2018 по товару "цветные карандаши" в регионах Краснодарский край и Псковская область) - тогда можно и готовые отчеты хранить. alexlucas007конект к бд может упасть, что случается сравнительно частоЭто плохо. Необходимо разобраться и устранить причину сей проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2019, 21:37 |
|
Отчёт, большие данные, запрос по частям
|
|||
---|---|---|---|
#18+
alexlucas007Чтобы учесть то что скрипт на каком-то этапе может сдохнуть, конект к бд может упасть, что случается сравнительно часто "Чо?" Может, вместо кривых костылей стоит таки починить коннект?.. Или вы там в принципе хотите заложить возможность "отчёт продолжить после того как на сервер упадёт метеорит"? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2019, 13:51 |
|
Отчёт, большие данные, запрос по частям
|
|||
---|---|---|---|
#18+
вадяинтересно клиент читает эти лямы строк? Есть задача, надо сделать. Клиент платит. miksoftЭто надо исправлять. Конечно, но это уже задача для DBA. Мне приходится это учитывать. vkleОбщий смысл состоит в том, что: 1) промежуточные данные для сборки готового отчета можно подготовить заранее и в фоновом режиме (а не во время формирования отчета). 2) эти данные своей структурой максимально пригодны для составления отчета. Да,таблицы с агрегированными данными были бы отличным решением, но их нет, а будут они всегда "скоро". А для того чтобы знать что и сколько собирать, надо ещё и говорить с клиентами. Вдруг один захочет отчёт с ещё фиг пойми чем. Нет партиций, нет архивных баз. В принципе мне стало ясно что нужно либо менять задачу, либо положить задачу в долгий ящик пока не будет проведена работа над инфраструктурой. Но так как второе будет "скоро", пока упростили задачу с учётом недостатков инфраструктуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2019, 14:30 |
|
|
start [/forum/topic.php?fid=47&msg=39831172&tid=1829074]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 151ms |
0 / 0 |