キー/バリューストアデータベースとは何ですか？
私はNoSQLのウィキペディアのページを見てきましたが、キー/値ストアデータベースのいくつかのバリエーションがリストされていますが、このコンテキストでのキー/値ストアの意味の詳細は見つかりません。誰かが私に説明したり、説明をリンクしたりできますか？また、そのようなデータベースはいつ使用しますか？
キー/値ペアの概念を知っていますか？ JavaまたはC＃に精通していると仮定すると、これは言語ではmap/hash/datatable/KeyValuePairです（最後はC＃の場合です）
動作方法は、次の小さなサンプルチャートに示されています。
Color Red
Age 18
Size Large
Name Smith
Title The Brown Dog
キー（左）と値（右）がある場合は、文字列、intなどにすることができます。ほとんどのKVPオブジェクトは、単なる値であるため、右側にオブジェクトを格納できます。
返す特定のオブジェクトの一意のキーは常にあるため、データベースにその一意のキーを照会して、オブジェクトが存在するノードから結果を返すだけです（これが、分散システムに適している理由です）。他のノードが返す値と一致する値を返すために最初のn個のノードをポーリングするなど、他のことも含まれているためです。
さて、上記の私の例は非常にシンプルなので、ここにKVPの少し良いバージョンがあります
user1923_color Red
user1923_age 18
user3371_color Blue
user4344_color Brackish
user1923_height 6' 0"
user3371_age 34
ご覧のとおり、単純なキーの生成は、「ユーザー」にユーザー固有の番号、アンダースコア、オブジェクトを配置することです。繰り返しますが、これは単純なバリエーションですが、左側のパーツを定義して一貫した形式にできる限り、値を引き出すことができることを理解し始めていると思います。
キーの値（テキストのみなどの制限がある場合があります）または値のプロパティ（サイズの制限がある場合があります）には制限がないことに注意してください。ただし、これまでのところ、実際には複雑なシステムはありません。もう少し試してみましょう。
app_setting_width 450
user1923_color Red
user1923_age 18
user3371_color Blue
user4344_color Brackish
user1923_height 6' 0"
user3371_age 34
error_msg_457 There is no file %1 here
error_message_1 There is no user with %1 name
1923_name Jim
user1923_name Jim Smith
user1923_lname Smith
Application_Installed true
log_errors 1
install_path C:\Windows\System32\Restricted
ServerName localhost
test test
test1 test
test123 Brackish
devonly
wonderwoman
value key
あなたはアイデアを得ます...それらはすべて分散ノード上の1つの巨大な「テーブル」に格納され（その背後には数学があります）、分散システムに名前で必要な値を要求するだけです。
少なくとも、それはすべてがどのように機能するかについての私の理解です。いくつか問題があるかもしれませんが、それが基本です。
必須のウィキペディアリンク http://en.wikipedia.org/wiki/Associative_array
SQL用語では、NoSQLデータベースは2つの列を持つ単一のテーブルです。1つは（主）キーであり、もう1つは値です。それだけです。これがNoSQLの魔法です。
NoSQLを使用する主な理由は、スケーラビリティです。
アプリケーションが毎秒数百万のクエリを処理する必要がある場合、それを実現する唯一の方法は、サーバーを追加することです。これは、NoSQLを使用すると非常に安価で簡単です。対照的に、従来のSQLデータベースのスケーリングははるかに複雑です。
実際に存在する最大のWebサイトだけが、完全なNoSQLの可能性、つまりFacebookを利用しており、何千ものサーバーが実行されています Cassandra 。
SQL、NoSQL、およびORMを比較して、このブログ投稿を読むことを強くお勧めします。
私は、あなたがNoSQLの動きと非リレーショナルデータベースモデルの基本を理解していることを前提としています。
キーバリューストアは、グラフなどの非リレーションデータベースモデルの1つであり、ドキュメント指向のデータベースモデルです。
キーバリューストアとNoSQLの動き
一般に、SQLは特別に構造化されたデータを処理し、問題の部門のニーズに応じて非常に動的なクエリを許可しました。
この特定の分野におけるSQLの競合相手はまだありませんが、日常のWebアプリケーションのユースケースは異なります。大規模なテーブルでの外部結合、内部結合、ユニオン、および複雑な計算でいっぱいの非常に動的なクエリは見つかりません。あなたは通常、非常にオブジェクト指向の考え方を見つけるでしょう。特にMVCなどのパターンの採用により、バックエンドのデータは通常データベース用にモデル化されていませんが、論理的な整合性のためにモデル化されているため、巨大なソフトウェアインフラストラクチャを理解するのに役立ちます。これらのオブジェクト指向モデルをリレーショナルデータベースに配置するために行われているのは、テーブルの複雑な階層につながる大量の正規化であり、オブジェクト指向プログラミングの背後にある主要なアイデアに完全に逆らいます。 SQL標準に準拠しているサーバーは、これまで何も単純なデータストレージに役に立たないコードの大部分を実装する必要があり、メモリフットプリント、セキュリティリスクを増大させ、結果としてパフォーマンスに影響を与えるだけです。
SQLが複雑なデータセットに対して任意の動的クエリを許可するという事実は、オブジェクト指向データの永続的なストレージにのみSQLデータベースを使用することによって役に立たなくなります。これは、ほとんどのアプリケーションが最近行っていることです。
ここでKey Valueストアが登場します。
Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship。データ自体は通常、プログラミング言語（文字列、整数、配列）のある種のプリミティブ、またはプログラミング言語のキー値ストアへのバインディングによってマーシャリングされるオブジェクトです。これにより、固定データモデルの必要性がなくなり、適切にフォーマットされたデータの要件が緩和されます。
They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval。 「より単純な」ストアの最大の違いは、異なるストアを認証またはアクセスできる（またはできない）方法です（可能な場合）。データの保存と取得における速度の利点は、一般的なSQLデータベースよりも考慮する必要があるかもしれませんが、キーと値のストアを使用するときに明らかになるもう1つの大きな利点は、結果のコードがプログラミング言語。これは、HibernateやActive Recordなどのオブジェクトリレーショナルマッピングフレームワークと戦う傾向があるものです。オブジェクトリレーショナルマッパーを使用すると、基本的に、SQLデータベースとオブジェクト指向プログラミング言語の間に非常に複雑なコードを多数追加して、キーバリューストアをエミュレートするように見えます。人々のコミュニティ全体が " NoSQL "タグの下に集まり、リレーショナルデータベース管理システムに代わるものを使用することのこれらの利点と欠点についても議論します。 もっと読む
これは少し古い記事ですが、とても役に立ちました。
when would I use such a database?Could someone explain or link an explanation to me?
それはより多くのアーキテクチャ上の決定であり、議論の余地のある決定です...スケーラビリティ、パフォーマンスなどのような多くの要因を考慮する必要があります...
以下のスライド/記事を見ると、いつ、なぜ、なぜKey Value Storeを使用しないのかがわかります:)
他の人がこれを説明しましたが、とにかく私は刺すつもりです。
キー/値データベースは、主キー別にデータを格納します。これにより、バケット内のレコードを一意に識別できます。すべての値は一意であるため、ルックアップは信じられないほど高速です。これは常に単純なディスクシークです。
値はあらゆる種類の値です。データの保存方法は、データベース自体には不透明です。キー/値ストアにデータを格納する場合、データベースはそれがXML、JSON、テキスト、または画像であるかどうかを知りません。実際、キー/値ストアで実行しているのは、データがデータベースからどのように格納されているかを理解する責任を、データを取得するアプリケーションに移動することです。バケットごとに考慮する必要があるキーの範囲は1つだけなので、多くのサーバーにキーを分散し、分散プログラミング手法を使用して、このデータにすばやくアクセスできるようにすることは非常に簡単です（すべてのサーバーがさまざまなデータを格納します）。 。
このデータへのアプローチの欠点は、検索が非常に難しいタスクであることです。バケットのデータのすべてのレコードを読み取るか、または セカンダリインデックス を自分で作成する必要があります。
キー/値データベースを使用する理由はいくつかあります。
- 書き込みパフォーマンスが最も優先される場合。 Mozilla Test Pilot キー/値データベースを使用してデータを迅速に記録します。
- PKによってのみ発生することが保証されている場合。
- フラットデータモデルを使用している場合。
- RDBMSでモデル化できないリッチで複雑なデータモデルを使用している場合。
キー/値データベースを使用する理由は、RDBMSを使用するのと同じくらい多くあり、一方を他方を正当化するのと同じくらい多くの引数があります。データのクエリ方法を確認し、そのデータアクセスパターンがどのようにデータの挿入と保存を行うかを理解することが重要です。
キー/値データベースは、NoSQLデータベースの1種類にすぎないことを覚えておいてください。
リレーショナルデータベースがある場合、これを簡単に試すことができます。
create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);
これは、すべてのデータベースがこれまで使用していた方法で、1979年以降は Berkeley DBM が良い例です。それ以来、状況は進歩しています（多くのRDBMSのキーごとの値）。多くのアプリケーションでは、キーと値のストアで十分です（たとえば、sendmailがエイリアスを格納する方法です）。しかし、自分のコードで値を前処理している（または文字列を連結して「キー」を作成している）場合は、おそらく値を区切り文字で分割するか、解析してから、使用する前に、 RDBMSと実際にその方法で格納します。