「Amazon Book Reminder」ですが、色々と大変です。

ちょっとプログラミング寄りな投稿になります。


「Amazon Book Reminder」というアプリを作成して公開している事を以前投稿しました。

しかし、このアプリを構築し公開しているGoogleAppEngineという環境があるのですが、最近その環境を利用する為の料金体系が変更になり、色々と大変な事になっています。
料金体系を細かく分けて、機能別に料金を徴収するように変更されました。





プログラムの書き方を根本的に変えなければいけないようです。
まあ私のプログラムの書き方が悪かったというか、あまりGoogleのBigtableの特性を考えない使い方をしていました。

一番の問題はBigtableのDatastoreに対する読み込み処理の回数が閾値を超えてしまっていることです。
閾値を超えるとどうなるかというと、エラーをログに出力し、プログラムの実行が強制的に終了されてしまいます。



私がプログラムでデータを扱うとなると、長く使ってきたのはORACLEという商用データベースです。
ついついBigtableに対してもORACLE的な使い方をしていました。

ORACLEではSQLという仕組みを利用してデータを検索します。
ORACLEではいかに複雑にSQLを組み上げて効率的に速くデータを検索するかに力点をおいて作業をしていました。

しかしBigtableのDatastoreに対してはあまり複雑なSQLが記述できません。
そもそもBigtableとORACLEでは仕組みが全く異なります。
ORACLEはリレーショナルデータベース、Bigtableは分散Key-Valueという仕組みというか考えに基づいて設計されています。



BigtableのDatastoreに対して以下のように処理していました。

・簡単な絞り込みができるSQLを発行しデータを取り出す。
・取り出したデータをループ処理でぐるぐる回す。
・ループの中でさらに絞り込みの判断を行い、その判断をパスしたデータを使用する。
というような段階を踏んで処理を実行していました。

しかし上記のような処理方法だと無駄なデータ読み込みが発生してしまいます。
これがデータ読み込み回数が閾値を超えてしまう大きな原因だと判断しています。
もう少しGoogleのDatastoreにあった使い方を勉強する必要があります。




また、新刊情報をAmazonに問い合わせてメールを発行する夜中の処理では、問題が発生した際にデータの追跡が行えるようにテンポラリー的なデータの置き場所を確保して、処理の過程で発生したデータをそこに書き込んでいます。
これがデータ書き込みの回数を上げている原因だと考えています。
データ書き込みに関しては閾値を超えていませんが、データ読み込みが改善されると、次は書き込みの回数が上がるものだと考えています。

とりあえず今は天井知らずで課金される可能性がありますので、課金オプションはOFFにしています。



実はアプリのメインページでは裏側で様々なデータを読み込んでいます。
なので、アプリの認証後のメインページへの遷移の段階でエラーで落ちてしまいます。
閾値に近ければ認証画面で落ちてしまうかもしれません。

幸いなことに今まで登録して頂いていたデータに関しましては夜間処理を工夫して、一日に処理できる処理は減ってしまいましたが、なんとか新刊メールは送信できている状態です。
ただタイミングが悪いと新刊が発売された後で新刊情報のメールが送付されるというような事が発生してしまいます。
問題発生前ですと登録データをAmazonデータと突合させるのは１つのデータに対して5日に１度は突合されるようにしてきましたが、今ではそれが出来ていません。




とりあえず漏れがないように購入する、という使い方をされている方に対しては影響はありません。
新刊メールは遅れて送信される可能性はありますが、新刊が出たよ、という情報は届きますので。

しかし、新刊を早く手に入れたい、と思われている方にはそのような使い方は現在は出来ません。
ただAmazonを使っている限り、たとえ予約していても発売日より２～３日遅れて届くことは当然のことだと思われますので、あまりそのような使い方をしている方はいらっしゃらないと想定しています。




不幸なタイミングというか、このタイミングで私は転職してしまいましたので、平日はもちろん休日もあまりプログラムの修正に時間を割くことが出来ません。

大変申し訳ございませんが、気長に修正をお待ち頂ければと思います。