Key-Valueデータストアと従来のリレーショナルDBをいつ使用するのですか？
リレーショナルDBではなくKey-Valueデータストアを選択するのはいつですか？どちらを決定する際にどのような考慮事項がありますか？両方の最良のルートの組み合わせはいつですか？できれば例を挙げてください。
私の経験では、伝統的な方法と難解な方法のどちらを使用するかという質問さえしている場合は、伝統的な方法を使用してください。難解な慣習はセクシーでやりがいがあり、楽しいものですが、アプリケーションの99.999％は従来のアプローチを求めています。
リレーショナルvsKVに関して、あなたがすべき尋ねるべき質問は次のとおりです。
なぜ私はnotこのシナリオにリレーショナルモデルを使用したいのですか：.。
シナリオを説明していないので、なぜそれを使用すべきでないのかを誰かが言うことは不可能です。 KVの「すべてをキャッチ」する理由はスケーラビリティですが、これは現在問題ではありません。最適化のルールを知っていますか？
- それをしないでください。
- （専門家のみ）今はやらないでください。
KVは高度にスケーラビリティに対する最適化されたソリューションであり、アプリケーションにとって完全に不要である可能性があります。
Key-Value、階層型、map-reduce、またはグラフデータベースシステムは、実装戦略に非常に近く、物理的な表現と密接に関連しています。これらのいずれかを選択する主な理由は、説得力のあるパフォーマンスの議論があり、それがデータ処理戦略に非常に密接に適合している場合です。アドホッククエリは通常、これらのシステムでは実用的ではないことに注意してください。事前にクエリを決定することをお勧めします。
リレーショナルデータベースシステムは、論理的なビジネス指向のモデルを、基礎となる物理的な表現および処理戦略から分離しようとします。この分離は不完全ですが、それでもかなり良好です。リレーショナルシステムは、事実を処理し、事実のコレクションから信頼できる情報を抽出するのに最適です。リレーショナルシステムは、他のシステムが苦手なことで有名なアドホッククエリにも優れています。これは、ビジネスの世界や他の多くの場所に最適です。そのため、リレーショナルシステムが非常に普及しています。
それがビジネスアプリケーションの場合、ほとんどの場合、リレーショナルシステムが答えです。他のシステムの場合、それがおそらく答えです。発生する必要のあるパイプラインのようなデータ処理の問題が多く、大量のデータがあり、すべてのクエリを事前に知っている場合は、別のシステムが適している可能性があります。
データが単なるリストであり、各アイテムの一意の識別子を導出できる場合は、KVSが適しています。これらは、新入生のコンピュータサイエンスで学んだ単純なデータ構造の緊密な実装であり、複雑な関係を許容しません。
簡単なテスト：データとそのすべての関係をリンクリストまたはハッシュテーブルとして表すことができますか？はいの場合、KVSが機能する可能性があります。いいえの場合、RDBが必要です。
それでも、ご使用の環境で機能するKVSを見つける必要があります。 KVSのサポートは、主要なものであっても、PostgreSQLやMySQL/MariaDBなどのサポートにはほど遠いものです。
キーに基づいて値をO(1)ルックアップする場合は、KVストアが必要です。つまり、k1={foo}, k2={bar}などの形式のデータがある場合は、値はより大きく/ネストされた構造であり、高速ルックアップが必要であり、KVストアが必要です。適切なインデックス付けを行っても、リレーショナルDBで任意のキーのO(1)ルックアップを実現することはできません。 「ランダムルックアップ」と呼ばれます。
言い換えると、1つの列だけでクエリを実行する場合は、残りのデータを取得するために「主キー」を使用し、その列をキースペースとして使用し、残りのデータをKVストアの値として使用します。ルックアップを行うための最も効率的な方法。
対照的に、複数の列のいずれかでデータをクエリすることが多い場合、つまりデータに対してより豊富なクエリAPIをサポートしている場合は、リレーショナルデータベースが必要になることがあります。
IMO、キーと値のペア（NoSQLデータベースなど）は、基になるデータが構造化されていない、予測できない、または頻繁に変更される場合に最適に機能します。構造化データがない場合、データを構造に適合させるために多くのスキーマ変更を行ったり、フープを飛び越えたりする必要があるため、リレーショナルデータベースはその価値よりも厄介になります。
KVP/JSON/NoSqlは、データ構造を変更するためにデータモデルを完全にリファクタリングする必要がないため、優れています。データオブジェクトにフィールドを追加することは、単にそれをデータに追加することの問題です。コインの反対側は、KVP/Nosqlデータベースの制約と検証チェックがリレーショナルデータベースよりも少ないため、データが乱雑になる可能性があることです。
リレーショナルデータモデルには、パフォーマンスとスペース節約のメリットがあります。正規化されたリレーショナルデータは、テーブルキーの関係と制約があるため、データの理解と検証が容易になります。
私が見た中で最悪のパターンの1つは、それを両方の方法で実現しようとすることです。キーと値のペアをリレーショナルデータベースに入れようとすることは、多くの場合、災害のレシピです。何よりもデータに合った技術を使うことをお勧めします。
従来のリレーショナルデータベースには、ポイントを超えてスケーリングする際の問題があります。そのポイントがどこにあるかは、あなたがやろうとしていることに少し依存します。
クラウドコンピューティングのすべての（ほとんど？）サプライヤーは、Key-Valueデータストアを提供しています。
ただし、複雑なデータ構造を持つ適度なサイズのアプリケーションがある場合は、リレーショナルデータベースを使用することで得られるサポートにより、開発コストを削減できます。