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

GeoJSON и MongoDB: Стоит ли хранить точки как GeoJSON.Point?

С введением 2.3 > MongoDB стал еще более полезен при обработке данных и обработке запросов. MongoDB хранит документы как BSON, поэтому каждый документ имеет все поля документа, что, очевидно, потенциально приводит к большим базам данных, чем наши обычные RMDBS.

Я использовал для хранения полилиний и полигонов в виде ряда индексированных точек с дополнительным полем, представляющим порядок каждой строки (я делал это, чтобы обеспечить согласованность, поскольку я использую JavaScript, поэтому точки не всегда сохранялись в их правильных заказ). Это было примерно так:

polyline: {
  [
    point: [0,0],
    order: 0
  ],
  [
    point: [0,1],
    order: 1
  ]
}

В то время как теперь я использую:

polyline: {
  type: 'LineString',
  coordinates: [
    [0,0],
    [1,0]
  ]
}

Я видел улучшение размера документов, так как некоторые полилинии могут иметь до 500 точек.

Однако мне интересно, какие преимущества могут хранить все мои данные Point как GeoJSON. Меня обескураживает увеличение размера документа, например:

loc: [1,0]

лучше, чем

loc: {
  type: 'Point',
  coordinates: [0,1]
}

и, следовательно, будет легче работать с.

Мой вопрос:

Лучше/рекомендуется хранить точки как объекты GeoJSON в отличие от массива с двумя точками?

Я рассмотрел следующее:

  • Ограничения по размеру: я могу потенциально иметь миллионы документов с местоположением, что может повлиять на размер коллекции и, возможно, на карман.
  • Согласованность. Было бы лучше иметь дело с каждым набором координат в формате lng, lat, а не с привязкой к lat, lng для точек, а первая для всех моих других функций местоположения.
  • Удобство: если я возьму точку и использую с ней $geoWithin или $geoIntersects, мне не нужно будет сначала преобразовывать ее в GeoJSON, прежде чем использовать ее как параметр query.

Я не уверен в следующем:

  • Будет ли поддержка для loc: [x,y] отброшена в будущем на MongoDB
  • Любые преимущества индексации от 2dsphere в отличие от 2d
  • Возможно, какие-либо запланированные дополнения GeoJSON к MongoDB могут привести к необходимости согласованности, упомянутой выше.

Я предпочел бы перейти на GeoJSON, пока мои данные по-прежнему управляемы, чем в будущем в будущем под большим напряжением.

Могу ли я, пожалуйста, просить полностью (хотя бы слегка) продуманный ответ. Я не буду правильно выбирать правильный ответ, поэтому я могу оценить любые ответы.

Я также не уверен, что SO - это подходящее место для постановки вопроса, поэтому, если DBA является более подходящим местом, я переведу туда вопрос. Я выбрал SO, потому что здесь много активности, связанной с MongoDB.

4b9b3361

ОТВЕТЫ

Ответ 1

Я бы рекомендовал использовать новый формат GeoJSON. Несмотря на то, что я не считаю, что было сделано какое-либо выражение об отказе от поддержки старого формата, тот факт, что они относятся к нему как к наследию, должен служить указанием на их мнение.

Есть некоторые преимущества индексации для использования 2dsphere, а не 2d.

  • Во-первых, он фактически вычисляет запросы, основанные на том, что Земля является сферой. Один из недостатков индекса 2d заключается в том, что он не учитывает это значение, что вам придется обрабатывать преобразование самостоятельно, если вас интересует фактическая область, охватываемая запросом, а не основные латинские /lngs.
  • Возможность использовать составные индексы, если вы хотите сделать что-то вроде "получить 100 результатов из этой области, которые были самыми последними", то 2dsphere - ваш единственный выбор.
  • Возможность использования запросов geoIntersects.
  • Геометрические запросы geoWithin требуют, чтобы вы использовали формат geoJSON.

Еще одна важная вещь, которую нужно отметить, - убедиться, что используемый вами запрос поддерживается индексом, который вы используете. Если вы используете 2dsphere, например, вы не можете использовать запрос $box, поскольку он не будет проиндексирован - однако mongo не будет предупреждать вас - результат будет просто выполнять сканирование таблицы и будет очень медленно!

Mongo предоставляет диаграмму совместимости, в которой могут быть использованы запросы с каким индексом

Ответ 2

Да, я думаю, это того стоит. Из моего опыта работы с GeoSpatial Information System лучше всего хранить данные о местоположении в полезном и переносимом стандарте. GeoJSON в MongoDB поддерживает WGS84 стандарт datum.

В MongoDB оператор $near может выполнять поиск по старым координатам 2d и координатам GeoJSON. В старой коллекции координат 2d $near возвращает ближайшую первую отсортированную коллекцию. $geoNear возвращает ближайшую первую отсортированную коллекцию с расстоянием от метаданных найденных точек.

Другим преимуществом является возможность использования других геопространственных запросов (например, $geoWithin и $geoIntersect), особенно если вы сохраняете другие типы GeoJSON (Polyline, Polygon)

Наконец Хотя базовые запросы, использующие сферическое расстояние, поддерживаются индексом 2d, рассмотрите переход к индексу 2dsphere, если ваши данные в основном долготы и широты.

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

Ответ 3

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

примечания к выпуску для mongoose Поддержка GeoJSON (MongoDB >= 2.4) дает следующий пример:

2dsphere индекс по старым координатным парам:

new Schema({ 
    loc: { type: [Number], index: '2dsphere'}
});

GeoJSON запрос на устаревшие пары координат, используя индекс 2dsphere:

var geojsonPoly = { 
    type: 'Polygon', 
    coordinates: [[[-5,-5], ['-5',5], [5,5], [5,-5],[-5,'-5']]] 
};

Model.find({ loc: { $within: { $geometry: geojsonPoly }}});