とりあえず思いつくまま列挙。まだまだ変わる可能性は大きい。 正規化しない。RDBMSでいうところのJOIN済みのでっかいテーブル作れ。 SELECTはがんばらない。INSERT超がんばれ。 PKはString型にしてgae.encoded-pkを使用する。 PKに複合キーは使わない。(コンポジットインデックス使わない) Date型のプロパティは使わない。String型にする。 プリミティブ型はnullを許容しないので使わない テーブル間のjoinができない。→正規化せずJOIN済みのでっかいテーブルを作る 集約関数がない（group byできない）、count()で全件カウントできない →集約したい値は、集約用のエンティティを用意してInsert時に集計値を保存する（最大値／最小値も同様） 毎回対象データをすべて取得してループで集計するのは非効率（また最大1000件の制限がある）集約したい
2010/02/25 米Amazon Web Servicesは2月24日、Amazon SimpleDBにデータ読み出し時の一貫性を保証する機能を追加したと発表した。これまでSimpleDBでは読み出したデータが最新のものである保証がなかったが、SelectやGetAttributesの読み出しAPI利用時にオプションで「ConsistentRead=true」を指定することで、確実に最新データを読み出せるようになる。ただし、この場合、読み出しに遅延が発生する。 ConsistentReadオプションのデフォルト値はfalseなので、特に指定しなければ、従来のアプリケーションはそのまま動く。新機能は、利用者からのフィードバックに基づいて実装したという。 Amazonのような分散環境では、応答性能を落とさずにシステムをスケールさせるために、ストアしたデータの一貫性を「eventually
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
