всем привет, пишу сервис, в котором пользователи будут раз в 10 секунд будут кидать свою геопозицию, сервис будет сильно загружен и постоянно при обновлении писать в бд не вариант, у меня появилось две идеи:
1. просто апдейтить, но это не сильно быстрее
2. писать в редис и потом другим скриптом читать редис раз в какое-то время и писать в бд, но есть страх, что редис переполниться и то что может произойти гонка данных
предполагается нагрузка на сервис где-то рпс 70-100к
1 м/с это 3.6 км/ч - пешая походка.
Так что смело что ниже отбрасывайте. Это даст сильную экономию.
Дальше, сохраняйте в редисе и сбрасывайте пакетной вставкой в 100 записей.
Посчитаем 1000 инсертов в секунду. Не так уж и много.
Дальше считаем объём памяти для редиса.
guid + timestamp + lng + lat
ааа и ещё, у меня будет такая логика:
раз в 10 секунд сервер получает геопозицию и раз в 5 секунд у нему летят запросы на получение позиций, но не всех, а фильтруя, если данные в редисе, то такой запрос с фильтрацией не простая штука будет, как быть?) а ещё, для фильтрации запрос к бд нужен, так как надо показывать позиции только друзьям
Владимир Коротенко, ещё раз спрошу, то есть работу можно построить так
сервер записывать в редис, а другой скрипт раз в секунду читает редис и делает запрос пачкой
предполагается нагрузка на сервис где-то рпс 70-100к
c
Это не большая нагрузка. Oracle лет 20 назад заявлял 500K транзакций в секунду по результатам бенчмарков.
Данную задачу также можно решать со стороны CQRS / Event Sourcing. Тоесть посто фиксировать события гео-позиции в журналы (они могут быть распределенные) а потом уже накатывать в БД. Здесь я предполагаю что вам не требуется реал-тайм. (За 10 секунд вашего технического лага человек все равно успеет убежать за горизонт) и накинтье еще от 1 секунды до допустим 30 секунд время на фиксацию в основной БД. И получается система вполне себе почти реального времени. И в то-же время вам будет лего выдержать всплески информации и ничего не потерять.
1) есть страх, что редис переполниться
2) и то что может произойти гонка данных
Чтоб что-то не переполнялось - надо иметь оценку объема. Допустим в БД будет 50 млн человек (устройств) трекать свою позицию. Загрузить в тестовом режиме туда 10% и посмотреть как редис захватывает память и сделать прогноз. Сисадмин поможет расчитать занятую и свободную память.
Насчет гонок - я не понял. У тебя атомарные операции. Обновил по ключу и плевать. Консистентность
не нужна. Кто последний - тот и прав. Усложнять эту модель не надо. Это не финансы. Координата есть - оно и ладненько.
mayton2019, то есть я по сути могу просто все в редисе хранить? но только вопрос, как селектить все?
P.s: немного не понимаю просто моменты некоторые, может легче в тг?
OCCASS OCCASSOVICH, для того чтоб искать все ключи в Redis можно сделать KEYS *.
Но сама постановка вопроса говорит о том что тебе Redis не подходит. Key-Value хранилища не предполагают
массовых выборок или агрегаций. Подумай об этом.
mayton2019, ага, получается так, я думаю идея записи в редис, а из редиса в бд при получении координат
и просто чтения из бд при запросе координат
если тебе удобно, давай в тг: miketayson_official
Средний
