14

NoSQL の世界をテストしたいと思います。これは単なる好奇心であり、(まだ) 絶対的な必要性はありません。SQL データベースと NoSQL データベースの違いについていくつか読んだことがあります。潜在的な利点については確信していますが、NoSQL が適用されない場合が少し心配です。私が理解している場合、NoSQL データベースには基本的に ACID プロパティがありません。

ACID リレーショナル データベースで処理できる実世界の操作 (たとえば、電子商取引サイト、科学アプリケーションなど) の例を誰かが挙げることができますか?競合状態または停電などのため?

完璧な例は、データベース エンジンを変更しないと回避策がない場合です。NoSQL データベースのパフォーマンスが悪い例は、最終的には別の問題になりますが、ここでは、理論的にはそのようなテクノロジを使用できない場合を確認したいと思います。

おそらく、そのような例を見つけることはデータベース固有のものです。この場合、NoSQL の世界を表すために MongoDB を取り上げましょう。

編集:この質問を明確にするために、特定のケースではどの種類のデータベースが優れているかについて議論したくありません。SQL データベースが提供するある種の機能をどれだけ試しても、nosql ストアの上に実装できないため、このテクノロジが場合によっては絶対的な行き止まりになる可能性があるかどうかを知りたいです。多くの nosql ストアが利用可能であるため、サポートとして既存の nosql ストアを選択することを受け入れることができますが、私が最も興味を持っているのは、より高いレベルの機能を実装できるようにするためにストアが提供する必要がある機能の最小サブセットです (トランザクションをX を提供しないストア...)。

4

6 に答える 6

19

この質問は、命令型/関数型言語で記述できないプログラムの種類を尋ねることに少し似ています。任意のチューリング完全言語であり、チューリング マシンによって解決できるすべてのプログラムを表現します。問題は、プログラマーとして、フォーチュン 500 企業の会計システムをポータブルでない機械語命令で本当に書きたいかということです。

最後に、NoSQL は SQL ベースのエンジンができることは何でもできます。違いは、プログラマーとして、MySQL が無料で提供する Redis のようなものでロジックを担当できることです。SQL データベースは、データの整合性について非常に保守的な見方をしています。NoSQL の動きは、これらの標準を緩和してスケーラビリティを向上させ、Web アプリケーションに共通のタスクをより簡単にします。

MongoDB (私の現在の好み) は、レプリケーションとシャーディング (水平スケーリング) を容易にし、挿入を非常に高速にし、厳密なスキームの要件を取り除きます。代わりに、MongoDB のユーザーは、インデックスが存在しない場合に低速なクエリを回避するようにコーディングし、アプリにトランザクション ロジックを実装する必要があります (おそらく 3 フェーズ コミットを使用)。これにより、ストレージ効率が低下します。

CouchDB にも同様のトレードオフがありますが、オフラインでデータを操作してからサーバーと同期する機能のためにアドホック クエリを犠牲にしています。

Redis およびその他のキー値ストアでは、プログラマーは、SQL データベースに組み込まれているインデックスおよび結合ロジックの多くを記述する必要があります。引き換えに、アプリケーションはそのデータに関するドメインの知識を活用して、SQL が必要とする一般的なソリューションよりも効率的なインデックスと結合を作成できます。また、Redis はすべてのデータが RAM に収まるようにする必要がありますが、代わりに Memcache と同等のパフォーマンスが得られます。

最終的には、MySQL や Postgres が行うすべてのことを、OS ファイル システム コマンドだけで行うことができます (結局のところ、これらのデータベース エンジンを作成した人々はそうしました)。すべては、データ ストアに何をしてもらいたいか、そしてその見返りに何を喜んで放棄するかにかかっています。

于 2011-03-26T05:47:32.037 に答える
11

良い質問。まず説明。リレーショナル ストアの分野は、各ベンダーが機能や価格設定で付加価値を選択することで、かなり強固な原則の基盤によってまとめられていますが、非リレーショナル (nosql) 分野ははるかに異質です。

コンテンツ管理に最適なドキュメント ストア (MongoDB、CouchDB) や、トピックを中心に構築する可変属性のフラット セットがある同様の状況があります。サイトのカスタマイズを行います。ドキュメント ストアを使用して、ユーザーが自分のページを表示したい方法を定義するカスタム属性を管理することは、プラットフォームに適しています。マーケティングの誇大宣伝にもかかわらず、これらのストアは、テラバイトにうまくスケールする傾向にありません。それは可能ですが、理想的ではありません。MongoDB には、動的インデックス (コレクション/テーブルごとに最大 40) など、リレーショナル データベースに見られる多くの機能があります。CouchDB は、障害が発生した場合に完全に回復できるように構築されています。

高度に分散されたストレージに最適なキー/値ストア (Cassandra、HBase...) があります。低レイテンシーには Cassandra、高レイテンシーには HBase。これらの秘訣は、データを入力する前にクエリのニーズを定義する必要があることです。これらは、属性に対する動的クエリには効率的ではありません。たとえば、顧客イベント ログ サービスを構築している場合は、顧客の一意の属性にキーを設定する必要があります。そこから、さまざまなログ構造をストアにプッシュし、オンデマンドで顧客キーによってすべてのログを取得できます。ただし、セカンダリ キーを作成しない限り、ログを調べて、タイプが「失敗」であるログ イベントを探すのは、はるかにコストがかかります。もう 1 つ: 私が最後に Cassandra を見たとき、あなたはできませんでした。M/R クエリ内で regexp を実行します。つまり、フィールド内のパターンを探したい場合は、そのフィールドのすべてのインスタンスを取得してから正規表現を実行して、必要なタプルを見つける必要があります。

