Как некоторые из моих читателей знают, что я теперь работал с двумя базами данных документов: IBM pureXML , собственная база данных XML, построенная на основе реляционного механизма (предназначенного для каламбура), который предлагает как реляционные ( SQL / XML ), так и неструктурированные ( XQuery ) языки запросов, и MarkLogic , база данных, созданная с нуля на основе новой парадигмы базы данных (назовите ее NoSQL, если хотите), которая понимает неструктурированные данные и предлагает неструктурированный язык запросов ( XQuery ).
Еще одна важная информация — это новая тенденция среди поставщиков баз данных NoSQL для реализации SQL (или SQL-подобных интерфейсов). Примером может служить недавнее продвижение Cassandra с CQL или даже более зрелые интерфейсы SQL на основе Hadoop . Я вижу в этом NoSQL, пытающийся развивать предприятие, что в целом хорошо.
Я не собираюсь спорить о том, делают ли эти поставщики NoSQL правильный выбор с SQL, или даже говорить о том, что предприятие — это больше, чем просто использование интерфейса SQL. Я также не буду обсуждать, почему некоторые модели данных лучше подходят для SQL, чем другие, например, Cassandra против MongoDB (но если вы хотите обсудить эти темы, просто оставьте комментарий) .
В этом посте я сосредоточусь на некоторых уроках, полученных при смешивании миров реляционных и неструктурированных баз данных.
Когда сталкиваются два мира
NoSQL о No SQL . Для меня это означает смещение акцента в сторону нереляционных альтернатив баз данных, которые могут даже исследовать различные интерфейсы к базе данных (и не заботиться о политкорректности) . Это хорошая вещь! Слепо признавая слабость SQL ради предпринимательства? Что ж, даже если SQL является правильным выбором для вашего продукта, вам все равно нужно подумать о последствиях и убедиться, что вещи хорошо согласованы между двумя мирами. Другими словами, это означает удаление «слепой» части и снижение «отстойности» до приемлемого минимума для ваших разработчиков.
Но будьте осторожны: все станет грязно. SQL не хорош, и он собирается столкнуться с удивительным неструктурированным грузовиком (слегка предвзятым) !
Модель данных
В реляционном у вас есть:
RowSet -> SQL -> RowSet
RowSet это что-то вроде:
RowSet -> Item+ Item -> INT | VARCHAR n | ...
Я не знаю о модели данных для JSON, поэтому я расскажу о модели данных, с которой я довольно хорошо знаком: модель данных XPath:
XDM -> XPath/XQuery -> XDM
И XDM это что-то вроде:
XDM -> Item+ Item -> AtomicType | Tree AtomicType -> integer | string | ... ...
(Оба эти определения упрощены, но служат цели) .
Отличительной особенностью модели данных для документа является то, что деревья не плоские:
{
"namespace": "person-2.0",
"comments": "This guy asked me for a dinosaur sticker. What a nutter!",
"person": {
"handle": "dscape",
"comments": "Please do not send unsolicited mail."
}
}
Таким образом, существует множество толкований того, что это может означать:
SELECT comments from PERSON where handle = "dscape"
К какому элементу «comment» относится запрос? Если вы посмотрите на SQL / XML (что ужасно, ужасно), ваш запрос будет выглядеть примерно так:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Что приводит меня к такому очевидному выводу: деревьям нужен способ навигации. В XML это XPath , в JSON возможно это будет JSONSelect , может быть что-то еще. Но вам все еще нужен стандартный способ навигации в первую очередь.
Что делает эту задачу еще более интересной, так это управление версиями и развитие схемы. Несмотря на то, что это игнорировалось целую вечность в реляционном мире (с серьезными последствиями для бизнеса из-за простоя в эти забавные моменты изменения таблицы) , это действительно, действительно, ДЕЙСТВИТЕЛЬНО нельзя игнорировать для документов. Подумайте о Microsoft Word — сколько разных версий документов они поддерживают? Word 2003, 2005 и т. Д.
Без схемы, гибкость, неструктурированность: выберите свое слово, но все они поддаются быстрой эволюции форматов данных. В этом запросе мы предполагаем, что дескриптор — это дитя человека, и что комментарии о том, что я идиот, являются прямым потомком дерева. Это обязательно изменится. А SQL не поддерживает версионность документов, поэтому вам придется расширять его, чтобы он работал.
Настоящий язык запросов для неструктурированных данных должен учитывать версию. В XQuery мы можем выразить этот запрос как что-то вроде:
declare namespace p = "person-2.0" ;
for $person in collection('person')
let $comments-on-person := $person/p:comments
where $person/p:handle = "dscape"
return $comments-on-person
Frankenqueries по примеру
Кто-то однажды упомянул меня (говоря о SQL / XML) как эти Frankenqueries. Термин прилип к моей голове до сих пор. Давайте рассмотрим эту аналогию немного дальше и поищем места, где органические части и болты собираются вместе.
Давайте представим два списка покупок, один для Джо и один для Мэри
marys-shopping.json
{ "fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{ "fruit": {
"apples": 6,
"oranges": 1
} }
Теперь с моим «воображаемым» расширением SQL / JSON, я делаю:
SELECT apples FROM LISTS
Что это возвращает? Помните, RowSet входит, RowSet выходит?
2, 5 --- 6
Таким образом, даже если вы явно запрашиваете список количеств яблок, вы получаете два набора строк вместо трех, и один из наборов строк будет иметь список количеств. Если вместо этого вы решите вернуть три вещи, у вас появятся два набора RowSet и три набора RowSet. Я не математик, но это звучит не очень хорошо.
Еще раз, это не проблема, если вы используете что-то, что может иметь дело с неструктурированной информацией. У вас нет этой проблемы в javascript и, конечно, не будет в XQuery. И в javascript, и в XQuery все это органично. (или болты, если вы предпочитаете)
Вывод: потрясающие языки для неструктурированных данных, единорогов и пикси-пыли!
Хотя XQuery — отличный язык для неструктурированной информации, моя точка зрения здесь не защищает ее использование. Суть, которую я пытаюсь подчеркнуть, заключается в необходимости реального языка неструктурированных данных, каким бы вы (читай: разработчики) не выбрали его.
Но я прошу вас (разработчиков) не принимать обратно «отстойность SQL». Она ушла, и у вас есть новое горячее свидание под названием NoSQL. Просто дайте ему немного времени, и он будет расти на вас. Кроме того, очень весело писать код JavaScript, который работает в базах данных: не позволяйте им отнять это у вас.
SQL для неструктурированных данных потерпит неудачу. Тогда PL-SQL для неструктурированных данных потерпит неудачу. Так что, если поставщик настаивает на том, что вам нужно, не соглашайтесь на что-либо меньшее, чем полноценный язык программирования: вы можете написать свое полное приложение в javascript и сохранить его в CouchApp , или вы можете написать свое полное приложение в XQuery и сохранить его в MarkLogic. И так и должно быть!
Вот контрольный список того, что нужно искать на языке запросов для неструктурированной информации (не стесняйтесь предлагать еще) :
- Язык навигации
- Модель данных
- Обычные выражения
- Лямбда
- Функции высокого порядка
- Функциональный аромат
- Хорошая обработка строк
- Модули, чтобы вы могли создавать свои собственные библиотеки
- Сервер приложений осведомлен: имеет функции, которые обслуживают REST
Вы можете игнорировать этот совет, но в конечном итоге вы можете почувствовать себя разочарованным разработчиком Silverlight . И мы, ребята, которые любят вводить новшества в базы данных, будут разочарованы тем, что разработчики приняли решение вернуться назад!
Увидимся на Open Source Bridge
Если вы хотите больше поговорить на эту тему, я бы хотел пригласить вас присоединиться ко мне , J Chris Anderson ( CouchDB ) и Roger Bodamer ( MongoDB ) в Open Source Bridge в Портленде в этом месяце. Мы будем устраивать дискуссию о моделировании данных в сеансе под названием No More Joins . Так что заходите на регистрацию и увидимся там!
Источник: http://writings.nunojob.com/2011/06/why-sql-sucks-for-nosql-unstructured-databases.html