過去数年にわたっていくつかのアプリを設計し、パフォーマンスとスケーラビリティの側面を継続的に改善してきた MySQL の分野に満足しています。また、memcached を使用して、頻繁にクエリされる結果セットでアプリケーション側の速度を向上させた経験もあります。そして最近、Amazon SDB を e コマースの実験用の主要な「データベース」として実装しました。
簡単に言うと、SDB サービスを使用する理由として、スキーマのないデータベース構造を使用することで、プロジェクトの論理的な問題に集中し、コンテンツをデータ ストアにすばやく蓄積できるということがすぐにわかりました。つまり、事前に製品の属性のすべての可能な順列を設定して正規化する必要はありません。製品のロードを開始するだけで、SDB は利用可能なすべてのものを記憶します。
プロジェクトの最初の数回の繰り返しをなんとかやり遂げ、データへの単純なインターフェイスをセットアップする必要があるので、MySQL での作業で当然のことと思っていた問題に取り組んでいます。例: select ステートメントでグループ化し、構文を "items 50 to 100" に制限します。SDB のスキーマ フリー アーキテクチャを使用して得た簡単な利点は、1800 項目をわずかに超える結果セットのクエリ/ループのパフォーマンス ヒットで失われました。
今、私は Tokyo Cabinet のようなプロジェクトについて読んでいます。これは、メモリ内のキー値ストアの概念を拡張して、疑似リレーショナル機能を途方もなく高速に提供しています (14x どこかで読んだ)。
私の質問: アプリケーション デザイナー/開発者として、プロジェクトの各段階でどの DB 技術が最も適切かを評価するために使用できる基本的なガイドラインやヒューリスティックはありますか?
例: アプリケーションの論理的/技術的な未知数がデータ構造を流動的にするプロトタイピング段階: SDB を使用します。ユーザーの成果物が優先されるより成熟した段階では、従来のツールを使用して、並べ替え、グループ化、またはページ付けロジックの作成に開発時間を費やす必要はありません。
これらのツールの実際の経験は非常に高く評価されます。
ありがとうございます！
シャヒーブ R.