Почему хранилища документа как Lucene / Solr, не включенный в переговоры NoSQL?
Все мы столкнулись с недавней шумихой решений NOSQL в последнее время. MongoDB, CouchDB, BigTable, Cassandra и другие были перечислены как опции NOSQL. Вот пример:
http://architects.dzone.com/articles/what-nosql-store-should-i-use
Однако три года назад коллега и я использовали Lucene.NET в качестве, что, кажется, соответствует описанию NOSQL. Мы не использовали его только для введенных пользователями поисковых запросов; мы использовали его для создания нескольких переиндексируемых данных таблицы RDBMS чрезвычайно производительными. Мы реализовали нашу собственную.NET sort-of-equivalent-to-Solr сервис, чтобы управлять этими индексами и сделать их вызываемыми. Когда я оставил компанию, команду переключенными на сам Solr. (Для не знающих, Solr является веб-сервисом, который переносит Lucene с вызываемыми REST запросами и индексными дампами.)
То, что я не понимаю, почему Solr не считается в типичных списках опций решения NOSQL? Я пропускаю что-то здесь? Я предполагаю, что существуют технические причины, почему Solr не сопоставим с подобными CouchDB, и т.д., и на самом деле я понимаю, что CouchDB использует Lucene в качестве своего хранилища данных (да?), но что дисквалифицирует Solr?
Я не спрашиваю как некоторый фанат Solr или что-нибудь, я просто не понимаю, почему Solr и т.п. не соответствуют определению NOSQL, и если Solr технически соответствует, определение затем что относительно него, вероятно, делает людей фу фу им? Я спрашиваю, потому что я испытываю затруднения при определении, должен ли я продолжить использовать находящиеся в Lucene решения (как Solr) для решений, которые я создаю или если я должен действительно провести больше исследования с этими другими опциями.
3 ответа
Я однажды слушал интервью с автором Урсула К. ЛеГуин о художественной литературе. Интервьюер спросила ее об авторах, которые работают в разных жанрах письма. Что делает одного автора писателем романов, другого писателем детективов, а третьего писателем-фантастом? ЛеГин ответил, объяснив:
Жанр связан с маркетингом, а не с контентом.
Это было заявление, открывшее глаза.
Думаю, то же самое относится и к технологическим решениям. Движение NoSQL привлекает внимание, потому что прямо сейчас оно полно маркетинговой энергии.У хранилищ данных NoSQL, таких как Hadoop, CouchDB, MongoDB, есть коммерческие предприятия, которые поддерживают их, продвигая свои решения как новые, инновационные и захватывающие, чтобы они могли развивать свой бизнес. Термин «NoSQL» - это маркетинговый бренд , который помогает им объяснить свою ценность.
Вы правы, Lucene / Solr технически очень похож на хранилище документов NoSQL: это денормализованный пакет документов (их термин) с полями, которые не обязательно согласованы во всей коллекции документов. Он проиндексирован сложным образом, чтобы вы могли выполнять поиск по всем полям или по определенным полям.
Но это не тот жанр, который Lucene использует для объяснения своей ценности. У них разная миссия по развитию рынка и бизнеса, поскольку ими управляет Apache Foundation. Они счастливы сосредоточиться на варианте использования полнотекстового поиска, даже если эту технологию можно использовать и по-другому. Они следуют принципу успеха программного обеспечения: делайте одно - и делайте это хорошо.
После дальнейшего поиска в Google, я думаю, этот документ довольно хорошо резюмирует это:
В данном случае Lucene / Solr является NoSql и может считаться одним из более зрелых «предков» NoSql. . Он просто не получает той шумихи вокруг NoSql, которой он заслуживает, потому что он не изобрел термин «no-SQL», и его пользователи не используют этот термин, поэтому машина для шумихи упустила его из виду.
Я думаю, что stimpy77 частично прав в том, что NoSQL является предметом брендинга . Но также, NoSQL означает, что это платформа для хранения данных, которая проще / проще, чем решения на основе SQL. И я думаю, что хотя Solr / Lucene разделяют некоторые аспекты (они хранят данные), на самом деле неправильно думать, что Solr / Lucene можно использовать в качестве основного хранилища данных для всего, что имеет отношения. Конечно, в него можно бросить много документов, и мощный поиск вытащит их. Но как только вам нужны отношения, тогда другие, такие как CouchDB и другие, намного лучше справятся с тем, у кого есть какой-то синтаксис запроса. В этом случае поиск - банальное решение. Подумайте о варианте использования «найти все документы, помеченные словом« автомобиль »». Если у меня есть какие-то структуры в моих данных, то мне легко получить документ для тега car и вернуть всех обратно. Вместо того, чтобы полагаться на поисковый запрос, содержащий fq = tag: 'car'. Чем меньше у вас связей, тем мощнее поиск становится все больше и больше, но чем больше связей, тем лучше хранилище данных, такое как CouchDB и его братья. Вот почему вы до сих пор видите CouchDB и друзей в паре с Solr, и наоборот! Пусть каждый делает то, что умеет лучше всего.
Конечно, это не значит, что вы не можете использовать хранение исходных данных в Solr, это может быть мощным инструментом!