nosql - キーと値のペアの noSQL db が従来のリレーショナル DB よりも高速なのはなぜですか

Question

私が使用しているリレーショナル データベースを置き換えるために、キーと値のペア データ システムを調査するように勧められました。

私がよく理解していないのは、これがクエリの効率をどのように改善するかです。私が理解していることから、構造データベースをキーと値の 1 つの大きな長いリストに変えるだけで、クエリをより効率的にするのに役立つ多くの情報を捨てることになりますか?

ポイントを完全に逃しましたか？

Answer 1

リレーショナル データベースの主な利点は、情報を関連付けてインデックスを作成できることです。ほとんどの「NoSQL」システムは、リレーショナル代数や優れたクエリ言語を提供していません。

自問する必要があるのは、私の意図したユースケースにとって切り替えが理にかなっているのかということです。

あなたはちょっと要点を逃しました。ポイントは、インデックスがない場合があるということです (とにかく一般的なリレーショナル DB で行う方法で)。インデックスがある場合でも、それを関連付ける機能は難しく、リレーショナル データベースが優れている点です。NoSQL ソリューションには多くの斬新な構造があり、多くのユースケースを自明のように簡単にします。たとえば、Redis はデータ構造指向の DB であり、キューまたはその pub-sub アーキテクチャを使用してあらゆるものを迅速に構築するのに適しています。MongoDB は、ドキュメントを JSON (BSON) として保存し、迅速な開発に優れた自由形式のドキュメント データベースです。BigTable ソリューションはそれよりも構造化されていませんが、行の概念を拡張して列のファミリー (各行に含まれるキーと値のペア) をディスク上に効率的に配置します。ElasticSearch などのテクノロジーを使用して、この上に転置インデックスを構築できます。

すべてが従来の RDBMS の一貫性の保証やディスク レイアウトを必要とするわけではありません。NoSQL のもう 1 つの主要なユース ケースは大規模なスケーラビリティです。多くのソリューション (BigTable -- HBase/Cassandra など) は、簡単にシャード化して水平方向にスケーリングするように設計されています (SQL ではそれほど簡単ではありません!)。特に Cassandra は、SPOF を考慮しないように設計されています。さらに、列指向のデータストアは、シーケンシャル読み取りによってディスク速度を最適化する (および書き込み増幅を減らす) ことを目的としています。そうは言っても、本当に必要でない限り、通常は従来の SQL サーバーで十分です。

メリットとデメリットがあります。個人的には両方を混ぜて使っています。適切な仕事には適切なツールを使用してください。多くの場合、PostgreSQL または MySQL になる可能性があります。

基本的なキーと値のシステムは、一意のキーと値の 2 つの列を持つ SQL テーブルを作成することにたとえることができます。これは非常に高速です。データの関係、相関、または照合を行う必要はありません。値を見つけて返すだけです。これは単純化しすぎています。NoSQL データベースには、単純な K,V ストアを超えた多くの興味深い機能とアプリケーションがあります。

あなたの科学データがほとんどの NoSQL 実装に適しているかどうかはわかりませんが、それはデータに依存します。HBase や Cassandra を見ると、科学者のニーズに適している可能性があります (適切な行キーの設計が必要です -- タイムスタンプが最初であってはなりません。OpenTSDB を調べてください)。私は、センサーの読み取り値を Cassandra に格納する企業を多数知っています。これは、ランダムな順序のパーティショナーとセンサーの UUID を使用して、読み取り値を毎日の太い行にロールアップします。毎日、特定のユースケースに基づいて新しいデータベースが作成されるため、その答えは変わる可能性があります。特定のユース ケースでは、柔軟性とツールを犠牲にして、特定のデータストアを使用することで大きな利益を得ることができます。

Answer 2

効率は次の3つの主要な領域からもたらされます。

1. データベースの機能ははるかに少なく、結合の概念はなく、トランザクションの整合性要件が緩和または欠如しています。少なくともサーバー側では、機能が少ないということは作業が少ないということは高速であることを意味します。
2. もう1つの設計原則は、データストアがサーバーのクラウドに存在するため、リクエストに複数の回答者がいる可能性があることです。これらのシステムは、マルチサーバーシステムがレプリケーションを通じてフォールトトレランスを向上させるとも主張しています。
3. それは完全に流行語に準拠しており、まだ完全には発明されていない一連のアイデアと説明を使用しています。たとえば、Amazonは現在、人々がサービスをどのように使用するかをよりよく理解し、仕様を改良するための経験を積むために、サービスを提供しています。

私の目には、「新しいデータはRDBMSには多すぎる」という要件を持ってあなたのところに来る人は、その主張を裏付ける数字を持っているか、新しい光沢のあるものを試したいだけだと認めるべきです。noSQLは無益ですか？おそらくそうではありません。Java 1.0が誇大宣伝されたように、それは世界をひっくり返すつもりですか？おそらくそうではありません。

新しいことを調査することに害はありません。50年前の、確立された、よく理解されているテクノロジーを支持して、農場に賭けないでください。

Answer 3

ここでは、特定の 1 つのクエリを最適化する必要があると想定しています。これは、単にレコードをキーで検索するものです。この 1 つの例は、ユーザー名による userinfo レコードの検索です。一部のシステムでは、そのようなクエリは信じられないほど高速である必要があり、他のすべてのクエリは重要ではありません。

データベースのパフォーマンスの最大の要因は、データの読み取り/書き込みに必要な I/O 操作の数です。ほとんどのデータベース システムは、キャッシュされていないデータを O(log(n)) I/O で取得できる同様のデータ構造 (つまり、b ツリー) を使用します。耐久性のある更新を提供するには、データをディスクに書き込む必要があります。ほとんどのシステムでは、これを順番に行うのが最速の方法です。

では、Key-Value ストアはどこで効率化できるのでしょうか?

1. 正規化されていないデータ。すべてのデータを 1 行に入れるということは、結合がないことを意味します。
2. 低 CPU オーバーヘッド。キー値ストアは、クエリの処理/最適化、セキュリティ チェック、制約チェックなどの CPU コストを回避します。
3. (別のサービスとして実行されている SQL サーバーとは対照的に) ストアをインプロセスにする方が簡単で、これにより IPC オーバーヘッドがなくなります。

ほとんどの RDBMS システムは、キーと値のストアのように見えるものの上に構築されているため、仲介者を排除していると見なすことができます。

Answer 4

There are a lot of good observations above and sometimes a little too much passion on both sides by both proponents. Let's get back to your original question. Suppose you do a design on Cassandra and do an identical design on an RDBMS. Say you have a set of KV pairs in Cassandra, and go and do an identical set of KV pairs on relational. (It is actually possible to do this - say, as a fully denormalized name value pair on relational). Even so, relational will run slower simply because of the overhead of the relational DBMS - logging, catalog access, integrity checking, transaction atomicity, etc. In addition, in column family data store the data is lexigraphically sorted; it is not in relational. I believe that several of the social networking sites did this, they built identical structures on both, but relational was slower. It is important to remember that after a user queries the product database, looks at who also bought this or that, builds their shopping cart and their wishlist, all of which will be done on NOSQL, when the user hits the checkout button, the transaction will be run on a relational database. Why can't we so-called experts realize it is not one versus the other in this database debate, but rather that there is a place for relational, as there is for NOSQL, graph, inverted column databases, multidimensional, etc. and even files.