Как эффективно искать большие наборы данных по местоположению и диапазону дат?

Question

У меня есть коллекция MongoDB, содержащая такие атрибуты, как:

longitude, latitude, start_date, end_date, price

У меня более 500 миллионов документов.

Мой вопрос заключается в том, как максимально эффективно выполнять поиск по широте / долготе, диапазону дат и цене?
Как я вижу, мои варианты:

1. Создайте геопространственный индекс по широте / долготе и используйте поиск близости MongoDB ..., а затем отфильтруйте его на основе диапазона дат и цены.
   • Мне еще предстоит проверить это, но я беспокоюсь, что объем данных будет слишком большим для быстрого поиска, когда у нас примерно 1 поиск в секунду.
   • У вас был опыт того, как MongoDB отреагирует в этих обстоятельствах?
2. Разделить данные на несколько коллекций по местоположению. то есть по таким городам, как london_collection, paris_collection, new_york_collection.
   • Затем мне нужно будет сначала выполнить запрос по широте / долготе, найти коллекцию ближайших городов, а затем выполнить пространственный поиск MongoDB по этим данным подмножества в этой коллекции с фильтрами даты и цены.
   • У меня было бы неравномерное распространение документов, поскольку в некоторых городах было бы больше документов, чем в других.
3. Создание коллекций по датам, а не по местоположению. То же, что и выше, но каждому документу выделяется коллекция на основе диапазона дат.
   • проблема с поиском с диапазоном дат, который охватывает несколько коллекций.
4. Создание уникальных идентификаторов на основе city_start_date_end_date для каждого документа.
   • Опять же, мне пришлось бы использовать свой лат / длинный запрос, чтобы найти ближайший город, добавить диапазон дат для доступа к ключу. Это кажется довольно быстрым, но мне не очень нравится внешний вид города ... кажется немного уродливым.

Я сейчас экспериментирую с вариантом 1.) но очень хотелось бы услышать ваши идеи, прежде чем я зайду слишком далеко по одному конкретному пути?

Как поисковые системы разделяют свои данные и управляют ими ... это должно быть похожая проблема?

Также мне не нужно использовать MongoDB, я открыт для других опций?

Большое спасибо.

Answer 1

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

Хотя я не могу дать вамКонкретный ответ, я могу предложить исследовать использование чисел Мортона в качестве эффективного способа получения нескольких похожих числовых значений, таких как лат длинных.

число Мортона

Answer 2

Почему вы думаете, что вариант 1 будет слишком медленным? Является ли это результатом теста реального мира или это просто предположение, что оно может в конечном итоге не сработать?

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

Не изобретайте велосипед, а сначала попытайтесь оптимизировать наиболее очевидный путь (1):

1. Настройка географических указателей
2. Используйте explain, чтобы убедиться, что ваши запросы действительно используют индекс
3. Убедитесь, что ваши индексы помещаются в ОЗУ
4. Профилируйте базу данных, используя встроенный профилировщик
5. Не измерять производительность в «холодной» системе, где у индексов еще не было возможности перейти в ОЗУ
6. Если возможно, старайтесь не использовать geoNear, если это возможно, и придерживайтесь более быстрых (но не идеально сферических) near запросов
7. Если вы по-прежнему превышаете ограничения, посмотрите на sharding , чтобы распределить операции чтения и записи на несколько машин.