Lucene / SolrのようなドキュメントストアがNoSQL会話に含まれないのはなぜですか？
最近、SQL以外のソリューションという最近の誇大宣伝に遭遇しました。 MongoDB、CouchDB、BigTable、Cassandraなどは、SQLなしのオプションとしてリストされています。次に例を示します。
http://architects.dzone.com/articles/what-nosql-store-should-i-use
ただし、3年前、同僚と私はLucene.NETをno-SQLの説明に適合しているものとして使用していました。ユーザーが入力した検索クエリだけに使用したわけではありません。これを使用して、いくつかの再索引付けされたRDBMSテーブルデータを非常に高性能にしました。これらのインデックスを管理して呼び出し可能にするために、Solrと同等の独自の.NETソートサービスを実装しました。私が会社を辞めたとき、チームはSolr自身に切り替えました。 （知らない人のために、SolrはLuceneをREST呼び出し可能なクエリとインデックスダンプでラップするWebサービスです。）
私が理解していないのは、なぜSolrが非SQLソリューションオプションの一般的なリストに含まれないのですか？ここで何か不足していますか？ SolrがCouchDBなどに匹敵しない技術的な理由があると思います。実際、CouchDBがデータストアとしてLuceneを使用していることを理解しています（はい？）
私はある種のSolrのファンボーイや何かと尋ねているのではなく、Solrなどがno-SQLの定義に適合しない理由を理解していません。Solrが技術的に定義に適合しているとしたら、それはどうなるでしょう。人々はそれをプープー？私が構築したソリューションに引き続きLuceneベースのソリューション（Solrなど）を使用する必要があるのか、またはこれらの他のオプションを使用してさらに調査を行う必要があるのかを判断するのが難しいので、私は尋ねています。
私はかつて作家のウルスラK.ルギンとのフィクション執筆についてのインタビューを聞いていました。インタビュアーは彼女に、異なるジャンルで執筆している著者について尋ねました。 1人の作家をロマンス作家、もう1人をミステリー作家、そして別の作家をSF作家にしたのはなぜですか。 LeGuinは次のように説明して答えた：
ジャンルはコンテンツではなく、マーケティングに関するものです。
それは目を見張るような声明でした。
同じことがテクノロジーソリューションにも当てはまると思います。 NoSQLムーブメントは、現在マーケティングエネルギーに満ちているため、注目を集めています。 Hadoop、CouchDB、MongoDBなどのNoSQLデータストアには、それらを後押しする商業ベンチャーがあり、ソリューションを新しく革新的でエキサイティングなものとして推進し、ビジネスを成長させることができます。 「NoSQL」という用語はマーケティングブランドであり、彼らがその価値を説明するのに役立ちます。
Lucene/Solrは、技術的にはNoSQLドキュメントストアと非常によく似ています。これは、ドキュメントのコレクション全体で必ずしも一貫していないフィールドを持つ非正規化されたドキュメントのバッグ（その用語）です。すべてのフィールドまたは特定のフィールドで検索できるように、高度な方法でインデックスが付けられています。
しかし、それはLuceneがその価値を説明するために使用するジャンルではありません。彼らはApache Foundationによって管理されているため、市場とビジネスを成長させるという同じ使命はありません。テクノロジーが他の方法で使用されたとしても、彼らはフルテキスト検索のユースケースに焦点を合わせて喜んでいます。彼らは、ソフトウェアの成功という信条に従っています。
さらにGoogle検索を行った後、このドキュメントはかなりうまくまとめていると思います。
適例なのは、Lucene/SolrisNoSqlであり、NoSqlのより成熟した「祖先」の1つと考えることができます。 「no-SQL」という用語を発明せず、そのユーザーがこの用語を使用していないため、それに値するNoSql誇大広告を取得しないだけで、誇大広告マシンはそれを見落としました。
Nosqlリストから削除されたsolr/luceneの最も関連性の高い特性は、最近まで、luceneをリアルタイムシステムとして機能させることが困難であったためだと思います。パフォーマンスの高いアプリケーションの通常のワークフローは、増分更新をバッチでインデックス付けし、たとえば5分ごとにインデックスを更新することでした。
私は stimpy77はNoSQLがブランディングであることに部分的に正しい だと思います。しかし、NoSQLは、SQLベースのソリューションよりもシンプルで簡単なデータストレージプラットフォームであることも意味します。そして、Solr/Luceneはいくつかの側面（データを保管する）を共有しますが、Solr/Luceneが関係を持つあらゆるものの主要なデータストレージとして使用できると考えるのは間違いです。もちろん、たくさんのドキュメントをその中に投げ込むことができ、強力な検索機能によってそれらを元に戻すことができます。しかし、リレーションシップが必要になるとすぐに、CouchDBやその他のクエリ構文を備えた他のものがはるかにうまく機能します。その場合、検索は絆創膏です。ユースケース「Word 'car'でタグ付けされたすべてのドキュメントを検索する」を考えてみてください。データに構造が含まれている場合、タグcarのドキュメントを取得して、全員を引き戻すのは簡単です。また、fq = tag： 'car'を含む検索クエリに依存しています。関係が少ないほど検索は強力になりますが、関係が多いほど、CouchDBや兄弟のようなデータストアは優れています。そのため、CouchDBと友達がSolrとペアになっていることがわかります。逆もまた同様です。それぞれに最善を尽くさせましょう。
もちろん、それはあなたがSolrにソースデータを保存することを活用できないということではありません、それは使用するための強力なツールとなり得ます！
運用面でのno sqlとsolrの主な違いは、私の意見では次のとおりです。
- Solrは中間データストア（データベースまたはXMLファイル）を必要としますが、nosql自体はストレートデータストアです。
- Solrへの一定の書き込みを行うことはできず（Solr 4.0はそのサポートをもたらすようです）、最大2分と200レコードの最大でのみインデックスを作成できます（これは、高スループットの書き込みでは非常に遅く、中間ストレージを強制されます）。 。
- ドキュメントに保存されているものを変更する場合は、スキーマを変更または定義する必要があります。 NoSQLにはそのような定義はありません。
- Solrインデックスは、インデックスサイズが大きくなるとパフォーマンスに影響しますが、NoSQLはそれに最適化されています（または:)
- Solrには基礎となるlucene検索アルゴリズムがバンドルされていますが、NoSQLではそれらを構築する必要があります。これは、solrが提供する壮大なファセット検索または非常に高速なドキュメント検索に適用されます。
最後にいくつかのポイント、その違いは、solrがNoSQLから出るマーケティング戦略としてここで言及したものではありません。
Lucene/Solr-Solrを内部で使用し、追加機能があるため、IamはSolrを使用します。したがって、Solrは基本的にLuceneを新しいコンポーネントでアップグレードしたものです。
Solrは主に、ファセットを作成し、検索エンジンのプレーンテキストにインデックスを付ける目的で使用されます。
Solrは、ほとんどのデータベースを使用してデータを保管できます。直接ディスクを使用するため、データをsolrに保持することは一貫していません。
NoSQLデータベースは、Solrに比べて習得が容易です。 Solrは多かれ少なかれ多くの構成と概念を持っています（例：フィールド）。
パフォーマンスはb/wを考慮しなければならないものです。 Solrは、他のNoSQLデータベースと比較して高いパフォーマンスを提供します。
注： Solrをいくつかのデータベースと組み合わせると、最高のパフォーマンスが得られます。
概要： Solrは、すべてのNoSQLデータベースの前身であるNoSQLデータストアでもあります。他の人の誇大宣伝を得られなかった。しかし、そのパフォーマンスとパワーにより、まだフィールドにいます。