High Replication Datastoreの扱いに困る話

第一章　はじめに

前回のエントリで書いたように、GAEのPython2.7で使えるDatastoreは、High Replication Datastore(HRD)というやつ一択で、こいつの扱いが難しいのに困っている。


具体的には、クエリの整合性が担保されないということなのだそうな。

・キーを使ったアクセスは「問題なし」
・祖先クエリ（Entityの親子関係を使ったクエリ）は「問題なし」
・その他のクエリは「過去の状態に基づく結果が返る可能性がある」


なので強い整合性を必要とする場合、memcacheやら何やらを駆使して、解決せよ、というのがGoogle始め、各人の御宣託なのであるが、しかし、memcacheも消えることがあるのだし、どうしようか。というお題である。

第二章　解決策

そこで考えたのが、

• Datastoreへのアクセスをラッパーするクラスを作って、書き込み時はmemcacheにも必ず書き込む。
• クエリは、ラッパーを経由することで、Datastoreに対する検索結果とmemcacheのデータをマージして返す。
• クエリもパターン化されているなら、クエリの結果もキャッシュしておく。
• と、そこまでやってもmemcacheは消えることもあるので、Datastore操作ログをDatastoreに残す。ログは全数にアクセスできないといけないので、Key名はプログラム的に推定可能なものを採用する。

ということ。

第三章　問題点

よし。ここまでやりゃ大丈夫か。いや、トランザクションとか使うともっとややこしいことになるが。

ただ、機能的には大丈夫なんだが、問題もある。

• 「Datastoreに対する検索結果とmemcacheのデータをマージ」するコスト（CPU時間）がバカにならない気がする。
• 特にmemcacheデータが増えてきた場合。
• なので、memcacheを定期的に捨てないといけないのだが、Datastoreへのクエリがいつになったら整合性が取れるのか分からないので、捨て時がわからない。
• あるクエリの実行結果がmemcacheと一致するなら「そのクエリに関しては」整合性が取れたと言えるのだろうが、別のクエリでも一致するとは限らない（と思う）ので完全に整合性が取れたと言い切れるタイミングが図れない。
• Datastore操作ログもmemcacheと同様に捨て時がわからない。

ふ～む、困ったね・・・。

第四章　HRDで整合が取れるまでの時間とは

で、実際HRDで整合性取れるのってどのくらいかかんのよ、ってことで実験してみたよ。

• Datastoreにput()する
• 直後に「put()したデータだけ」がひっかかるはずのクエリを投げる
• 引っ掛かった件数が1なら整合、それ以外なら不整合と判定する

結果：必ず一件取れた。おいおい・・・、優秀じゃねーか。

ん～、データが軽すぎるのかも知れない。プロパティ数が数個かつエンティティ数も100件程度じゃ、あっという間にインデックスが構築されてしまう模様。

じゃ、プロパティを26個まで増やし、エンティティ数も1000件程度の状態まで持って行ったらどうか。

結果：数百回試して1回だけ0件となった。

なるほどね・・・。
スクリプト言語であるPythonごときの処理速度では、インデックス構築完了より先にクエリは投げられんよ、と、そういうことか？

てーことは、何？上に書いたような対策は杞憂なの？やりすぎなの？
でもさー、保証されてないんだから考えちゃうよね、そりゃ。

第五章　終幕

とかって実験しているうちに、Over Quotaとなった。。。

新料金体系では、無料枠は
Datastore Write Operations : 0.05 Million Ops
となっているので、Write Opsは5万回まで。

Write Opsってput()とdelete()の回数ですか？って甘かった。
put()/delete()の際のインデックスの更新もWrite Opsに含まれるんだってよ、奥さん！

インデックスは、Keyと、プロパティ１個１個に対して昇順と降順のインデックスが作られるので、
・データそのもの(1)
・Key用インデックス(1)
・プロパティの昇順、降順（プロパティ数 x 2）
だけのWrite Opsが発生するんだって！一回のput()で！

上記の実験では26個のプロパティを用意したので、一回当たり 1 + 1 + 26 * 2=54 Ops

5万 ÷ 54 ＝ 約1000

そう。たった1000回(未満)のput()でOver Quotaなのであった。
なーんーだーよー。

ろくろく実験もできねーじゃねーか。

なんかもー、こんな対策考えてる時点でベンダーロックインされまくってる弊害がありありだし、別に安くもなくなっちゃったし、もうGAEやめちゃおっかな、とか思うんだが・・・。