Подтвердить что ты не робот

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

Я оцениваю бэкэнд для приложения для определения местоположения, похожего на Tinder.

  • Функция приложения показывает близлежащих пользователей онлайн (с сексом и возрастным фильтром).
  • В некоторых системах баз данных есть Redis, Cassandra, MySQL Cluster
  • Приложение должно масштабироваться горизонтально, добавляя node при высоком трафике

После исследования я очень смущен, есть ли общая модель данных "наилучшей практики", алгоритм для этого. Мой подход использует Redis Cluster:

// Store all online users in same location (city) to a Set. In this case, store user:1 to New York set
SADD location:NewYork 1

// Store all users age to Sorted Set. In this case, user:1 has age 30
ZADD age 30 "1"

// Retrieve users in NewYork age from 20 to 40
ZINTERSTORE tmpkey 2 location:NewYork age AGGREGATE MAX
ZRANGEBYSCORE tmpkey 20 40

Я неопытен и не могу предвидеть потенциальную проблему, если масштабирование произойдет для миллионов одновременных пользователей.

Надеюсь, что любой ветеран может пролить некоторый свет.

4b9b3361

ОТВЕТЫ

Ответ 1

Для вашего случая использования mongodb будет хорошим выбором.

  • Вы можете хранить каждого пользователя в одном документе вместе с их текущим местоположением.

  • Создайте индексы в полях, которые хотите выполнять запросы, например. возраст, пол, местоположение

  • Mongodb имеет встроенную поддержку геопространственных запросов, поэтому легко найти пользователей в радиусе 1 км от другого пользователя.

Ответ 2

Большинство функций noSQL Geo/proximity Index зависят от алгоритма GeoHash

http://www.bigfastblog.com/geohash-intro

Хорошо понять, как это работает, и это действительно захватывающе. Этот метод также можно использовать для создания высокоэффективных индексов в реляционной базе данных.

У Redis есть встроенная поддержка этого, но если вы используете ElastiCache, то в этой версии Redis этого нет, и вам нужно будет использовать это в своем API.

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

Я также могу немного рассказать о Redis: операции отсортированного набора выполняются быстро, но вам нужно отфильтровать. Либо вам придется сканировать ваш близлежащий результат и искать метаинформацию для фильтрации, либо поддерживать отдельные наборы для каждой комбинации фильтра, который вам может понадобиться. У первого будет больше накладных расходов на производительность. Второе требует, чтобы вы сами манипулировали индексами. ЭГ: Что, если кто-то удалит одну из своих "симпатий"? Что делать, если они перемещаются?

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

Ответ 3

Вам может быть интересен Redis Geo API.

Geo API состоит из набора новых команд, которые добавляют поддержку для хранения и запроса пар координат долготы/широты в ключи Redis. GeoSet - это название структуры данных, содержащей набор (x, y) координат. На самом деле, нет никакой новой структуры данных под капотом: GeoSet - это просто Redis SortedSet.

Redis Geo Tutorial

Ответ 4

Я также поддержу MongoDB на основе требований с развитием компаса MongoDB, вы также можете визуализировать свои геопространственные данные. Ссылка на документацию компаса mongodb: " https://docs.mongodb.com/compass/getting-started/".