Найкраща система ГІС для високоефективних веб-додатків - PostGIS проти MongoDB


36

Я працюю над веб / мобільним додатком на основі даних про місцезнаходження. Оскільки я вже знайомий з MongoDB, я виявив, що геопросторове індексування Монго цілком підходить для моїх потреб. Оскільки я в основному маю справу з простою / короткою точкою розташування, індексування Mongo 2d добре для мене.

По дорозі я вибрав PostGIS через його стабільний / зрілий шлях. І його дивовижний набір функцій. Але моя головна стурбованість - це ефективність, оскільки мої дані сильно залежать від місця розташування (в основному 70 - 80% db-дзвінків займаються місцем розташування).

Мені подобається монго за те, що його використовують високоефективні веб-додатки, як уже чотирикутник. Але я бачив, що PostGIS використовується в основному в урядових / корпоративних проектах (в основному, не в Інтернеті / мобільних додатках). Тож я зараз мало збентежений, щоб вибрати правильний GIS db для свого веб-/ мобільного додатка? Є якісь пропозиції?


2
створити просторовий індекс за допомогою postgres / postgis, і ви побачите хороші показники. Але якщо ви щасливіші з MongoDB, тоді продовжуйте це.
Mapperz

Відповіді:


36

Якщо навантаження на запис (вхідний потік даних) потенційно може зростати без обмежень (якщо успіх вашого веб-проекту призведе до того, що кількість записів зростатиме, зростає), тоді йдіть з Монго, оскільки це буде дуже важко архітектувати ваш шлях пишіть вузьке місце в PostGIS / PostgreSQL, як тільки ви переробите можливості єдиного сервера високого класу (який, зауважимо, досить величезний).

Ви можете створити хороші рішення PostGIS / PostgreSQL для великого навантаження для читання (реплікація головного / підлеглого) та для величезних розмірів даних (розділення таблиць), але завантажувати запис важко. Ви вже виклали справу проти Монго та щодо PostGIS, що є значно більшим набором функцій та зрілості коду PostGIS, так що збалансуйте це проти інших проблем.


3
О, і пам’ятайте, "MongoDB - це веб-масштаб". xtranormal.com/watch/6995033/mongo-db-is-web-scale
Пол Рамзі

так, я знаю, що це було дуже смішно (і вдарити прямо в голову, якщо ви просто хотіли пофантазувати найновішими технологіями) :)
RameshVel

1
Що ж, ви завжди можете "нанести масштаб", вимкнувши fsync = вимкнено;)
Рагі Ясер Бурхум

1
Тепер PostgresXC може забезпечити паралельну запису систему з повними гарантіями транзакцій та виконанням запитів на багато вузлів. Ремені та підвіски, OLAP і OLTP, варто подивитися. І він підтримує PostGIS.
Пол Рамзі

Але якщо ви вибрали PostgresXC / XL, вам потрібно буде самостійно підтримувати пакет. Офіційно доступний лише для Fedora / Redhat, любителям Ubuntu доведеться витрачати час на складання речей вручну.
Раві Кумар

21

Я використовую PostGIS кілька років, і лише нещодавно почав досліджувати, як я міг використовувати MongoDB для вирішення певних випадків використання. Я мав справу з точковими даними, які мали розрізнені поля - наприклад, дані OSM з різною кількістю тегів на запис, і оскільки у MongoDB немає схеми, він добре піддається цьому. Я завантажив зразок цих даних в екземпляр кожної БД, і ось що я знайшов.

Мені здається, що для простого зберігання та пошуку точкових даних Mongo працює чудово. Геопросторові запити на обмежувальній шкалі, здається, працюють добре, і я вважаю, що загальна ефективність дуже хороша. Це також дуже просто налаштувати та розпочати роботу, хоча я виявив, що інструмент mongoimport не дозволяє мені визначати складене 2D-поле координати у файлі TSV або CSV. Оскільки написати сценарій, що генерує JSON, досить легко, це не склало особливих проблем. Основним його недоліком на даний момент є те, що майже нічого іншого в геопросторовій царині не може споконвічно читати з нього дані. Здається, що експериментальний плагін джерела даних Mapnik за адресою https://github.com/springmeyer/mapnik-mongo , але це все, що я міг знайти.

З іншого боку, PostGIS потребує трохи більше часу, щоб налаштувати (принаймні, для мене), але, як було сказано вище, він забезпечує можливість отримати більше функцій прямо з коробки. Окрім надання значно складніших можливостей просторової аналітики, він також підтримується цілою низкою інших програм та бібліотек; Mapserver, Mapnik, QGis, GDAL тощо, тощо. Для мене PostGIS - це набагато більше справжня система GIS, а не проста система зберігання та пошуку.

Що стосується продуктивності, то я виявив, що можу дуже швидко отримати дані з обох систем. Однак здавалося, що PostGIS отримав більше вигод від наявності індексів. MongoDB трохи швидше повертав весь набір даних мені (2 мільйони записів) відразу, і трохи повільніше при поверненні запиту, який використовував індекс - перший раз. Я не точно впевнений у механізмі, який він використовує для кешування, але я можу побачити, що якщо повторюю запит у MongoDB, результати повертаються набагато швидше вдруге. Я бачу щось подібне в PostGIS, але не в тій же мірі. Я також зазначив, що споживання пам’яті на моїй машині, здається, значно більший при запуску MongoDB, ніж у PostGIS.

Отже, мій висновок полягає в тому, що я не збираюся позбавлятися від PostGIS як моєї геопросторової системи зберігання та аналізу за замовчуванням, але для певних типів проектів (а саме веб-карт, які відображають плитки зображень та / або дані точок), я можу розглянути можливість використання MongoDB як мій сховище даних.

Роджер


1
я абсолютно з вами згоден .. Монго - це дуже хороший варіант обробки основних геоданих. В даний час я роблю простіші сферичні та обмежувальні запити в області, і це робить добре. Ще одне, що я хочу додати - це Solr люцен, що також забезпечує основні геофункції, як монго, і його досить швидко, коли використовується з гранованими запитами. currenlty я використовую комбінацію як mongo, так і Solr ..
RameshVel

@RameshVel ви могли б сказати щось більше про solr lucene?
rkm

@rashad, ви можете встановити elastsesearch (просто завантажити, витягнути і виконати) та грати з Geo DSL-запитами. Це досить базово, але якщо ви хочете шукати / грані, а також гео, ви можете використовувати його.
Раві Кумар

3

Що стосується використання пам'яті з Mongo, то варто зазначити, що Mongo повністю покладається на кеш файлів ОС, щоб отримати свої індекси та дані в пам'ять - немає поняття "буфер пам'яті / індексу кеш пам'яті", тому ви побачите його спробувати (або скоріше, ОС буде використовувати) всю доступну оперативну пам’ять до тих пір, поки всі ваші файли даних були кешовані.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.