Почему хранилища документов, такие как Lucene/Solr, не включены в разговоры NoSQL?

В последнее время все мы столкнулись с недавней рекламой решений без SQL. MongoDB, CouchDB, BigTable, Cassandra и другие были указаны как опции без SQL. Вот пример:

http://architects.dzone.com/articles/what-nosql-store-should-i-use

Тем не менее, три года назад один из сотрудников и я использовали Lucene.NET как то, что похоже на описание no-SQL. Мы не использовали его только для пользовательских поисковых запросов; мы использовали его, чтобы сделать несколько переиндексированных данных таблицы РСУБД чрезвычайно результативными. Для управления этими индексами и обеспечения их возможности мы реализовали нашу собственную службу сортировки по стандарту .NET. Когда я покинул компанию, команда переключилась на Салра. (Для тех, кто не в курсе, Solr - это веб-сервис, который переносит Lucene с запросами REST-запроса и дампами индексов.)

Я не понимаю, почему Solr не учитывается в типичных списках вариантов решения no-SQL? Я что-то упустил? Я предполагаю, что есть технические причины, по которым Solr не сопоставим с подобными CouchDB и т.д., И на самом деле я понимаю, что CouchDB использует Lucene как хранилище данных (да?), Но что лишает Solr?

Я не спрашиваю, как какой-то фанат Solr или что-то еще, я просто не понимаю, почему Solr и тому подобное не соответствуют определению no-SQL, и если Solr технически соответствует определению, то что это, вероятно, заставляет людей пух-пух его? Я спрашиваю, потому что мне сложно определить, следует ли мне продолжать использовать решения на основе Lucene (например, Solr) для решений, которые я создаю, или если я действительно буду делать больше исследований с этими другими вариантами.

Ответ 1

Я когда-то слушал интервью с автором Урсулы К. Ле Гуин о художественной литературе. Интервьюер спросил ее об авторах, которые работают в разных жанрах письма. Что делает одного автора писателем-романтиком, а другой - писателем-загадкой, а другим - писателем-фантастом? LeGuin ответил, объяснив:

Жанр - это маркетинг, а не контент.

Это было откровенное выражение.

Я думаю, что то же самое относится к технологическим решениям. Движение NoSQL привлекает внимание, потому что оно полностью поглощает энергию маркетинга прямо сейчас. В хранилищах данных NoSQL, таких как Hadoop, CouchDB, MongoDB, есть коммерческие предприятия, поддерживающие их, продвигая свои решения как новые, новаторские и захватывающие, чтобы они могли развивать свой бизнес. Термин "NoSQL" является маркетинговым брендом, который помогает им объяснить их ценность.

Вы правы в том, что Lucene/Solr технически очень похожа на хранилище документов NoSQL: это денормализованный пакет документов (их термин) с полями, которые не обязательно согласованы между коллекцией документов. Он индексируется сложным способом, позволяющим выполнять поиск по всем полям или по определенным полям.

Но это не тот жанр, который использует Луцен, чтобы объяснить его ценность. У них нет той же миссии по развитию рынка и бизнеса, поскольку они управляются Apache Foundation. Они с удовольствием сосредоточены на использовании полнотекстового поиска, хотя технология может использоваться и другими способами. Они следуют принципу успеха программного обеспечения: сделайте одно и сделайте это хорошо.

Ответ 2

После выполнения большего поиска Google, я считаю, что этот документ достаточно хорош:

https://web.archive.org/web/20100504055638/http://www.lucidimagination.com/blog/2010/04/30/nosql-lucene-and-solr/

Дело в том, Lucene/Solr является NoSql и может считаться одним из более зрелых "предков" NoSql. Он просто не получает шумиху NoSql, которой она заслуживает, потому что она не придумала термин "нет-SQL", и ее пользователи не используют этот термин, поэтому машина hype игнорировала его.

Ответ 3

Я думаю, что самая важная характеристика solr/lucene, которая выпадает из списка nosql, потому что до недавнего времени работа lucene как системы в реальном времени была болью. Обычный рабочий процесс для любого приложения-исполнителя заключался в индексировании инкрементных обновлений в пакетах и, например, обновлении индекса каждые 5 минут.

Ответ 4

Я думаю, что stimpy77 отчасти прав на NoSQL, являющемся брендингом. Но также, NoSQL означает, что это платформа хранения данных, которая проще и проще, чем решения на базе SQL. И я думаю, что в то время как Solr/Lucene разделяют некоторые аспекты (они хранят данные), он действительно не замечает, что Solr/Lucene можно использовать в качестве основного хранилища данных для всего, что имеет отношения. Конечно, в него можно бросить много документов, и мощный поиск отбросит их. Но как только вы хотите отношения, другие, такие как CouchDB и другие, делают намного лучше, у которых есть синтаксис запроса. В этом случае поиск - это бандатное решение. Подумайте о прецеденте "найдите все документы, помеченные словом" автомобиль ". Если у меня есть некоторые структуры в моих данных, тогда мне легко получить документ для машины с меткой и вернуть всех. В сравнении с поисковым запросом, который включает fq = tag:" автомобиль". Поиск становится все более мощным, чем меньше отношений у вас есть, но чем больше отношений, тем лучше хранилище данных, например CouchDB и братья. Вот почему вы все еще видите CouchDB и друзей в паре с Solr, и наоборот! Пусть каждый делает то, что он делает лучше всего.

Конечно, это не значит, что вы не можете использовать ваши исходные данные в Solr, это может быть мощный инструмент для использования!

Ответ 5

Основные различия между no sql и solr в операционных мудрах следующие, на мой взгляд.

Solr требует промежуточного хранилища данных (базы данных или файлы XML), в то время как nosql - прямое хранилище данных.
Вы не можете делать постоянную запись в solr (похоже, что solr 4.0 поддерживает эту поддержку), и вы можете индексировать максимум в каждые 2 минуты и 200 записей (что очень медленно для записи с высокой пропускной способностью, и вы вынуждены промежуточное хранилище).
Вам необходимо изменить/определить схему при изменении того, что хранится в документе. NoSQL не имеет таких определений.
Индексы Solr имеют производительность, когда его размер индекса растет, тогда как NoSQL оптимизирован для него (или утверждает, что он:))
Solr содержит лежащие в основе алгоритмы поиска lucene, но в NoSQL вам нужно их построить. Это относится к великолепному грандиозному поиску или быстрому поиску документов, предоставляемых solr.

Ответ 6

Последнее, но несколько баллов, о разнице, не упомянутой здесь в качестве маркетинговой стратегии, в которой solr выходит из NoSQL

Lucene/Solr - Iam будет использовать Solr, так как Solr использует lucene внутри и имеет дополнительные функции. Итак, Solr - это, в основном, обновление до Lucene с новым контуром.

Solr в основном используется для создания фасетов и индексирования простых текстов для поисковой системы.
Solr может использовать большинство баз данных для хранения своих данных. Неправильно хранить данные в solr, так как он напрямую использует диски.
Базы данных NoSQL просты в освоении по сравнению с Solr. Solr более или менее имеет множество конфигураций и понятий (например, поля).
Производительность - это то, что мы должны рассмотреть b/w. Solr обеспечивает высокую производительность по сравнению с другими базами данных NoSQL.

Примечание. Объединение Solr с некоторыми базами данных обеспечивает лучшую производительность.

Резюме: Solr также является хранилищем NoSQL, который является предшественником всех баз данных NoSQL. Который не обманывал других. Но все еще в поле из-за его производительности и мощности.