23

私は、リレーショナル データベースと、それらに対して効率的にコーディングする方法にしっかりと頭を悩ませています。私の経験のほとんどは、MySQL と SQL に関するものです。ドキュメント ベースのデータベースについて聞いていることの多くが気に入っています。特に、最近のポッドキャストで誰かが大きなパフォーマンスの利点について言及したときはそうです。では、その道をたどる場合、SQL から NO-SQL に移行するために必要な精神的なステップにはどのようなものがありますか?

それがあなたの答えに違いを生むなら、私は主にC＃開発者です（今日、とにかく）。私は EF や Linq to SQL のような ORM に慣れています。ORM の前は、ジェネリックとデータリーダーを使用して独自のオブジェクトを展開していました。それは重要かもしれないし、そうでないかもしれない。

より具体的なものを次に示します。

  1. 結合についてどのように考える必要がありますか?
  2. SELECT ステートメントを使用せずにクエリを実行するにはどうすればよいですか?
  3. コードにプロパティを追加すると、既存の保存済みオブジェクトはどうなりますか?

（ここにあなた自身の質問を自由に追加してください）

4

2 に答える 2

20

まず、NoSQL ストアはそれぞれ異なります。したがって、Oracle、Sql Server、または MySQL のいずれかを選択するようなものではありません。それらの違いは非常に大きくなる可能性があります。

たとえば、CouchDB では、アドホック クエリ (必要に応じて動的クエリ) を実行することはできません。オンラインとオフラインのシナリオに非常に優れており、ほとんどのデバイスで実行できるほど小さいです。RESTful インターフェイスを備えているため、ドライバーも ADO.NET ライブラリもありません。クエリを実行するには、MapReduce を使用して (現在、これは NoSQL スペース全体で非常に一般的ですが、ユビキタスではありません)、ビューを作成します。これらは多くの言語で記述されていますが、ほとんどのドキュメントは Javascript 用です。CouchDB はクラッシュするようにも設計されています。つまり、何か問題が発生した場合、プロセス (通常は CouchDB インスタンス全体ではなく、Erlang プロセス、またはリンクされたプロセスのグループ) を再起動します。

MongoDB は高いパフォーマンスを発揮するように設計されており、ドライバーを備えています。このため、.NET の世界の多くの人々にとって飛躍的ではないように思えます。ただし、クラッシュの状況ではデータが失われる可能性があると思います (CouchDB と同じレベルの書き込みに関するトランザクション保証は提供されません)。

現在、これらはどちらもドキュメント データベースであり、データが構造化されていないという共通点があります。テーブルも、定義されたスキーマもありません。それらはスキーマレスです。ただし、保持するデータが理解できると主張しているため、キー値ストアとは異なります。CouchDB ではこれは JSON の使用を意味し、MongoDB ではこれは BSON の使用を意味します。

MongoDB と CouchDB には他にも多くの違いがあり、これらは NoSQL 空間では設計上非常に近いと見なされています。

ドキュメント データベース以外には、Neo4J のようなネットワーク指向のソリューション、カラム型ストア (データを保持する方法が行指向ではなく列指向) などがあります。

MapReduce 以外のほとんどの NoSQL ソリューションに共通することは、それらがリレーショナル データベースではなく、大部分が SQL スタイルの構文を使用していないことです。通常、クエリは、SQL の宣言型スタイルではなく、プログラミングの命令型モードに従います。

もう 1 つの一般的な特性は、リレーショナル データベースによって通常提供される絶対的な整合性が、最終的な整合性モデルと交換されることです。

NoSQL ソリューションの使用を検討しているすべての人への私のアドバイスは、最初に彼らの要件を本当に理解し、SLA を理解することです (必要なレイテンシのレベル、ソリューションのスケーリングに応じてそのレイテンシをどの程度一貫させる必要があるか、予想される負荷の規模はどれくらいか、どの程度の負荷が予想されるか、どの程度の負荷が予想されるか、どの程度の負荷が予想されるか、どの程度の負荷が予想されるか、どの程度の負荷が予想されるか、どの程度の負荷が予想されるかなど)。負荷は一貫しているか、急増するか、データのユーザー ビューの一貫性はどの程度必要か、クエリを実行するときに自分の書き込みが常に表示される必要があるか、他のすべてのユーザーが書き込みをすぐに確認できるか、などなど）。完全な一貫性、100% の可用性、およびパーティション トレラント (ノードが通信できない場合に対処する) を実現することは基本的に不可能であると述べています。次に、さまざまな NoSQL ソリューションを調べて、要件を満たすように設計されていないものを排除し始めます。リレーショナル データベースからの移行は些細なことではなく、それに伴うコストがかかることを理解している (ミーティングやディスカッションなどに関して、組織をその方向に移行するコストは非常に高く、集中を妨げていることがわかった)潜在的な利益の他の分野で）。ほとんどの場合、ORM は必要ありません (式の R 部分が欠落しているだけです)。場合によっては、バイナリ シリアル化だけで問題ない場合もあります (たとえば、DB4O のようなもの、またはキーと値のストアを使用)、Newtonsoft JSON のようなもの/BSON ライブラリや automapper が役立つ場合があります。C#3 で作業することは、Python などの動的言語で作業する場合と比較して、明確なコストがかかることがわかりました。C#4 では、ExpandoObject や DLR の Dynamic などで少し改善される可能性があります。

3 つの特定の質問を見ると、採用する NoSQL ソリューションに依存するため、1 つの答えはありませんが、非常に一般的な用語で言えば、次のような注意事項があります。

  1. オブジェクト (または集約の可能性が高い) を全体として永続化する場合、通常、結合はコードで行われますが、これの一部は MapReduce を介して行うことができます。

  2. 繰り返しますが、状況によって異なりますが、Couch では、特定のリソースに対して、または MapReduce ビューに対して HTTP 経由で GET を実行します。

  3. ほとんどの場合、何もありません。シリアライゼーション、デシリアライゼーションのシナリオに注意してください。私が見つけた難しさは、コードのバージョンを管理する方法にあります。プロパティが純粋にインターフェイス (GUI、Web サービス) にプッシュするためのものである場合は、問題が少なくなる傾向があります。プロパティが動作が依存する内部状態の形式である場合、これはさらにトリッキーになる可能性があります。

それが役に立てば幸いです、頑張ってください！

于 2010-02-20T13:10:05.047 に答える
5

データベースについて考えるのをやめてください。

ドメインのモデリングについて考えてみましょう。適切なパターンとプラクティスに従ってオブジェクトを構築し、問題を解決してください。持続性について心配する必要はありません。

于 2010-02-19T16:41:57.543 に答える