読者です 読者をやめる 読者になる 読者になる

お勉強②

http://code.google.com/intl/ja/events/io/sessions/BuildingScalableComplexApps.html

ある程度エンティティが複雑なときのパフォーマンス対策で、一対nの関連についての対策を説明しています。

list property

  • list propertyとは?

一対nの関連のこと。equals filterを使って検索できる。

listへのアクセス時に、シリアライズ・デシリアライズが発生してしまう。ひとつ以上のlist propertyにアクセスすると、対象インデックスが爆発的に増えてしまう。

  • list propertyのパフォーマンス特性と対策

インデックスへパラレルで書き込みするので、高速。1対nのnを増やしていく分にはリニアに増える。1対nのnについては、5000までに制限されているらしい。
使うストレージの容量的にはrdbmsと同じ。

ただし、検索時にはシリアライズにコストがかかってしまう(nの側をデシリアライズしないと検索できないから)。

list propertyの中に入っているエンティティの一部のカラムだけとってきてシリアライズのコストを下げるのは今のところできないけど、エンティティをインデックス用とデータ用に分割すればパフォーマンスの向上が図れる。(このエンティティの永続化時には、同じentity groupにする)

検索時には、key-onlyクエリとして発行し、インデックスの全件からkeyとして必要なものだけ引いてきて、必要なkeyに該当するデータを引く(このときはパラレルに引ける)。インデックスエンティティ全件が1000件オーダーで、取得対象が10件なら10秒かかってたのが1秒程度になる、というデモをやってました。

marge join

  • maege joinとは

gaeでjoinはできないけど、marge joinはできる(自然結合、外部結合はできない)。

marge joinではインデックスは作らなくてもよいのでコストが安い。

  • marge joinの挙動

検索対象のプロパティはソート順に格納されている前提で、実行時にmarge sortする。zig-zag algorithmで検索し、インデックスをパラで読む。list property を含んでいても、marge joinできる。

  • marge joinのパフォーマンス

フィルターの個数に対してスケールするが、結果の集合は100より小さいほうがいいらしい。これも、list propertyでみたインデックスエンティティを作ればシリアライズのコストはない。

検索対象のプロパティのサイズについては、zig zagしすぎるのでスケールしない。また、コンポジットインデックスに対しては機能しない(インデックスが爆発しちゃうので)こういうときは、メモリでソートしたほうがよい。