Филиппов Владислав

Начало эксперимента. После подключения к серверу базы PostgreSQL/PostGIS я сразу же начал сравнивать. Суть происходящего - скорость выборки пространственных данных из двух различных по идеологии СУБД: реляционной PostgreSQL/PostGIS и NoSQL-базы MongoDB. Так вот, и в реальном приложении PostgreSQL/PostGIS тоже оказалась быстрее.  Я понимаю, что нужно больше данных, что нужно горизонтальное масштабирование у MongoDB, что на вставке MongoDB по объективным причинам будет быстрее, но мне интересно было именно то что я делал - выборка по расположению и демонстрация выбранного на карте. Таблица 1. Время выполнения запросов: СУБД Масштаб карты Кол-во объектов Время, мс PostgreSQL/PostGIS 9 6 050 9 422 PostgreSQL/PostGIS 8 24 182 9 437 PostgreSQL/PostGIS 7 76 611 12 406 MongoDB 9 5 921 42 725 MongoDB 8 23 890 44 149 MongoDB 7 96 811 48 083 Таблица 2. Время выполнения запросов с ограничением: СУБД Масштаб ка...

Первое что выдал гугл - http://www.mkyong.com/mongodb/how-to-run-mongodb-as-windows-service/ В моём случае: mongod --dbpath "D:\data\research\mongobase\data" --logpath "D:\data\research\mongobase\logs.txt" --install --serviceName "MongoDB" Вот результат:

Решил поэкспериментировать, что будет работать быстрее с пространственными данными: новомодная NoSQL MongoDB или "классика" PostgreSQL/PostGIS? NoSQL, в том числе, хороши в работе с большими объёмами данных. Правда с использованием кластера с несколькими инстансами СУБД. Всё что я смог создать большого это 10 миллионов точек в GRASS GIS: 30 секунд на настройку и несколько минут на создание набора точек. Затем экспорт этого набора в PostgreSQL 9.3/PostGIS 2.0.1, а от туда через GeoJSON в MongoDB 2.6. Файл с GeoJSON весит 1,6 Гб. Для обоих наборов были созданы пространственные индексы.