Как оптимизировать процесс загрузки большего объема данных?

Question

[Paul14]

С базы данных получаю большой объем данных статистики. Потом работаю с ними в реакте, выводя графики продаж, отгрузок и прочее. Средний ответ сервера на запрос 3сек, данные получаю около 7-8 секунд. Нужно уменьшить это время. Это задача.

Какие решения вижу:
1) Сохранить все файлы в какое-то локальное хранилище и загружать их соответственно потом без запроса на сервер.
- Local Storage не походит по размеру хранилища
- Сохранять данные на сервер в текстовый файл не пробывал, но помоему шило на мыло
2) Выполнять все статистические операции на сервере. Но это просто одуреть как неудобно.
... больше мыслей нет

Скажите пожалуйста, какое лучшее решение для этой задачи?

Comments

[Максим Федоров]

Выполнять все статистические операции на сервере. Но это просто одуреть как неудобно

Почему? Агрегируйте по критериям с фронта и получайте то, что нужно только

Для аналитики используйте Clickhouse как быструю колоночную БД для аналитики

[Максим Федоров]

Гонять по сети тонны данных и потом этими тоннами вертеть — худшее из решений

На бекенде есть структуры данных для индексов, мощные ресурсы и при наличии критериев все быстро и без всякого транспорта по сети

Движки готовы быстро и легко данные отдавать

Вы хотите эти агрегации и выборки на слабом фронте делать и еще тяжело транспортом гонять, реализуя мешанину из сторадж-возможностей браузера

[Paul14]

Максим Федоров, а я отвечу вам прямо - да)) Простое пролетарское решение. Которое вот вылезло боком, когда сильно увеличилось кол-во данных. Ну и мороз по коже пробегает, если представить, что код фильтрации и вообще подготовки данных статистики придется писать на php.

[Anton]

Это не задача javasctipt точно ) уменьшить время можно сменив сервер или оптимизировав запрос к базе, все это может сделать бек или админ или оба.

Самый простой вариант, сохраняешь все данные в json файл и грузишь его быстро и резко ) обновляешь файл раз в Х время что бы данные были свежие

[Aetae]

Paul14,

если представить, что код фильтрации и вообще подготовки данных статистики придется писать на php.

Ну так не пишите на PHP.:)
Если вы такой фанат js - на сервер можно node.js поставить.
НО, это мало поможент. Потому что фильтрацию, агрегацию в всё такое прочее чтоб быстро работало - писать придётся на самом деле в SQL.:)

Answer 1

[Дмитрий Кузнецов]

Для начала необходимо понять по какой причине ответ от сервера около 3 секунд.
Тут может быть проблема в настройках, слабом сервере или ещё чего из большого списка возможностей.

Далее нужно понять почему данные вы получаете 7-8 секунд.
Тут может быть как первая причина, так и просто неоптимизированный, кривой код. Опять же, разбираемся!

В любом случае нужно всю логику пихать в сервер, а клиенту отдавать уже готовые данные для отображения. Клиент не должен страдать из-за больших данных, тем более владельцы мобильных телефонов. Для них это будет ужс и они уйдут из вашего продукта.
PS: Я бы и сам не стал ждать такой долгой загрузки.

UPD:
Банальный пример из практики. У нас в проекте был очень старый код, который написан был лет 5 назад. Новички думали что просто сервер слабый. Но покопавшись в коде стало ясно, что код крайне неоптимизированный и мы его оптимизировали.
Раньше загружалось более 60 секунд (как правило уходил в таймаут. т.е. вообще не загружались при малом количестве фильтров по данным)
Стало: около 10-20 секунд.
И это те же данные...

Comments

[Paul14]

Персональная СРМ система. Данные хранятся в таблицах MySql.
clients, calls, tasks,mails,messages... и тд. Много всего. У каждого поля таблиц есть параметр clientID, который является указателем, что это, ну скажем, письмо связано с определенным клиентом.

Я с помощью PHP функции собираю все данные по каждому клиенту в один JSON и оправляю их обратно.

clients:[
// первый клиент
{
calls: [...] ,
mails: [...],
...
},
// и тд, другие клиенты
...
]

Итоговый размер данных как видно всего 4.5 мб, при времени скачивания 12 секунд.
Подскажите пожалуйста кто знает - это не нормально ведь, косяк со стороны моего кода на сервере?

[Дмитрий Кузнецов]

Нормально-не нормально - зависит от задачи. К тому же без общего кода и информации о бд сложно сказать правильно ли вы делаете.
Может вы запросами к БД не правильно работаете, мб что-то в коде самого "сборщика" данных не так.

Answer 2

[VoidVolker]

Провести диагностику и анализ того, какие именно данные запрашиваются, откуда, каким образом и как они попадают туда, где они нужны. Т.е., исследовать путь данных и механизм их получения. Далее изучить на каком этапе происходит задержка или задержки и уже от этого момента проектировать решение. В общем случае можно сделать следующее:

• оптимизировать запрос для получения данных
  
• оптимизировать формат передачи данных
  
• добавить сжатие данных
  
• сделать кэширование, возможно даже в несколько уровней
  
• обновить железо сервера на более мощное
  
• оптимизировать или сменить БД на более подходящую для задачи
  
• часть или все вычисления производить на сервере и выдавать готовый результат в нужном виде
  

Answer 3

[ThunderCat]

Потом работаю с ними в реакте, выводя графики продаж, отгрузок и прочее.

Так, а это вот все в одну кучу нужно, или для каждого графика нужно свой набор данных? Не проще каждый график строить по отдельному запросу? Таким образом во первых вы разделите потоки, уменьшите данные на один запрос, и практически аннигилируете нагрузку на фронт.

Comments

[Владимир]

Тут вопрос какие именно данные используются? У меня, скажем, есть утилитка, работающая с геоданными, я в итоге пришёл к тому, чтобы как раз закачать весь массив на клиент и уже на месте раскидывать по частям дашборда. Потому что на карте хочешь не хочешь, а все точки и дуги отобразить нужно и их не настолько много чтобы геморроиться с динамической подгрузкой при скролле и выкидыванием промежуточных точек при зуме.

Answer 4

[Надим]

Вот:
https://github.com/localForage/localForage
Можно хранить в браузере файлы и данные любого объема.

Comments

[Paul14]

Классно! Спасибо!