CouchDBとRDBMSを使用する場合
私はCouchDBを見ています。CouchDBには、リレーショナルデータベースよりも魅力的な機能が数多くあります。
- 直感的なREST/HTTPインターフェイス
- 簡単な複製
- 正規化されたテーブルではなく、ドキュメントとして保存されたデータ
これは成熟した製品ではないため、慎重に採用する必要があることを感謝していますが、実際にはRDBMSの実行可能な代替品であるかどうか疑問に思っています（イントロページではそうではないと言っていますが http：//couchdb.Apache .org/docs/intro.html ）。
- どのような状況下で、CouchDBがRDBMS（例：MySQL）よりも優れたデータベースの選択になるでしょうか。スケーラビリティ、設計+開発時間、信頼性、メンテナンスの面で。
- RDBMSが明らかに正しい選択である場合がまだありますか？
- これはどちらか一方の選択肢ですか、それともハイブリッドソリューションがベストプラクティスとして登場する可能性が高いですか？
私は最近ロンドンで開催されたNoSQL会議に参加しましたが、元の質問にどのように答えればよいか、今ではもっと良いアイデアがあると思います。 ブログ投稿 も書いたが、他にも goodones がいくつかある。
キーポイント：
- リレーショナルデータベースの管理に関するおそらく30年の知識を蓄積しているので、慎重に検討することなくそれらを置き換えるべきではありません。非リレーショナルデータストアはリレーショナルデータストアよりも成熟度が低いため、採用するのが本質的にリスクが高い
- 非リレーショナルデータストアにはさまざまな種類があります。いくつかはキーバリューストア、いくつかはドキュメントストア、いくつかはグラフデータベースです
- ハイブリッドアプローチを使用できます。ソーシャルソフトウェアサイトのRDBMSとグラフデータストアの組み合わせ
- ドキュメントデータストア（CouchDBやMongoDBなど）は、おそらくリレーショナルデータベースに最も近く、すべてのフィールドが階層的に表示されるJSONデータ構造を提供します。これにより、テーブル結合を行う必要がなくなります。ほとんどのアプリケーションが現在使用しているリレーショナルマッピング
- 非リレーショナルデータベースはレプリケーション（マスターマスターを含む）をサポートします。リレーショナルデータベースもレプリケーションをサポートしていますが、非リレーショナルオプションほど包括的ではない場合があります
- Twitter、Digg、Facebookなどの非常に大規模なサイトでは、クラスタリングをサポートするためにゼロから構築されたCassandraを使用しています
- リレーショナルデータベースはおそらくケースの90％に適しています
要約すると、コンセンサスは「慎重に進められる」ようです。
誰かがより詳細な答えを出すまで、CouchDBの長所と短所を次に示します。
長所：
- これらの厄介な高次正規形のいずれかにデータを適合させる必要はありません
- データの「スキーマ」はいつでも変更できます
- データはクエリに対して正確にインデックス付けされるため、一定の時間で結果が得られます。
短所：
- クエリごとにビューを作成する必要があります。つまり、アドホックのようなクエリ（SQLでの動的WHEREとSORTの連結など）クエリは使用できません。
- 冗長データがあるか、「クライアント側」で結合およびソートロジックを実装することになります（たとえば、複数のフィールドで多対多の関係をソートする）
長所または短所：
- ビューの作成はSQLほど単純ではなく、パズルを解くようなものです。これが賛否両論の場合は、タイプによって異なります:)
CouchDBはいくつかの利用可能な「キー/値ストア」の1つであり、その他には [〜＃〜] bdb [〜＃〜] などの古いもの、 Persevere などのWeb指向のものが含まれます。 MongoDB とCouchDB、 memcached （RAMのみ）や Tokyo Cabinet などの新しい超高速、HadoopやGoogleのBigTable（MongoDBなど）また、このスペースにいると主張しています）。
キー/値ストアとリレーショナルDBの両方に確かにスペースがあります。従来、ほとんどのRDBはキー/値の上のレイヤーと見なされます。たとえば、MySQLはBDBをテーブルのオプションのバックエンドとして使用していました。要するに、キー/値はSQLの基礎であるフィールドと関係について何も知りません。
通常、キー/値ストアはスケーリングが容易であるため、Twitterのように爆発的に成長するときに魅力的な選択肢になります。もちろん、これは、SQLで宣言するだけでなく、格納された値間の関係をコードで管理する必要があることを意味します。 CouchDBのアプローチは、価値のある部分に大きな「ドキュメント」を格納し、（ほとんど）自己完結させて、必要なデータのほとんどを単一のクエリで取得できるようにすることです。多くのユースケースはこの考えに適合していますが、他のユースケースは適合しません。
私が見る現在のテーマは、「レールはスケールしない!!」の後です。怖い、今では多くの人があなたのWebフレームワークではないことに気付いています。ただし、可能な場合はデータベース、さらにはwebappにアクセスしないようにするためのインテリジェントなキャッシュについてです。そこの新星はmemcachedです。
いつものように、それはすべてあなたのニーズに依存します。
これは答えるのが難しい質問です。そこで、CouchDBがあなたに不利に働く可能性のある分野を強調します。
人々が持っているCouch UsersとDevメーリングリストの難しさの2つの最大の原因は次のとおりです。
- データの複雑な結合。
- マルチステップマップ/リデュース。
カウチビューは、それ自体がほとんどの島です。ビューのセットを集約/マージ/インターセクトする必要がある場合は、今のところアプリケーション層でそれを行う必要があります。ビュー照合と複雑なキーでできるいくつかのトリックがありますが、これらは特定の種類のデータに対してのみ有効です。これは、さまざまなアプリケーションに適している場合とそうでない場合があります。何度も言われているように、この問題はデータの構造を変えることで軽減または解消できます。
この質問に対する他の人々のコメントは、CouchDBに適したさまざまなタイプのデータのいくつかを示しています。
覚えておくべきもう1つのことは、多くの場合、結合/マージ/交差する必要があるデータは、RDBMSデータベースでオフラインにするデータになるため、CouchDBで同じことを行っても何も失われないことです。
短い答え：最終的にCouchDBは、あなたが投げたいあらゆる種類の問題を処理できると思います。しかし、それを使用している快適さのレベルは、開発者によって異なる場合があります。それはやや主観的だと思います。チューリング完全言語を使用してデータを照会し、アプリケーション層により多くのロジックを保持するのが好きです。あなたのマイレージは異なる場合があります。
間違っている場合は修正してください。 Couchdbは、複数のフィールドにわたってドキュメントの一意性を検証する必要がある場合には役に立ちません。たとえば、「ログインとメールの両方が一意である必要がある」などの検証ルールを適用し、データを一貫性のある状態に保つことは不可能です。ドキュメントを保存する前に確認できますが、あなたとデータが矛盾する前に誰かがプッシュできます。
浅いデータ階層しかない表形式のデータを使用している場合は、おそらくRDBMSシステムが最良の選択です。これはRDBMSシステムの主な用途であり、ドキュメントとツールのサポートは非常に優れています。
Xmlのようなネストされたデータの場合、ドキュメントデータベースはデータへのアクセスを高速化する必要があります。また、ストレージモデルはデータのストレージモデルにより類似しているため、検索はより簡単です。