|
Анализ большого объема данных на лету.
|
|||
---|---|---|---|
#18+
Всем добрый день. Может кто то подкинуть пар идей. Какие вообще возможны варианты решения подобной задачи. К примеру есть сотрудник и есть админы организации. Сотрудники могут видеть автомобили, находящиеся у 2-3 дилерский центров ДС. Админы могут видеть авто во всех ДЦ. Сотрудник открывает ИС и ему показывается список авто с параметрами год выпуска, адрес ДЦ и тд. Всего 20-25тыс автомобилей. И вот задача: у автомобиля есть стадия, на которой он сейчас находится. Эта стадия считается по очень сложной логике с задействованием большого объема данных из 15ти таблиц. 1 вариант, запихнуть все в один запрос, тогда стадия по 1-2тысячам авто считается быстро, по 10-20тысячам очень тяжело. А если зайдет админ и откроет список по всем ДС, то это полчаса на реплике. 2 вариант предрассчитать стадию и сложить результат в t_vin_state. Эту таблицу приджойнить к списку авто. Повесить триггеры на эти 15 таблиц. Во время изменения какой либо таблицы, триггер в специальную таблицу t_vin_queue заносит vin авто. Каждые 5 минут запускается скрипт, который лезет в t_vin_queue и пересчитывает стадии и обновляет t_vin_state. В таком варианте соответственно имеем время, когда статус неактуален и тут надо решать задачу, как информировать юзера - типа подождите 5 минут, статус еще не актуализировался. Может кто то уже решал подобную задачу, может задействовал какие то инструменты другие. Заранее спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2020, 13:57 |
|
Анализ большого объема данных на лету.
|
|||
---|---|---|---|
#18+
kliff Сотрудник открывает ИС и ему показывается список авто с параметрами год выпуска, адрес ДЦ и тд. Всего 20-25тыс автомобилей. Пока пользователь просто промотает эту портянку сверху вниз, уже пройдут те самые 5 минут и статусы станут не актуальны. :) Если на лету пересчитывать статус накладно, то 2-й вариант в самый раз. Мне кажется, 5 минут вообще никак не критичны в этой задаче, просто предупредить пользователей, что будет такой лаг. Разве сейчас, когда у них сейчас по полчаса идут расчеты, они получают актуальную информацию? Да хоть бы и не полчаса. Человек открывает данные, смотрит их какое-то время, они за это время становятся неактуальными, вы ведь с этим не пытаетесь бороться? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2020, 03:17 |
|
Анализ большого объема данных на лету.
|
|||
---|---|---|---|
#18+
Ruuu kliff Сотрудник открывает ИС и ему показывается список авто с параметрами год выпуска, адрес ДЦ и тд. Всего 20-25тыс автомобилей. Пока пользователь просто промотает эту портянку сверху вниз, уже пройдут те самые 5 минут и статусы станут не актуальны. :) Если на лету пересчитывать статус накладно, то 2-й вариант в самый раз. Мне кажется, 5 минут вообще никак не критичны в этой задаче, просто предупредить пользователей, что будет такой лаг. Разве сейчас, когда у них сейчас по полчаса идут расчеты, они получают актуальную информацию? Да хоть бы и не полчаса. Человек открывает данные, смотрит их какое-то время, они за это время становятся неактуальными, вы ведь с этим не пытаетесь бороться? Извиняюсь, что не полностью описал в задаче. Но еще плюсом сортировка этого списка делается по вот этим статусам. То есть пагинация тут не получается. Нельзя выбрать первые 20 записей и по ним показать статусы. Если пагинация, то надо выбрать весь список, рассчитать статусы по нему, отсортировать по статусам и показать на первой странице первые 20 записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 12:12 |
|
Анализ большого объема данных на лету.
|
|||
---|---|---|---|
#18+
kliffИзвиняюсь, что не полностью описал в задаче. Но еще плюсом сортировка этого списка делается по вот этим статусам. То есть пагинация тут не получается. Как наличие сортировки влияет на возможность реализации пагинации? Как раз наоборот, возможность сортировки по уникальному набору столбцов является необходимым условием для нормальной пагинации (например, value-based pagination). ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2020, 18:48 |
|
Анализ большого объема данных на лету.
|
|||
---|---|---|---|
#18+
bff7755a kliffИзвиняюсь, что не полностью описал в задаче. Но еще плюсом сортировка этого списка делается по вот этим статусам. То есть пагинация тут не получается. Как наличие сортировки влияет на возможность реализации пагинации? Как раз наоборот, возможность сортировки по уникальному набору столбцов является необходимым условием для нормальной пагинации (например, value-based pagination). влияет так, что нет возможности обработать весь список например 100тыс записей, взять для первой страницы первые 100 записей и для этих 100 посчитать статусы. Тут надо для всех 100тыс посчитать статус, по полученным статусам отсортировать и только потом взять первые 100. То есть пагинация не избавляет от необходимости перебора всех записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2020, 15:40 |
|
|
start [/forum/topic.php?fid=53&msg=39958511&tid=1994541]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 289ms |
total: | 445ms |
0 / 0 |