powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Отчёт, большие данные, запрос по частям
6 сообщений из 6, страница 1 из 1
Отчёт, большие данные, запрос по частям
    #39830855
alexlucas007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброе время суток.
Есть таблица с огромным кол-вом данных, сотни миллионов строк.
В рамках запроса для отчёта, к этой таблице джойнятся ещё несколько таблиц. Индексы расставлены соответственно.

Клиент хочет получить отчёт за год+, а это десятки/сотни лямов строк.
Чтобы учесть то что скрипт на каком-то этапе может сдохнуть, конект к бд может упасть, что случается сравнительно часто, нужно получать данные по частям, чтобы потом следующий процесс подобрал отчёт там где предыдущий сдох.

Была идея брать отчёты за день, а потом склеивать.
Но дело в том что сортировка для отчёта может идти как по дате, так и по разным int/строковым колонкам.
Как мерять отрезки в этом случае, так чтобы они были в разумных пределах (max 50k строк за итерацию, например) я не придумал.

Брать лимит+offset с таким кол-вом данных выйдет слишком долго.

Есть какие-нибудь идеи/варианты, может кто сталкивался с подобной задачей?
...
Рейтинг: 0 / 0
Отчёт, большие данные, запрос по частям
    #39830883
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexlucas007Клиент хочет получить отчёт за год+, а это десятки/сотни лямов строк.интересно клиент читает эти лямы строк?
...
Рейтинг: 0 / 0
Отчёт, большие данные, запрос по частям
    #39830899
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexlucas007Чтобы учесть то что скрипт на каком-то этапе может сдохнуть, конект к бд может упастьСтройте отчет независимо от скриптов и коннектов. Например,через Scheduler . Или используя локальный коннект на сервере мимо сети.
alexlucas007что случается сравнительно частоЭто надо исправлять.
...
Рейтинг: 0 / 0
Отчёт, большие данные, запрос по частям
    #39830902
vkle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexlucas007Клиент хочет получить отчёт за год+, а это десятки/сотни лямов строк.При таком раскладе:
а) Мозг среднестатистического индивидуума не в состоянии воспринять/оценить такое количество данных. Скорее всего, в реальном отчете будут десятки или небольшие сотни строк.
б) Изменение значения какого-то параметра в одной строке исходных таблиц, кои, можно предположить, состоят из сотен лямов записей, в большинстве случаев вряд ли будет вообще заметно, ну или накрайняк, можно приравнять к статистической погрешности или погрешности вычислений.
Это к вопросу данных для формирования отчета.

alexlucas007Была идея брать отчёты за день, а потом склеивать.
Но дело в том что сортировка для отчёта может идти как по дате, так и по разным int/строковым колонкам.Хорошая идея, только повернули не туда.
Есть смысл подготовить и хранить заранее подготовленные данные для формирования отчета в дополнительных таблицах, из которых можно сделать выборки с необходимой сортировкой/группировкой "как по дате, так и по разным int/строковым колонкам". Особенно это касается прошедших временных промежутков, на которые будущее уже никак не повлияете.
Возможно, для каких-то отчетов более приемлемыми будут таблицы с дискретностью в один год, для других в один квартал, месяц или день.
Возможно, есть смысл группировать статистические данные по каким-то иным признакам, а не только по дате.

Общий смысл состоит в том, что:
1) промежуточные данные для сборки готового отчета можно подготовить заранее и в фоновом режиме (а не во время формирования отчета).
2) эти данные своей структурой максимально пригодны для составления отчета.

Если же все отчеты заранее точно известны (строго прописаны в ТЗ) и пользователь не выбирает заранее неведомые произвольные сочетания ограничений/фильтров (например, а покажи-ка продажи с июня 2016 по сентябрь 2018 по товару "цветные карандаши" в регионах Краснодарский край и Псковская область) - тогда можно и готовые отчеты хранить.

alexlucas007конект к бд может упасть, что случается сравнительно частоЭто плохо. Необходимо разобраться и устранить причину сей проблемы.
...
Рейтинг: 0 / 0
Отчёт, большие данные, запрос по частям
    #39831149
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexlucas007Чтобы учесть то что скрипт на каком-то этапе может сдохнуть, конект к бд может упасть, что случается сравнительно часто
"Чо?"
Может, вместо кривых костылей стоит таки починить коннект?..
Или вы там в принципе хотите заложить возможность "отчёт продолжить после того как на сервер упадёт метеорит"?
...
Рейтинг: 0 / 0
Отчёт, большие данные, запрос по частям
    #39831172
alexlucas007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
вадяинтересно клиент читает эти лямы строк?
Есть задача, надо сделать. Клиент платит.

miksoftЭто надо исправлять.
Конечно, но это уже задача для DBA. Мне приходится это учитывать.

vkleОбщий смысл состоит в том, что:
1) промежуточные данные для сборки готового отчета можно подготовить заранее и в фоновом режиме (а не во время формирования отчета).
2) эти данные своей структурой максимально пригодны для составления отчета.

Да,таблицы с агрегированными данными были бы отличным решением, но их нет, а будут они всегда "скоро". А для того чтобы знать что и сколько собирать, надо ещё и говорить с клиентами. Вдруг один захочет отчёт с ещё фиг пойми чем.
Нет партиций, нет архивных баз.

В принципе мне стало ясно что нужно либо менять задачу, либо положить задачу в долгий ящик пока не будет проведена работа над инфраструктурой.
Но так как второе будет "скоро", пока упростили задачу с учётом недостатков инфраструктуры.
...
Рейтинг: 0 / 0
6 сообщений из 6, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Отчёт, большие данные, запрос по частям
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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