MongoDB и использование DBRef с пространственными данными

Question

У меня есть коллекция с 100 миллионами геодезических документов.

У меня есть вторая коллекция со временными данными, связанными с каждой из других геометрий. Это будет 365 * 96 * 100 миллионов или 3,5 триллиона документов.

Вместо того, чтобы хранить 100 миллионов записей (365 * 96) раз больше, чем необходимо, я хочу сохранить их в отдельных коллекциях и сделать тип JOIN/DBRef/что бы я ни смог в MongoDB.

Прежде всего, я хочу получить список GUID из коллекции геометрии с помощью геоинтеграции. Это позволит отфильтровать его до 100 миллионов до 5000. Затем, используя эти настройки геометрии 5000, я хочу отфильтровать 3.5 триллиона документов на основе 5000 геметрис и дополнительных критериев даты, которые я указываю и агрегировал данные и находил среднее значение. У вас осталось 5000 геометрий и 5000 средних значений для указанных вами критериев даты.

Это в основном JOIN, поскольку я знаю это в SQL, возможно ли это в MongoDB, и это можно сделать оптимально, скажем, менее 10 секунд.

Уточнить: как я понимаю, для этого используется DBrefs, но я читал, что он неэффективен, и имея дело с этим большим количеством данных, это было бы не очень удобно.

Answer 1

Если вы собираетесь иметь дело с геометрией и данные временных рядов вместе, имеет смысл хранить их в одном документе. Годовая стоимость данных с 15-минутным шагом не является убийцей - и вам определенно не нужен документ для каждой записи временного ряда! Поскольку вы можете получить все, что хотите работать как единый документ геометрии, это большая победа. Обратите внимание, что это также позволит вам разобраться в недостающих данных. Вы можете кодировать данные по-разному, если они разрежены, а не индексируются в массив слотов 35040.

A $ geoIntersments на большой куче геометрии данных будет проблемой производительности. Убедитесь, что у вас есть индексирование (например, 2dsphere), чтобы ускорить процесс.

Если есть какой-либо способ, вы можете создать дополнительные критерии в запросе, которые могли бы дешево устранить членов из более дорогого поиска, вы можете сделать вещи более крутыми. Например, скажем, поиск ударит по штатам в США. Вы можете сначала пересечь поиск с границами состояний, чтобы найти состояния, содержащие геоданные, и использовать что-то вроде почтового кода для квалификации документов. Это будет очень быстрый предварительный поиск против 50 документов. Если сначала была определена граница поиска, которая достигла двух состояний, а записи геоданных включали поле состояния, вы просто разведали 96 миллионов записей (при прочих равных условиях) перед более дорогой геометрической частью запроса. Если вы пересекаетесь с небольшими координатами сетки, вы можете продолжить ее до того, как будут рассмотрены геоданные.

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