Я оцениваю бэкэнд для приложения для определения местоположения, похожего на Tinder.
После исследования я очень смущен, есть ли общая модель данных "наилучшей практики", алгоритм для этого. Мой подход использует 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
Я неопытен и не могу предвидеть потенциальную проблему, если масштабирование произойдет для миллионов одновременных пользователей.
Надеюсь, что любой ветеран может пролить некоторый свет.
Для вашего случая использования mongodb будет хорошим выбором.
Вы можете хранить каждого пользователя в одном документе вместе с их текущим местоположением.
Создайте индексы в полях, которые хотите выполнять запросы, например. возраст, пол, местоположение
Mongodb имеет встроенную поддержку геопространственных запросов, поэтому легко найти пользователей в радиусе 1 км от другого пользователя.
Большинство функций noSQL Geo/proximity Index зависят от алгоритма GeoHash
http://www.bigfastblog.com/geohash-intro
Хорошо понять, как это работает, и это действительно захватывающе. Этот метод также можно использовать для создания высокоэффективных индексов в реляционной базе данных.
У Redis есть встроенная поддержка этого, но если вы используете ElastiCache, то в этой версии Redis этого нет, и вам нужно будет использовать это в своем API.
Любая реляционная база данных предоставит вам максимальную гибкость и простейшее решение. Проблема, с которой вы можете столкнуться, - это время запроса. Если вы оптимизируете поиск в своем экземпляре БД (возможно, для "данных поиска/контента" есть "поиск db" ), тогда можно получить весь индекс в памяти для быстрого получения результатов.
Я также могу немного рассказать о Redis: операции отсортированного набора выполняются быстро, но вам нужно отфильтровать. Либо вам придется сканировать ваш близлежащий результат и искать метаинформацию для фильтрации, либо поддерживать отдельные наборы для каждой комбинации фильтра, который вам может понадобиться. У первого будет больше накладных расходов на производительность. Второе требует, чтобы вы сами манипулировали индексами. ЭГ: Что, если кто-то удалит одну из своих "симпатий"? Что делать, если они перемещаются?
Это не флэш или фантазия, но в большинстве случаев, когда вам нужно искать ряд данных, реляционные базы данных выигрывают из-за их простоты и поддержки. Подумайте о том, что ваш поиск является копией вашего основного источника, и вы всегда можете перейти на другое решение или перерисовать/масштабировать, если вам нужно в будущем.
Вам может быть интересен Redis Geo API.
Geo API состоит из набора новых команд, которые добавляют поддержку для хранения и запроса пар координат долготы/широты в ключи Redis. GeoSet - это название структуры данных, содержащей набор (x, y) координат. На самом деле, нет никакой новой структуры данных под капотом: GeoSet - это просто Redis SortedSet.
Я также поддержу MongoDB на основе требований с развитием компаса MongoDB, вы также можете визуализировать свои геопространственные данные. Ссылка на документацию компаса mongodb: " https://docs.mongodb.com/compass/getting-started/".