グラフ データベースは、上記の 2 つとは大きく異なります。項目 (オブジェクト、タプル、要素) 間の関係は流動的です。テラバイト単位に拡張することはできませんが、それは設計された目的ではありません。「ねえ、私のユーザーの何人が緑が好きですか?そのうち何人がカリフォルニアに住んでいますか?」などの質問をするのに最適です。リレーショナル データベースでは、静的な構造になります。グラフ データベース (もちろん単純化しすぎています) では、属性とオブジェクトがあります。スキーマを強制せずに、理にかなった方法でそれらを接続します。

非リレーショナル ストアに重要なものは入れません。たとえば、製品を配送する前にトランザクションが完了したことを保証したい商取引。完全性が保証されていること (または、少なくとも完全性が保証される可能性が最も高いこと) が必要です。ユーザーがサイトのカスタマイズ設定を失ったとしても、大したことではありません。商取引を失うと、大変なことになります。異論のある方もいらっしゃるかもしれません。

また、複雑な構造を上記の非リレーショナル ストアのいずれにも配置しません。それらは大規模な結合をうまく行いません。そして、それは彼らが働くべき方法ではないので大丈夫です。リレーショナル システムの customer_address テーブルに address_type の ID を配置する場合は、ドキュメントまたはキー/値に格納されている顧客のタプルに address_type 情報を埋め込む必要があります。データ効率は、ドキュメントやキー/バリュー ストアの領域ではありません。ポイントは配信と純粋なスピードです。犠牲はフットプリントです。

「nosql」とラベル付けされたストアのファミリーには、ここでは取り上げていないサブタイプが他にもあります。さまざまな種類のデータ問題に対する非リレーショナル ソリューションに焦点を当てた、膨大な数 (最終的には 122) のさまざまなプロジェクトがあります。Riak は、私がよく耳にするもう 1 つのツールであり、試してみるのが待ちきれません。

そして、ここにトリックがあります。大金を投じるリレーショナル ベンダーは注目しており、自社製品と連携する独自の非リレーショナル ソリューションを構築している、または構築を計画している可能性があります。今後数年のうちに、この動きが成熟し、大企業が最善の組み合わせを買収し、リレーショナル ベンダーが統合ソリューションをまだ提供していない企業向けに提供し始めるのを見るでしょう。

データ管理の分野で働くのは非常にエキサイティングな時期です。これらのいくつかを試してみてください。Couch または Mongo をダウンロードして、数分で稼働させることができます。HBase は少し難しいです。

いずれにせよ、重大な偏見や誤りなしに啓蒙したことを混乱させることなく伝えられたことを願っています.

于 2011-03-26T06:23:50.887 に答える
9

RDBMS は結合に適していますが、NoSQL エンジンは通常そうではありません。NoSQL エンジンは分散スケーラビリティに優れていますが、RDBMS は通常そうではありません。

RDBMS はデータ検証の制約に優れていますが、NoSQL エンジンは通常そうではありません。NoSQL エンジンは柔軟でスキーマのないアプローチが得意ですが、RDBMS は通常そうではありません。

どちらのアプローチでも、どちらの問題も解決できます。違いは効率です。

于 2011-03-26T07:50:40.960 に答える
2

おそらく、あなたの質問に対する答えは、mongodb はあらゆるタスク (および SQL も) を処理できるということです。ただし、mongodb を選択した方がよい場合もあれば、sql データベースを選択した方がよい場合もあります。ここで読むことができる長所と短所について.

また、 @Dmitryが言ったように、レプリケーションとシャーディングを使用した簡単な水平および垂直スケーリングのためのmongodbオープンドア

于 2011-03-25T23:15:33.277 に答える
1

RDBMS は強力な整合性を強制しますが、ほとんどの非 SQL は結果整合性です。そのため、SQL なしの DB からデータが読み取られる特定の時点で、そのデータの最新のコピーを表していない可能性があります。

一般的な例は銀行取引です。ユーザーがお金を引き出すと、ノード A がこのイベントで更新されます。同時にノード B がこのユーザーの残高を照会された場合、古い残高が返される可能性があります。これは、データが読み取られる前に更新されることが一貫性属性によって保証されるため、RDBMS では発生しません。

于 2011-03-25T23:31:59.627 に答える
1

RDBM は、テーブルから合計や平均などをすばやく集計するのに非常に適しています。例えばSELECT SUM(x) FROM y WHERE z。すぐに答えが必要な場合、ほとんどの NoSQL データベースでこれを行うのは驚くほど難しいことです。一部の NoSQL ストアは、同じことを解決する方法として map/reduce を提供しますが、SQL の世界と同じようにリアルタイムではありません。

于 2011-03-26T05:53:59.490 に答える