プロジェクトの次の段階として、次のNoSQLデータベースを検討しています。
Elasticsearch は主に高度な検索シナリオに対応するものとして位置付けられ、RavenDB はドキュメント指向のデータベースとして位置付けられます。
主に、ドキュメントはビデオに関するものになります。それぞれに自然なIDがあります。それがドキュメントのキーになります。
その周りに、必ずしもスカラーまたはフラットではないフィールドに他のコンテンツを追加します。情報は、さまざまな構造を持つさまざまなソースから取得されるためです。
たとえば、ビデオ プロバイダーの Atom フィードからのコンテンツ、ビデオが埋め込まれたブログ投稿、データ ウェアハウス プロジェクトからのその他のデータがあります。
すべてのアイテムに一定の構造はありません (実際には、それぞれが非常にドメイン固有です)。それらを関連付ける唯一のものは、上記のビデオの自然キーです。
とはいえ、上記のソリューションのいずれかでこの情報を取得したら、それを使用して多くのことを行いたいと思います。
- ビデオに関する分類を行うために、ランダム フォレストに変数を入力するのに役立つようにそれを選別します。
- Web ベースのフロント エンド (知っておく必要がある場合は ASP.NET MVC) を介して、ビデオの一般的な検索 (ランダム フォレストの結果に基づくのではなく、一般的なフリーテキスト) を提供します。
いくつかの要件があります:
私はおそらく、ASP.NET 共有 Web ホスティング環境にいるでしょう。つまり、マシンは 1 台しかなく、サービスをセットアップするためのアクセス権はありません。埋め込み可能なものは非常に役立ちます。
ASP.NET 環境は IIS でホストされるため、埋め込み可能な側面はアプリ ドメインのリサイクルに耐えなければなりません。
サイトでの検索に役立つ、簡単にファセットできる統計分析の結果に基づいて、新しいインデックスを作成したいと思います。
オートコンプリート機能のサポート (これが「すぐに使える」要求ではないことはわかっていますが、その点に到達できることが重要です)。
豊富な類義語のサポート (私がコンテンツのインデックスを作成しているタイプのビデオには、多数の類義語があります)
Trufflerなどのサービスにもオープンですが、コストについては懸念があります (Truffler の場合、リクエストは西海岸の Web ホストから送信されるため、データ センター間の遅延が少し心配です。または東海岸のバックエンド プロセスから）。
さらに、 1 つのソリューションですべての要件を満たす必要があるとは思いません。私は、ある目的のために 1 つを使用し、別の目的のために別のものを使用することに問題はありません。確かに、移行は最悪ですが、これら 2 つのドキュメント ストア間の移行は少し簡単です (そして、必ずしも同じドキュメント構造を使用するとは思いません)。