NoSQLのウィキペディアのページを見て、キー/値ストアデータベースのバリエーションをいくつかリストしていますが、このコンテキストでのキー/値ストアの意味についての詳細は見つかりません。誰かが私に説明をしたり、説明をリンクしたりできますか?また、このようなデータベースはいつ使用しますか?
NoSQLのウィキペディアのページを見て、キー/値ストアデータベースのバリエーションをいくつかリストしていますが、このコンテキストでのキー/値ストアの意味についての詳細は見つかりません。誰かが私に説明をしたり、説明をリンクしたりできますか?また、このようなデータベースはいつ使用しますか?
回答:
キー/値ペアの概念に精通していますか?あなたがJavaまたはC#に精通していると仮定すると、これはmap / hash / datatable / KeyValuePairとしての言語にあります(最後はC#の場合です)
動作の仕組みは、この小さなサンプルチャートに示されています。
Color Red
Age 18
Size Large
Name Smith
Title The Brown Dog
キー(左)と値(右)がある場合は、文字列、整数などを指定できます。ほとんどのKVPオブジェクトは、値であるため、右側に任意のオブジェクトを格納できます。
返される特定のオブジェクトに対して常に一意のキーがあるため、データベースにその一意のキーを照会し、オブジェクトを持つノードから結果を取得できます(これが分散システムに適している理由です。他のノードと一致する値を返すために最初のn個のノードをポーリングするなど、他のことも関係しているため)。
上記の私の例は非常に単純なので、ここではKVPのわずかに優れたバージョンを示します
user1923_color Red
user1923_age 18
user3371_color Blue
user4344_color Brackish
user1923_height 6' 0"
user3371_age 34
ご覧のとおり、単純なキー生成は、「ユーザー」にユーザー固有の番号、アンダースコア、およびオブジェクトを配置することです。繰り返しになりますが、これは単純なバリエーションですが、左側のパーツを定義して一貫してフォーマットできる限り、値を引き出すことができることを理解し始めると思います。
キー値(テキストのみなど)やvalueプロパティ(サイズ制限がある可能性があります)には制限はありませんが、これまでのところ、私は本当に複雑なシステムを持っていません。もう少し試してみましょう:
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
user1923_color: red, user1923_age: 18, ...
反対するのか、私にはわかりませんuser1923: {color: red, age: 18, ...}
。
SQLの用語では、NoSQLデータベースは2つの列を持つ単一のテーブルです。1つは(プライマリ)キーで、もう1つは値です。それだけです、それがすべてNoSQLの魔法です。
NoSQLを使用する主な理由の1つは、スケーラビリティです。
アプリケーションが毎秒数百万のクエリを処理する必要がある場合、それを実現する唯一の方法はサーバーを追加することです。NoSQLを使用すると、非常に安価で簡単です。対照的に、従来のSQLデータベースのスケーリングははるかに複雑です。
実際には、NoSQLの可能性を最大限に活用している最大のWebサイト、つまりCassandraを実行している数千のサーバーを持つFacebookのみです。
SQL、NoSQL、ORMを比較して、このブログ投稿を読むことを強くお勧めします。
NoSQLの動きと非リレーショナルデータベースモデルの基本的な理解があると思います。
キーバリューストアは、グラフ、ドキュメント指向のデータベースモデルなどの非関係データベースモデルの1つです。
キーバリューストアとNoSQLの動き
一般に、SQLは特別に構造化されたデータを処理し、問題の部門のニーズに応じて非常に動的なクエリを許可しました。
この特定の分野にはまだSQLの本当の競争相手はいませんが、日常のWebアプリケーションのユースケースは異なります。大きなテーブルに対する外部および内部結合、結合、複雑な計算に満ちた非常に動的なクエリ範囲は見つかりません。通常、非常にオブジェクト指向の考え方があります。特にMVCなどのパターンの採用により、バックエンドのデータは通常、データベース用にモデル化されていませんが、巨大なソフトウェアインフラストラクチャの理解に対処できるようにするための論理的整合性も確保されています。これらのオブジェクト指向モデルをリレーショナルデータベースに配置するために行われていることは、テーブルの複雑な階層につながる大量の正規化であり、オブジェクト指向プログラミングの背後にある主要な考え方に完全に反します。
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?
そのアーキテクチャの決定のより多くの、そして議論の余地のある...スケーラビリティ、パフォーマンスなどのような多くの要因を考慮する必要があります...
以下のスライド/記事を見ると、キーバリューストアを使用するタイミング、理由、理由を知ることができます:)
他の人がこれを説明しましたが、とにかく刺すつもりです。
キー/値データベースは、主キーによってデータを保存します。これにより、バケット内のレコードを一意に識別できます。すべての値は一意であるため、検索は非常に高速です。常に単純なディスクシークです。
値は、あらゆる種類の値です。データの保存方法は、データベース自体には不透明です。キー/値ストアにデータを保存する場合、データベースは、それがXML、JSON、テキスト、または画像であるかどうかを認識したり、気にしたりしません。実際、キー/値ストアで行っていることは、データをデータベースから保存する方法を理解する責任を、データを取得するアプリケーションに移すことです。バケットごとに心配するキーの範囲は1つだけであるため、キーを多くのサーバーに分散し、分散プログラミング手法を使用して、このデータにすばやくアクセスできるようにすることは非常に簡単です(すべてのサーバーが範囲のデータを保存します) 。
このデータへのアプローチの欠点は、検索が非常に難しいタスクであることです。バケット内のすべてのレコードを読み取るか、自分でセカンダリインデックスを作成する必要があります。
キー/値データベースを使用する理由はいくつかあります。
キー/値データベースを使用する理由は、RDBMSを使用する場合とほぼ同じくらい多く、一方を他方に対して正当化するための引数も同じくらい多くあります。データのクエリ方法を確認し、そのデータアクセスパターンがどのようにデータを挿入および保存するかを理解することが重要です。
キー/値データベースはNoSQLデータベースの一種にすぎないことを覚えておいてください。
リレーショナルデータベースがある場合は、これを簡単に試すことができます。
create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);
これが、1979年以降のバークレーDBMの良い例であるすべてのデータベースの歴史です。それ以来、状況は進歩しています(どのRDBMSでもキーごとに多くの値を持つことができます)。多くのアプリケーションでは、キーと値のストアで十分です(たとえば、これはsendmailがエイリアスを保存する方法です)。しかし、自分のコードで値を前処理する(または文字列を連結して「キー」を作成する)、値を区切り文字で分割または解析して、使用する前に見つけた場合は、おそらくRDBMSと実際にそのように格納します。