Есть ли быстрое хранилище с возможностью подписаться на обновления?

Question

[Володимир Паламар]

Трекеры каждые ±20 сек присылают свою скорость и координаты на сервер на Go. Надо их где-то хранить и при обновлении значений другая проблема на Nodejs должна присылать клиентам координаты
Я думаю в сторону Redis но хотел бы услышать и мнение других людей

Comments

[d'Ivan]

От плохого вопроса хорошего ответа не жди.
Афоризм (с) мой

Answer 1

[paran0id]

Kafka

Comments

[Володимир Паламар]

Можно подробнее?

[Сергей Горностаев]

Володимир Паламар, Apache Kafka.

[Володимир Паламар]

Сергей Горностаев, гуглить умею, спасибо.
paran0id Подробнее почему именно кафку?

[Сергей Горностаев]

Володимир Паламар, потому что она разработана именно для таких сценариев использования и просто идеально подходит для описанного случая.

[Володимир Паламар]

paran0id Сергей Горностаев, хорошо а если ли альтернативные варианты RabbitMQ например. Что о них скажете?

[d'Ivan]

paran0id
Интересно, почему, скажем, не NATS, Postgres?

[paran0id]

Володимир Паламар,
Ловите телеметрию от трекеров по http, кладете в топик кафки.
На топике настраиваете сколько-то там партишенов, по числу сервисов, разгребающих топик. Допустим, 10.
Ставите ретеншен, чтобы старые данные автоматически вычищались, допустим сутки.
Разгребающие сервисы подписаны на топик, имеют общее для всех значение consumer group. Прилетающие в топик сообщения они читают и отправляют координаты, или чего там.
Формат сообщения - на ваше усмотрение, json например, но что-нибудь бинарное будет быстрее.

Если нужно хранить исторические данные и что-то с ними сделать, разумно будет поставить какую-нибудь базу (хорошо подойдет clickhouse). Писать по одному событию нерационально - медленно и грузит базу, так что лучше будет выгребать батчем по достижению количества или истечению времени, что раньше наступит. Для этого можно отрядить отдельный сервис с другой consumer group.

[paran0id]

Román Mirilaczvili, про NATS ничего не могу сказать. Не postgres, потому что инсёртить 1000x20 раз в секунду в базу как-то не круто, а если база таки нужна, то лучше колоночная типа clickhouse, но в любом случае будет лучше квантовать запросы и кидать их в базу батчем.

[Володимир Паламар]

paran0id, по сути есть 24 области думаю клиенту не нужно получать все сразу координаты ему надо только ближайшее

[paran0id]

Володимир Паламар, вы не описали свою архитектуру - по этим обрывкам я вообще не понимаю, что вы делаете.

Но если вам точно не нужно хранить исторические данные - просто ставьте retention на топик поменьше.

[Володимир Паламар]

paran0id, историю не надо только последние значение

[d'Ivan]

paran0id, в Postgres есть встроенный механизм Pub/Sub, если что. И я не видел где автор вопроса указывает про

инсёртить 1000x20 раз в секунду

[paran0id]

Román Mirilaczvili, он в другой ветке упоминал

[d'Ivan]

paran0id, если я верно понял задание

историю не надо только последние значение

то Kafka - решение как стрелять из пушки по воробьям.

[paran0id]

Román Mirilaczvili, это условие появилось уже после того, как я ответил

Answer 2

[mayton2019]

Если честно у меня - путаница. Трекеры и клиенты - это одни и те-же сущности?

Kafka - хорошая штука но она любит грамотный дизайн топиков. Какой здесь будет маппинг? Если клиентов - 100 мильонов то вряд-ли кафка выдержит столько-же топиков. Если топик делать один на все события - то нужно как-то партицировать по признакам. По каким?

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

Comments

[Володимир Паламар]

Примерно 1000 машин. В одну смену грубо считая половина из них каждые 20 сек присылают координаты и свою скорость

Трекеры только присылают данные
Клиенты их только читают

При чем трекеры присылают их через сервер на Go присылая свой индивидуальный номер скорость и координаты

[Сергей Горностаев]

Володимир Паламар, детская нагрузка для Кафки.

[paran0id]

Если топик делать один на все события - то нужно как-то партицировать по признакам. По каким?

А нафига по признакам? 10 партишенов - 10 консумеров. consumer group у всех одинаковая.

[mayton2019]

Володимир Паламар, сколько клиентов одновременно присутствуют? Согласно архитектуре Kafka каждый клиент - это consumer и его нужно настроить на топик или есть еще опция топик + партишен или ключ.

Успех архитектуры kafka будет зависеть от того сможете ли вы разложить producers/consumers/partitions оптимальным образом иначе у вас все будут вычитывать всё.

При скорости в 500 машин по 0.05 сообщений в сек получаем средний канал 25 сообщений в сек. При такой нагрузке Kafka не нужна. Можете брать RabbitMQ.

[Володимир Паламар]

mayton2019 , за клиентов ручаться не могу сколько зайдет на сайт столько и будут получать. Но по сути клиентом можно считать программу на Nodejs которая получает все обновления
А какая нагрузка большая для RabbitMQ а оптимальная для Kafka? Какую нагрузку Kafka может выдержать?

[mayton2019]

Володимир Паламар, насчет Kafka я точно не скажу. Но если нет балансировок и перезагрузок - тогда пропускная способность кафки почти бесконечна. Вот сколько машин в кластер загонишь на столько и умножать можно. Ну это грубая формула. Там на самом деле есть еще репликация.

А RabbitMQ - это я просто для общности сказал чтоб было с чем сравнивать. Можно даже взять Apache ActiveMQ. Это все из бесплантного. А по поводу недостатков. Эти все штуки хорошо работают в топологии точка-точка. Но если у тебя модель топиков-подписок то эти архитектуры ведут себя гораздо хуже чем кафка. Собственно ... Кафка это даже не MQ система. Это скорее распределенное хранилище логов сообщений. Вот поэтому ее и часто советуют в оппозицию к стандартным системам.

Answer 3

[Сергей Соколов]

Redis Pub/Sub вполне подойдёт, наверное.

Answer 4

[Vitsliputsli]

Что значить "Надо их где-то хранить"? Эти данные будут использоваться далее, отдельно от описанного?
Если не будут, просто сразу пересылайте из сервера Go в сервер nodejs. Если, чтото и потеряется, то оно все равно утратит свою актуальность и придут новые данные.
Если будут использоваться, то зависит от того, как будет использоваться, вполне может и вообще классическая СУБД нужна.

Comments

[Володимир Паламар]

Веб приложении запрашивает SSE стрим с координатами, он получает сразу же "старые" а потом по мере обновления новые. Это значит что надо где-то хранить или кэшировать координаты

[Vitsliputsli]

Володимир Паламар, ну и отлично, redis вполне подойдет, если нет особых требований к лагу. Если есть, тогда появляется смысл заморочиться очередями.

[d'Ivan]

Просто вытесняем старые данные новыми по заданному ключу-идентификатору.

[mayton2019]

Выше по топику кто-то советовал Redis. Вот - хороший кандидат. Бери и храни последнюю координату в Redis.

[d'Ivan]

Володимир Паламар, на чем остановился выбор в итоге?

[Володимир Паламар]

Román Mirilaczvili, Redis