MongoDB Geo-Spatial Mobile Демо

Монго: существительное (pl mongo или mongos) — денежная единица Монголии. Равный сотой тугрика. Происхождение от монгольского «серебра»

Я написал о СУБД NoSQL [ http://keyholesoftware.com/2012/10/01/is-nosql-the-sql-sequel/ ]. Мы знаем, что существует несколько категорий СУБД NoSQL. MongoDB — это масштабируемое хранилище данных, ориентированное на документы NoSQL, которое имеет встроенную геопространственную индексацию. Давайте посмотрим на его характеристики, а затем посмотрим мобильное демо-приложение.

MongoDB Характеристики

1. Нет схемы Вставленный документ может иметь различные атрибуты. Это обоюдоострый меч, который позволяет быстро менять приложение или легко принимать данные с добавленными или новыми атрибутами с течением времени.
2. Нет языка запросов SQL . Выполните CRUD через API, который использует JSON вместо ввода SQL-запроса.
3. Документ-ориентированный. Просматривайте каждую запись как документ JSON с уникальным ключом в коллекции. База данных содержит коллекции, а не таблицы.
4. BSON. Я разорен MongoDB действительно использует BSON, двоичное сериализованное представление JSON [ http://bsonspec.org/ ]. Документы хранятся как BSON, но JSON входит в MongoDB, а JSON выходит из него. Мы можем думать о данных как о JSON, если только мы не используем привязку к языку, а не можем использовать BSON напрямую.
5. Типы. Существуют строки UTF-8, массивы, встроенные документы, даты, регулярные выражения, логические значения, 64-разрядные числа, идентификатор объекта (OID), двоичный код, временная метка и код JavaScript.
6. Документный запрос. Укажите документ JSON в качестве параметра поиска. Если ни один не предоставил, результатом являются все документы, страница за один раз.
7. Индексируйте любой атрибут документа. Атрибуты являются именами атрибутов JSON.
8. Атомное обновление. Обновления данных стремятся быть на месте. Сервер MongoDB блокирует всю коллекцию до завершения обновления. Если документ должен увеличиваться слишком сильно, запись становится копированием и перезаписью, что медленнее. Мы можем проверить результат. Каждый документ имеет отступы для защиты от чрезмерного копирования и перезаписи.
9. Напишите беспокойство. MongoDB позволяет нам указать заботу о результате операции записи. Следующие все более разборчивые типы проблем с записью дают представление об этой концепции: все ошибки игнорируются, только хорошая запись не подтверждается, журнальная защита в случае отключения сервера или все реплики подтвердили запись.
10. Реплика установлена. Это группа распределенных серверов MongoDB, которые совместно используют один набор данных. Они выбирают мастера. Отработка отказа влечет за собой набор реплики, автоматически выбирающий нового мастера. Это обеспечивает высокую доступность и избыточность.
11. Возможная последовательность. Все члены набора реплик стремятся в конечном итоге синхронизироваться с избранным мастером.
12. Авто-сегментирование. MongoDB масштабируется горизонтально, разделяя коллекцию между серверами. Если мы добавим сервер, MongoDB автоматически перенастроит собранные данные на новый сервер [ http://docs.mongodb.org/manual/sharding/ ].
13. Память сопоставлена . Данные поступают в и из отображенных в память файлов, которые отражают дисковое хранилище.
14. ОСТАЛЬНЫЕ. Сервер mongod предоставляет простой интерфейс REST-запросов только для чтения. Некоторые языковые привязки предоставляют полнофункциональные службы REST [ http://docs.mongodb.org/ecosystem/tools/http-interfaces/#HttpInterface-RESTInterfaces ].
15. Уменьшение карты. Сложные задачи агрегации используют map-Reduce [ http://docs.mongodb.org/manual/core/map-reduce/ ]. Если целевая коллекция отбрасывается, каждый сервер осколков может обрабатывать фрагменты операции уменьшения карты. Думайте о подсчете слов как о тривиальном примере, подходящем для сокращения карты. Здесь все слова в результате запроса сводятся к числу.
16. Aggregation. Структура агрегации позволяет получать агрегированные значения, не прибегая к более сложному сокращению карты. Все документы проходят через конвейер агрегации, где необязательные операторы могут фильтровать данные. Например, одним оператором является $ sort. Выражения без сохранения состояния могут создавать выходные документы из текущего документа в конвейере.
17. GridFS. Файлы любого размера могут храниться в коллекции, расположенной в кусках по 256 КБ на разных серверах. Мы можем поместить чтение в середину файла, не загружая данные полностью в память. Команда mongofiles помогает при работе с файлами GridFS.
18. Геопространственная индексация. Мы можем индексировать любой атрибут. Более того, мы можем индексировать некоторые атрибуты пространственно. Если атрибут состоит из числовых значений 2D или 3D в качестве координат, вы можете индексировать этот атрибут как пространственный индекс 2D или 3D. Координаты обычно являются местоположениями Земли, но игровые сетки работают. Я расскажу больше о геопространственной индексации в следующем разделе.
19. Закрытые коллекции. Мы можем ограничить или ограничить коллекцию так, чтобы самые старые документы исчезали, когда размер коллекции достигает предела ограничения. Это полезно для регистрации и аналитики. Это может сформировать первый набег предприятия на NoSQL.
20. Оболочка. Встроенный командный клиент обеспечивает администрирование и возможность запросов.
21. Консоль HTTP . Я получаю доступ к встроенной веб-консоли через URL-адрес, ориентированный на порт на 1000 выше, чем у сервера mongod. Например, для стандартного порта 27017 на локальном хосте используйте http: // localhost: 28017 / .

Геопространственная база данных

Мне нравится геометрия и карты [ http://keyholesoftware.com/2013/01/28/mapping-shortest-routes-using-a-graph-database/ ]. Я упоминал, что MongoDB поддерживает двухмерные геопространственные индексы. Каждая запись может связать документ с точкой в ​​двухмерном пространстве. Это может быть точка на карте или точка в игровой сетке. MongoDB поддерживает следующие виды данных на основе местоположения, использующих эти индексы:

• Запросы на близость, которые возвращают документы как функцию расстояния до заданной точки.
• Ограниченные запросы, которые выбирают документы, имеющие значения местоположения в данном регионе.
• Точные запросы, которые выбирают документы, соответствующие точным координатам.

Я видел мобильные приложения, которые возвращают списки или карты объектов, расположенных поблизости от моего телефона. Например, см. Gas Buddy [ http://gasbuddy.com/ ]. Как будут работать такие приложения? Я хотел учиться на практике. Казалось, мне нужны пространственные данные и способ запросить близость к месту.

Книга MongoDB в действии , приложение E, посвящена пространственным запросам. Он предоставляет ссылку на сжатый файл массива JSON, подходящий для импорта информации о почтовом индексе [ http://mng.bz/dOpd ]. Каждый объект массива JSON выглядит так:

Этот объект является документом, имеющим город, штат, почтовый индекс, почтовый индекс и координаты xy. У — широта; х долгота. Каждый _id уникален — первичный ключ базы данных. Файл был готов для импорта в MongoDB.

Я установил MongoDB MongoDB, используя инструкции с их сайта [ http://www.mongodb.org/ ]. MongoDB имеет основанную на командах консоль администрирования и запросов mongo . Там я создал геопространственную базу данных. Я запустил команду mongoimport для заполнения базы данных:

Вернувшись к монго, я выдал:

Аргумент «найти» — это документ соответствия JSON. Пустой аргумент find возвращает выгружаемый консольный дамп всех документов, каждый из которых отформатирован, как в примере JSON-документа, который мы видели ранее. Я хотел запросить записи вблизи заданной долготы и широты. Мне нужен был двухмерный пространственный индекс в коллекции zips. Я обратился к MongoDB в книге Action Manning и Руководству MongoDB, чтобы увидеть, как создать геопространственный двухмерный индекс, используя следующее заклинание:

Это дало моей коллекции мозгов мозги для ответа на запросы о близости по предоставленной широте и долготе. MongodDB выполняет магию. Мета-ключ запроса близости MongoDB — $ near . Я хотел, чтобы zip collection Documents $ находился рядом с локацией, которая определяется как объект широты / долготы (т. Е. Y / x) в каждом документе. Например:

Это дало три JSON-документа с почтовыми индексами, ближайшими к координатам моего родного города:

Обратите внимание, что входные данные запроса представляют собой документ JSON. Этот оператор $ near является геопространственной функцией MongoDB. Ограничение (3) — это вызов API фильтрации.

Геопространственный REST сервис

Здорово! Затем мне понадобился сервис REST только для чтения, который мог бы возвращать список записей, соответствующих частичному запросу города с подстановочными знаками. Пользователь может отправить одно из этих полей результирующего документа в другую цель REST, которая будет возвращать список $ рядом с записями, из которых я получу каждый почтовый индекс. Я мог бы использовать консоль Монго, чтобы проверить два запроса.

Я использовал Node.js в качестве HTTP-сервера, потому что его привязка к языку MongoDB обеспечивает полнофункциональную маршрутизацию REST… и потому, что я хотел покончить с Node.js. Это для другой статьи в блоге.

Облако Red Hat OpenShift платформа-как-услуга (PaaS) дало мне свободное место для размещения моего сервиса. У него есть набор «картриджей», из которых можно выбирать. К ним относятся MongoDB и Node.js. OpenShift имеет развертывание на основе Git вместе с SSH-оболочкой, в которой я могу запустить оболочку mongo. Я импортировал базу данных в экземпляр MongoDB, резидентный в моем облаке. Я написал простой REST-сервис Node.js, основанный на трех запросах MongoDB. Я развернул его в OpenShift с помощью команд Git.

На этом этапе я мог протестировать свои REST-сервисы с помощью браузера или команды curl. Примеры URL приведены ниже. Нажмите на них, чтобы увидеть результаты JSON.

• Список городов с названиями, содержащими KANS… https://geospatial-mauget.rhcloud.com/cities/KANS
• Список мест рядом с почтовым индексом 27516… https://geospatial-mauget.rhcloud.com/near/zip/27516
• … который перенаправляет на список мест рядом с широтой / долготой почтового индекса 27516 … https://geospatial-mauget.rhcloud.com/near/lat/35.579952/lon/78.790807

Мобильное геопространственное приложение

Моему REST сервису нужен был клиент. Я дал моему серверу Node.js дополнительный маршрут, который просто возвращает кешированную статическую страницу index.html. Эта страница содержит одностраничный клиент jQuery-Mobile для сервиса. Физическая страница охватывает контроллер и представление, реализованные в виде HTML5, CSS и jQuery Mobile JavaScript для этого простого приложения.

На странице выполняются вызовы AJAX REST на основе касаний пользователя. Затем он отображает возвращенный JSON. Первая логическая страница стоит перед поисковым таргетингом с опережением по типу запроса номер один выше. См. Рис. 1 и рис. 2. Каждый пользовательский символ ввода вызывает запрос в оба конца к MongoDB, отображая список местоположений. Коснитесь любой строки результатов поиска, чтобы отобразить вторую логическую страницу. Обратитесь к рисунку 3. Он использует запрос два, чтобы запросить широту / долготу данного почтового индекса. Этот запрос всегда вызывает перенаправление на запрос три, чтобы получить список результатов $ near для широты / долготы. Я использовал перенаправление на сервере вместо добавления кода к клиенту для выдачи запроса 3. Таким образом, клиент запрашивает и получает список близлежащих почтовых индексов города, никогда не имея дело с широтой / долготой.

На этом этапе цикл запрос-ответ покидает MongoDB. Служба перенаправляет на Карты Google, чтобы отобразить эти $ близкие результаты на карте. Каждый пин-код карты представляет собой почтовый индекс, ближайший к выбранному почтовому индексу. Прикосновение булавки выскакивает информацию об этом почтовом индексе. Google и немного JavaScript выполняют эту магию пост-монго.

Рисунок 1: Панель запуска демо

Вы можете клонировать или скачать архив с исходным кодом на GitHub: https://github.com/mauget/geospatial-mongodb . Варианты загрузки клона репозитория или файла Zip находятся в правом нижнем углу этой страницы. Вам потребуется собственный ключ API Карт Google, иначе ваша копия не будет работать с Картами Google.

Вы можете попробовать мое размещение на https://geospatial-mauget.rhcloud.com/ . Его расположение статично, поэтому в телефоне он выглядит лучше. Для поддельного телефона попробуйте http://iphone5simulator.com/ . Снимаю шляпу перед Red Hat за предоставление облачной службы OpenShift PaaS «вы получаете три приложения бесплатно», которая размещает эту демонстрацию, не переводя ее в спящий режим после часа простоя.

Что хорошего в этом?

Это приложение является демо. Учтите, однако, что вы можете преобразовать коллекцию местоположений в более детальную коллекцию бизнес-адресов вместо грубой коллекции почтовых индексов и групп почтовых индексов. Каждое предприятие может зарегистрировать документ, имеющий широту / долготу GPS своего уличного адреса вместе с деловой информацией. Документ может представлять собой автозаправочную станцию, объект недвижимости, ресторан, парк, карту погоды, ресторан и его кухню … все, что полезное приложение хочет представить географически вблизи точки на Земле. Некоторые деловые документы могут иметь различные атрибуты, например тип кухни в ресторане. Схемы нет, поэтому приложение должно обрабатывать атрибуты маршрута или игнорировать их.

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

Почему MongoDB? Реляционные СУБД имеют пространственные API, в том числе Oracle и DB2. Пожалуйста, перечитайте характеристики MongoDB в верхней части этой статьи. Похоже, что MongoDB подходит для больших отзывчивых данных. Распределенная реляционная СУБД, в конечном счете, ударит по стене в управлении транзакциями между репликами при попытке масштабирования до некоторой точки. Мы не заботимся о транзакциях для такого рода приложений. Конечная согласованность является приемлемым компромиссом, если мы получаем взамен легко расширяемое горизонтальное и вертикальное масштабирование. Есть телефоны и планшеты, нумерация которых похожа на песчинки, которые могли бы вытащить из этого вида приложений.

— Лу Може, [email protected]

Рекомендации:

• Статья в Википедии: http://en.wikipedia.org/wiki/MongoDB
• Руководство MongoDB: http://docs.mongodb.org/manual/
• 2d индексы MongoDb: http://docs.mongodb.org/manual/core/geospatial-indexes/
• MongoDB в действии, авт. Кайл Банкер, паб. Мэннинг, © 2012, ISBN 9781935182870
• OpenShift: https://www.openshift.com/
• Node.js: http://nodejs.org/
• JQuery Mobile: http://jquerymobile.com/
• Git команды: http://git-scm.com/docs
• Справка GitHub: https://help.github.com/
• Является ли NoSql продолжением SQL ?: http://keyholesoftware.com/2012/10/01/is-nosql-the-sql-sequel/

CodeProject