NoSQLデータベースは私に適していますか？
私はWPFアプリケーションを開発しています。そのコア機能には、ユーザーが特定の部分を変更してデータベースに保存できる大きなオブジェクトグラフ（多くの場合、数万のエンティティ）の作成が含まれます。グラフは、後で取得、変更、および再度保存することもできます。ユーザーが1日に数十のこれらのグラフを作成できることは実現可能です。
このアプリはまた、データベース内のエンティティを検索するさまざまな方法（主にさまざまなフィールドでのテキスト検索）をユーザーに提供し、検索結果をユーザーに提示し、ユーザーが1つを選択できるようにします。これにより、関連するエンティティグラフが取得されます。完全に表示され、ユーザーが上記のように表示および変更できるように表示されます。
現在、EntityFrameworkとSQLExpressを使用していますが、アーキテクチャと設計の特定の側面に不安があり、クライアントはSSをインストールする必要がありません。私は最近NoSqlデータベースの概念に出くわしました、そしてそれらは私がしていることにぴったりかもしれないように思えます、しかし私はいくつかの質問があります。
まず、これらのオブジェクトグラフのいずれかを読み書きするときに、パフォーマンスがEFより悪くなることはないと思いますか？
アプリの検索機能はどうですか？ NoSql dbはこの種のことをサポートしますか、そして私が持っている可能性のある「ドキュメント」のサイズと量を念頭に置いて、パフォーマンスはどのようになりますか。
ルックアップ（参照）データはどうですか？そのようなデータを各NoSQLドキュメントに複製しますか、それともすべてを1つのNoSqlドキュメントに保持し、それらのIDをメインドキュメントに保存しますか？
最後に、製品に関する推奨事項はありますか？ MongoDbとRavenDbは、Windowsの主要なOSS候補のようです。
これは単に尋ねるのは間違った質問です。
「NoSQL」は特定のデータベースを指すのではなく、ドキュメントデータベース、分散型Key-Valueストア、グラフデータベース、オブジェクトデータベースを含むデータベースのスーパークラス全体を指します。
速度は、一般的に、データストレージに関する決定を行う上で、最も重要でない重要な要素です。 10億行のSQLServerテーブルは、10億のドキュメントを含むMongoDBコレクションまたは10億のオブジェクトを含むdb4oデータベースとほぼ同じ速度でキーとインデックスのルックアップを実行できます。もちろん例外は、シャーディングを実行できる場合です。その場合、それをサポートする製品が必要になりますが、ユーザーがSQL Expressのインストールに意欲的である場合は、つかむように指示すれば、丘に向かって走りますのでご安心ください。 200台の古いデスクトップPCと、それらすべてのHBaseインスタンスをシャーディングします。
全文検索が必要ですか？そのための業界標準はLuceneです。それ自体は実際にはデータベースではなく、他のデータベースに追加され、ElasticSearchやSolrなどのツールによってより適切にパッケージ化されることもあります。ほとんどのSQLデータベースには、何らかの形式の全文検索もあります。一般的に、Luceneよりも遅く、劣っています。 一部NoSQLデータベースには全文検索があります（たとえば、RavenDBは実際にはLuceneを使用します）が、ほとんどはサポートがないか、非常に原始的な段階にあります。
オブジェクトの非常に深い階層を一度に、常に単一の既知の集約ルートを持つ階層を格納する必要がありますか？もしそうなら、MongoDBやCouchDBのようなドキュメントデータベースがあなたのためにうまくいくでしょう。しかし、階層を変更する必要がある場合、またはトランザクションの一貫性（「最終的な」種類ではない）が必要であることがわかった場合は、傷ついた世界。
それぞれが独立した存続期間を持つ複数の関連エンティティのデータに一貫性がありますか？もしそうなら、SQL Serverやmysqlのようなリレーショナルデータベースがはるかに最良の選択です。リレーショナルデータベースを使用すると、多くの難しいモデリングの決定を延期または無視できます。一般に、モデルを頻繁に変更したり、複数の並列モデルを順番に維持したりする必要があるドキュメントデータベースやキー値ストアと比較すると、モデリングは1回で済みます。さまざまなユースケースを解決します。物事を単純に保ちたいのであれば、間違いなくSQLに固執したいと思うでしょう。
embeddedデータベースが必要な場合は、SQLiteを検討してください。 SQL Serverほど強力ではありませんが、高速で使いやすく、展開も簡単です。構文はおなじみのものです。
ちなみに、あなたが本当にそれが速度を心配しているなら（そしてそれの音によって、あなたのニーズはそのような心配を正当化するには小さすぎます）少し前にServiceStackの人たちによって行われた benchmark を見たいと思うかもしれません。 Entity Frameworkは最後に機能しなくなり、かなりの差があります。互換性とパフォーマンスの相互に排他的な要件のバランスを取る場合は、NHibernateがおそらく最良の選択です。個人的にはORMをまったく使用したくないのですが、NoSQLに切り替えると、かなり小さなORMを使用できなくなります。製品の使用経験がない場合は、 110億のRedisコマンド を学習してください。
NoSQLのようなものはありません。まったく異なる哲学とユースケースを持つ新しいデータベーステクノロジーはたくさんあり、それらに共通しているのは、SQLデータベースにも共通していることだけです。つまり、プロジェクトを計画していて、データベーステクノロジーについて確信が持てない場合は、各noSQLデータベースを個別に評価する必要があります。
データが大きなグラフに基づいている場合、 Neo4j のようなグラフ指向データベースの完璧なユースケースのように聞こえます。
MongoDBのようなドキュメント指向データベースは、ドキュメント間の接続を十分にサポートしていないため、一般的にグラフには適していません。
最初にデザインし、後で購入する
特定の実装の購入を開始する前に、システムを設計する必要があります。具体的には：
- 検索およびデータの取得の計画に基づいてデータ構造を設計します。
- 設計要件を実装する同等のソリューションの効率とパフォーマンスを評価します。
データの代表的なコーパスでさまざまなソリューションをベンチマークすることに代わるものは実際にはありません。また、組織以外の誰も、yourのさまざまなトレードオフを評価できます。事業。
グラフ化？次にグラフ！
データを表す適切なデータ構造を選択することは、プログラマーの早期エージングを防ぐために不可欠です。データの検索、保存、取得に適切なモデルを選択することは、状況に大きく依存しますが、新しいシステムを設計する上で不可欠な最初のステップです。
自分で実際に必要なことは一度もありませんが、基本的なデータ構造がグラフである場合は、グラフデータベースソリューションを見てみませんか？ Neo4j 問題のあるドメインに対処するように設計されているようですが、使用したことがないので、気にしないでください。
Neo4jがプロジェクトに適したソリューションではない場合でも、コアデータ構造を簡単に操作できるようにするすべてのオプションを確実に調査する必要があります。重要な目標は、入力形式と出力形式の間でデータを変換するときに必要な変換の数を減らすことです。したがって、ソリューションをどのように使用するかに焦点を合わせてください。 。
NoSQLデータベースはSQLデータベースよりもニーズを満たしている可能性が非常に高いですが、それは選択肢を増やすことだけです。
ほとんどすべてのタイプのデータベースがデータセットを格納できますが、本当に重要なのは、実行する必要のある検索の種類です。データベースの種類が異なれば、この分野での能力も大きく異なります。これは、使用するデータベースの適切な種類を特定するのに役立ちます。
このリンク さまざまなNoSQL製品の適切なリストが緩い動作にグループ化されています。
しかし、私が言いたいのは、これらの製品のほとんどはWindows環境を対象としていないということです。これは、Linuxデータベースサーバーが必要であり、Windowsアプリケーションをホストする別のアプリケーションサーバーがあることを意味します。