v
агент подключаешь в рантайме и шлёшь из него граф на сервер
Size: a a a
2020 February 02
v
на локалхост)
K
Ребята, кто разруливал такую ситуацию, данных много(2-3 млн) в таблице, сделана страница куда выводятся резуьтаты статистики, сейчас все работает на связке постгресс+монго, тормозит все адово, клиент не хочет уступать в сторону кеширования части данных, просит реалтайм вывод.
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
v
на локалхост)
на локальный сервер, без разницы) либо он тебе формирует файл с графом и коммитишь его в репу, а сервис подцепляет
v
даже проще так
RR
Ребята, кто разруливал такую ситуацию, данных много(2-3 млн) в таблице, сделана страница куда выводятся резуьтаты статистики, сейчас все работает на связке постгресс+монго, тормозит все адово, клиент не хочет уступать в сторону кеширования части данных, просит реалтайм вывод.
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
сделай материализованную вьюху
K
постгресную?
RR
будешь ее обновлять в беке, на тот же сейв\апдейт
RR
мы на проекте такое делали, при сейве\апдейте отправлялась джоба в сайдкик на пересчет, и контроллировалось, что за 1 раз обновляется 1 раз, т.е. лок через редис
RR
у нас обновление было порядка 2-3 секунд
K
а обьем данных по которым вьюха работала?
v
Ребята, кто разруливал такую ситуацию, данных много(2-3 млн) в таблице, сделана страница куда выводятся резуьтаты статистики, сейчас все работает на связке постгресс+монго, тормозит все адово, клиент не хочет уступать в сторону кеширования части данных, просит реалтайм вывод.
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
а почему сразу не писать агрегированные данные?
RR
не очень большой, там где-то 30к записей было, но запрос на полтора экрана, агрегация из 5 таблиц с вложенными запросами
RR
по сути ты свою стату, которую выводишь, выделишь в SQL запрос
RR
и примерно его скорость работы будет равна пересчету +\-
NB
Ребята, кто разруливал такую ситуацию, данных много(2-3 млн) в таблице, сделана страница куда выводятся резуьтаты статистики, сейчас все работает на связке постгресс+монго, тормозит все адово, клиент не хочет уступать в сторону кеширования части данных, просит реалтайм вывод.
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
Я вижу схему так, берем таблицы, которые хранят данные для расчетов, создаем одну таблицу, в которой будут колонки с параметрами для графиков(проценты, разница и т.п) пишем импорт данных с применением их написанных считалок этого всего добра, расчитываем все в бекграунде и заносит потихоньку в эту одну таблицу.
Так же пишем обработку новых данных, где на бекграунде будет пересчитывать поля(процентные, разница) и +=1 для счетчиков(int) каждый раз, когда поступает процесс создания.
Входные:
Давит не сильно, 50-70rpm на новые данные
Не совсем прикольно запускать джобы на каждый сейв, но запихывать перерасчет в сервер где происходят сейв повлечет увеличение респонза, поэтому скорее всего по вебхуку будет прилетать на сервер с расчетом статистики и джобами обрабатывать.
Кто разруливал реалтайм статистику с кучей процентов и вывода разниц, когда требовали - здесь и сейчас(новый сейв - покажи нам его прямо сейчас) ?
Что-то примерное такое и делали: сайдкик джоб, который пересчитывал статистику. Только данных было овер 64 млн в таблице (и похожиш таьлиц штук 5, от 20 до 70 млн рекордов), и джоб запускался пару раз в день (не реал-тайм, но и данные дополнялись не часто)
K
а почему сразу не писать агрегированные данные?
считает много(27 графиков, проценты, разница, сравнение вчера - сегодня и прочая каша)
RR
а там уже индексы можно навесить и тд
RR
https://github.com/scenic-views/scenic
вот через него делал, + у тебя версионирование SQL
вот через него делал, + у тебя версионирование SQL
