Базы данных NoSQL проникают в основные технологические компании, особенно в приложения для определения местоположения. Но они мало обсуждались в геопространственных СМИ. После того, как несколько десятков активных и увлеченных ГИС-практиков (включая моих аспирантов в Пенсильванском университете) подтвердили, что они не слышали о термине «NoSQL», я подумал, что пришло время представиться.
Что такое NoSQL?
Как красноречиво пишет в своем блоге Пол Рэмси, базы данных NoSQL не являются «против» SQL. Вместо этого их, возможно, правильнее охарактеризовать как «не SQL». То есть они действуют иначе, чем язык структурированных запросов, SQL/реляционные базы данных, которые многие читатели используют и используют в течение некоторого времени.
Что отличается? В Википедии говорится: базы данных NoSQL «могут не требовать фиксированных схем таблиц, обычно избегают операций соединения и обычно масштабируются по горизонтали». Это означает, что у некоторых нет строгих структур (схем), некоторые избегают объединения записей из нескольких таблиц на основе значений комментариев в одном поле (что мы часто делаем в ГИС!), а некоторые масштабируются просто за счет добавления дополнительного оборудования. Ключевым моментом здесь является то, что разные базы данных NoSQL имеют разные сильные стороны в зависимости от их архитектуры. Не существует универсальных свойств, которыми будет обладать каждая база данных NoSQL.
Существует научное направление, которое рассматривает SQL/реляционные базы данных как подмножество «структурированного хранилища» — так называются предложения NoSQL. Еще один момент: базы данных NoSQL часто классифицируют по «типу хранилища данных», например «хранилище документов», «хранилище ключей/значений», «табличное» и т. д. Я не буду здесь рассматривать эти различия, но у GigaOm есть хорошая таблица. в качестве отправной точки для понимания различий.
Зачем вам такая база данных?
Короче говоря, потому что SQL/реляционные базы данных не так хороши для некоторых задач, таких как «индексирование большого количества документов, обслуживание страниц на веб-сайтах с высокой посещаемостью и доставка потокового мультимедиа». (Википедия).
Решения NoSQL особенно хорошо справляются с большим количеством задач чтения/записи, поступающих одновременно, что имеет тенденцию замедлять работу SQL/реляционных баз данных. Я думаю, что перечисление всего трех компаний, использующих решения NoSQL, помогает определить «много-много задач чтения и письма»: Facebook, eBay, Google.
Джо Стамп из SimpleGeo признает, что можно использовать SQL/реляционные базы данных для того, что могут делать базы данных NoSQL. Для него решение использовать NoSQL связано с деньгами.
Как насчет геопространственных данных?
Некоторые решения NoSQL включают поддержку геопространственных данных либо изначально, либо с помощью расширения. Другие не предназначены для геопространственных приложений, но были реализованы для поддержки геопространственных данных. Некоторые базы данных NoSQL, используемые в настоящее время для управления геопространственными данными, включают: MongoDB (с открытым исходным кодом), BigTable (разработанную Google, проприетарную, используемую в Google Earth), Cassandra (разработанную Facebook, теперь с открытым исходным кодом и поддерживаемую Apache), CouchDB (с открытым исходным кодом). , Апач).
Кто использует NoSQL для геопространственных задач?
Foursquare: MongoDB
SimpleGeo: Cassandra
Где: MongoDB
Scrabbly: MongoDB (многопользовательская игра Scrabble)
Google Earth: Google Big Table
PDX API (API для Инициатива открытых данных города Портленда, штат Орегон): CouchDB (GeoCouch)
Как мне узнать, следует ли мне использовать NoSQL?
Этот вопрос не должен решаться отделом маркетинга или менеджмента без консультации с опытной командой разработчиков. Я полагаюсь на экспертов, которые говорят: «Это зависит!»
Пол Рэмси предполагает, что базы данных NoSQL ценны в «варианте использования с большими объемами и высокой доступностью, который появился в эпоху потребительских веб-сервисов». Но он признает: «Хотя бесплатного обеда не бывает. В обмен на высокую пропускную способность/доступность вы теряете выразительность [богатство] и мощь SQL».
Юрг ван Влит предлагает следующее наблюдение и совет, размышляя о хранилище больших точек интереса (POI):
Традиционным решением для хранения информации является реляционная база данных. Но реляционные базы данных были разработаны для другой эпохи, для другой инфраструктурной парадигмы. Масштабирование Oracle на мейнфрейме — это нормально, вы можете добиться отличной производительности. Но построить что-то большое из обычных компонентов инфраструктуры гораздо сложнее. Вот почему в последнее время NoSQL начинает привлекать к себе так много внимания. NoSQL делает уступки реляционной части информации, чтобы ее можно было масштабировать, распределяя информацию вокруг.
Так что, если вы не хотите покупать несколько мейнфреймов для своего магазина POI, вам придется прыгнуть на подножку RDBM. Однако NoSQL не является универсальным контейнером хранилищ данных. Существуют подходы к веб-сервисам, такие как Amazon SimpleDB. Отлично подходит для хранения большого количества пар ключ/значение, хорошо подходит для извлечения простых выборок, но не так хорош для сложного поиска. Кроме того, у вас есть задержка, потому что это веб-служба.
Еще один момент, касающийся использования NoSQL, согласно Полу Рэмси, заключается в том, что, вероятно, многие разработчики будут использовать NoSQL для пространственных функций без реального использования базы данных. Вместо этого они будут использовать локальную или размещенную службу. Он предлагает следующие примеры: хранение данных в таблицах Google Fusion, использование SimpleGeo API и использование пространственных типов в Google App Engine. «Это все случаи их использования [баз данных NoSQL] без их использования. Вы сразу видите ограничения в типах запросов, которые вы можете выполнять (не так много), но вы пожинаете плоды, перекладывая ответственность за инфраструктуру на кого-то другого».
Что ждет нас в будущем?
Гуру баз данных Майкл Стоунбрейкер, как сказал в 2005(!) гуру баз данных Майкл Стоунбрейкер, должен ожидать «усиления фрагментации технологий баз данных в зависимости от вариантов использования». Итак, ожидайте больше возможностей в области базы данных, а не меньше. И, добавлю, ожидайте больше возможностей (встроенных и расширенных) для хранения и управления геопространственными данными в этих новых предложениях.
