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 объектов, а не как массив из 2 точек?

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

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

В чем я не уверен:

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

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

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

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


database mongodb gis wgs84
person nevi_me    schedule 21.04.2013    source источник

Ответы (3)


arrow_upward
17
arrow_downward

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

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

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

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

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

person whostolebenfrog    schedule 28.05.2013
comment
Я принимаю твой ответ. Ваш второй пункт меня убеждает. Я читал об этом, но забыл, что теперь я могу использовать составные индексы в 2dsphere. - person nevi_me; 01.06.2013

arrow_upward
4
arrow_downward

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

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

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

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

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

person avelis    schedule 16.05.2013
comment
Исходя из моего опыта, я могу использовать все геозапросы Mongo с устаревшей парой, включая $geoNear. Так что я не заметил никакой разницы в типах запросов. У меня есть другое приложение, которое использует GeoJSON для всех данных о местоположении, поэтому я говорю о сравнении между ними. Я храню данные о точках в формате lat, lng и написал утилиту, которая преобразует GeoJSON в массив и обратно. Так что от удобства это не имеет значения. Меня больше беспокоит будущая совместимость с Mongo 2.6 и так далее - person nevi_me; 17.05.2013

arrow_upward
2
arrow_downward

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

примечания к выпуску для < strong>Поддержка 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 }}});
person Steve Lorimer    schedule 26.05.2014