Key-Valueストアvs. RDBM vs.＆＃8220;クラウド＆＃8221; DB（SDB）[終了]

Question

MySQLの分野では、過去数年にわたっていくつかのアプリを設計し、パフォーマンスとスケーラビリティの側面を継続的に改善してきました。また、memcachedを使用して、頻繁にクエリされる結果セットでアプリケーション側の高速化を実現した経験もあります。そして最近、Amazon SDBを主要な「データベース」として実装しました。 eコマースの実験用。

簡単に言うと、SDBサービスを使用するために思いついた簡単な理由は、スキーマレスデータベース構造を使用すると、プロジェクトの論理的な問題に集中でき、データストアにコンテンツをすばやく蓄積できるということです。 。つまり、事前に製品属性の可能なすべての順列を設定して正規化することを心配しないでください。製品のロードを開始するだけで、SDBは使用可能なすべてを記憶します。

プロジェクトの最初の数回のイテレーションを完了することができ、データへのシンプルなインターフェースをセットアップする必要があり、MySQLでの作業が当たり前だと思っていた問題に直面しています。例：select文でグループ化し、クエリを「アイテム50から100」に制限します。 SDBのスキーマフリーアーキテクチャを使用して得られた使いやすさの利点は、1800を超えるアイテムを含む結果セットのクエリ/ループのパフォーマンスヒットに負けました。

今、私は、東京内閣のような、インメモリのキーバリューストアの概念を拡張して、途方もなく速い速度で擬似リレーショナル機能を提供しているプロジェクトについて読んでいます（14xどこかで読んでいます）。

私の質問： プロジェクトの各段階でどのDB技術が最も適切であるかを評価するために、アプリケーション設計者/開発者として私が経験できる基本的なガイドラインまたは経験則があります。

Ex：アプリケーションの論理的/技術的な未知数がデータ構造を流動的にするプロトタイピング段階：SDBを使用します。 ユーザーの成果物が優先されるより成熟した段階では、ソート、グループ化、またはページネーションロジックの開発に時間を費やす必要がない従来のツールを使用します。

これらのツールの実用的な経験は非常にありがたいです。

ありがとう！

Shaheeb R.

Answer 1

新しいソリューションは特効薬ではありません。

従来のRDBMSと比較して、これらのシステムはトレーディングオフの他の側面（クエリ機能の低下、最終的な一貫性、特定の操作の恐ろしいパフォーマンス）によって、いくつかの側面（スケーラビリティ、可用性、または単純性）を改善します。

これらは従来のデータベースの代替としてではなく、既知の特定のニーズに特化した専用ツールです。

たとえば、Amazon Simple DBを例にとると、SDBは基本的に巨大なスプレッドシートです。それがデータのようであれば、おそらくうまく機能し、優れたスケーラビリティとシンプルさで多くの時間とお金を節約できます。

システムが非常に構造化された複雑なクエリを必要としているが、これらのクールな新しいソリューションのいずれかを主張する場合、すぐにアマチュアで不適切なRDBMSをすべて再実装する途中にいることに気付くでしょう固有の問題。

この点で、これらがあなたのニーズに合うかどうかわからない場合は、特に単一サーバー展開で最高の柔軟性と機能を提供するため、従来のRDBMSで最初の数回の反復を行う方が実際には良いと思いますそして適度な負荷の下で。 （ CAP定理を参照）。

データがどのように見え、どのように使用されるかについてより良いアイデアが得られたら、別のソリューションでニーズを一致させることができます。

クラウドホスト型ソリューションのシンプルさを望むが、リレーショナルデータベースが必要な場合は、 Amazonをチェックアウトできます。リレーショナルデータベースサービス

Answer 2

あなたが見つけている問題は、RDBMSの専門家が、いくつかの代替システムを慎重に見ている理由です。はい、代替システムは特定の特定の要件を非常に高速に処理しますが、同じデータを使用して何か他の処理を実行するとすぐに、最も軽いものが突然遅れをとります。対照的に、RDBMSは通常、バリエーションをより大きな外交で管理します。処理するために微調整されている特殊なワークロードの場合のように高速ではないかもしれませんが、他のクエリを処理するために呼び出されたときほど速く劣化することはほとんどありません。