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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 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, которого он заслуживает, потому что он не изобрел термин «no-SQL», и его пользователи не используют этот термин, поэтому машина обмана упустила его из виду.

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

• Solr в основном используется для создания фасетов и индексации простых текстов для поисковой системы.

• Solr может использовать большинство баз данных для хранения своих данных.Хранить данные в solr непоследовательно, поскольку они напрямую используют диски.

• Базы данных NoSQL легко изучить по сравнению с Solr.Solr более или менее имеет множество конфигураций и концепций (например, для полей).

• Производительность - это то, что мы должны учитывать ч / б.Solr обеспечивает высокую производительность по сравнению с другими базами данных NoSQL.

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

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