DatastoreのQuota制限におけるサイズの解釈等について
風柳
Quotaでの)Limited状態となっていました。
ところが、Datastore StatisticsやDatastore Adminで確認した限り、容量は
合計しても約400MBであり1.00GBの制限にかかりそうに思えなかったのですが
これはこういうものなのでしょうか？
いくらなんでも容量が目安の半分以下でQuotaにかかるとは考え辛いようにも
感じるのですが……。
なお、約400MB中約340MBが1種類のモデル(db.Model)で占められておりました。
※平均サイズが2KB強・約16万件強のデータ。
また、上記のデータを簡便に削除する方法はありますでしょうか？
とりあえず500件ずつ削除するような処理で試したところ、約6万件弱を削除
したところで、6.50 CPU Hoursを使い果たしてしまい……。
※500件削除辺り約200000cpu_ms=200cpu_sec……こんなにかかるもの？
Datastore Adminの機能で一括削除がありますが、
http://code.google.com/intl/en/appengine/docs/adminconsole/datastoreadmin.html#Deleting_Entities_in_Bulk
に
| Warning! Deleting entities in bulk happens within your application,
and thus counts against your quota.
とあったので、途中でCPU Timeを使い果たしておかしなことになったらと思い
怖くて試せていません……。
Takashi Matsuo ♟
先日、自分のアプリが、DashboardやQuota Detailsでみたときに、100%で(Free
Quotaでの)Limited状態となっていました。
ところが、Datastore StatisticsやDatastore Adminで確認した限り、容量は
合計しても約400MBであり1.00GBの制限にかかりそうに思えなかったのですが
これはこういうものなのでしょうか？
いくらなんでも容量が目安の半分以下でQuotaにかかるとは考え辛いようにも
感じるのですが……。
なお、約400MB中約340MBが1種類のモデル(db.Model)で占められておりました。
※平均サイズが2KB強・約16万件強のデータ。
また、上記のデータを簡便に削除する方法はありますでしょうか？
とりあえず500件ずつ削除するような処理で試したところ、約6万件弱を削除
したところで、6.50 CPU Hoursを使い果たしてしまい……。
※500件削除辺り約200000cpu_ms=200cpu_sec……こんなにかかるもの？
Datastore Adminの機能で一括削除がありますが、
http://code.google.com/intl/en/appengine/docs/adminconsole/datastoreadmin.html#Deleting_Entities_in_Bulk
に
| Warning! Deleting entities in bulk happens within your application,
and thus counts against your quota.
とあったので、途中でCPU Timeを使い果たしておかしなことになったらと思い
怖くて試せていません……。
--
このメールは Google グループのグループ「Google-App-Engine-Japan」の登録者に送られています。
このグループに投稿するには、google-app-...@googlegroups.com にメールを送信してください。
このグループから退会するには、google-app-engine...@googlegroups.com にメールを送信してください。
詳細については、http://groups.google.com/group/google-app-engine-japan?hl=ja からこのグループにアクセスしてください。
--
Takashi Matsuo
Developer Relations
Developer Advocate for Google App Engine/iGoogle
Google Japan, Inc.
風柳
を付加して再送しております。
===============================================================================
| > 先日、自分のアプリが、DashboardやQuota Detailsでみたときに、100%で(Free
| > Quotaでの)Limited状態となっていました。
| >
|
| storage の課金額は非常に安いので少し予算をあてがってみてはいかがですか？
うーん、試しに作って放置してあったアプリなもので今更かな、という感じなのです
よね(苦笑)。
とりあえず Datastore にデータを置かなくても動くように改修してしまいましたし。
| > ところが、Datastore StatisticsやDatastore Adminで確認した限り、容量は
| > 合計しても約400MBであり1.00GBの制限にかかりそうに思えなかったのですが
| > これはこういうものなのでしょうか？
| > いくらなんでも容量が目安の半分以下でQuotaにかかるとは考え辛いようにも
| > 感じるのですが……。
| >
|
| task の payload なども全体の storage quota に関係してきます。そちらはどうでしょう。
| それでもおかしいということでしたら app-id を教えていただけますか？調べてみます。
| app-id はグループ宛に送信するのが気になるようでしたら個人宛でも良いです。
taskのpayloadとはDashboard／Quota Detailsで確認できる項目でしょうか？
すみません、どこを見ればよいか解らなかったので……。
※なお、Total Stored Data以外のStorageの項目は、ほぼ0に近い値です。
とりあえず、app-idは hatena-anohito になります。
あ、それと現在は30分に1回、500件を削除するようなCron Jobが走っているため、
下記記載値よりも徐々に減少してきております。
※ 500件/30分→24000件/日→約50MB/日→約0.05GB/日ずつ減少する計算です。
※ 2011/05/13 日本時間23時過ぎで、Datastore Adminの dbUserInfo は
Entities 86,010 Avg. Size/Entity 2 KBytes Total Size 179 MBytes
（これの他は8MB程）
Total Stored Dataは77%で0.77 of 1.00 GBytes
と表示されています。
※ 2011/05/20 現在、当該エントリは削除完了しており、
Total Stored Dataは 7%で0.07 of 1.00 GBytes
と表示されています。
以下、Billing Historyより。
Usage Report for 2011-05-09: Stored Data: 1.01
Usage Report for 2011-05-10: Stored Data: 0.76
Usage Report for 2011-05-11: Stored Data: 0.58
Usage Report for 2011-05-12: Stored Data: 0.40
Usage Report for 2011-05-13: Stored Data: 0.26
Usage Report for 2011-05-14: Stored Data: 0.16
Usage Report for 2011-05-15: Stored Data: 0.07
1.01GB→0.07GBで、0.94GB容量が減っていることになりますが、この間に削除した
データは実際には合計約340MB(平均2KB強・約16万件強のエントリ)に過ぎません。
差分の約0.6GBは何に相当する値なのでしょう？
課金を検討する上でも、Datastore Statistics/Datastore Adminで表示されるSizeと
Quota Details/Billing HistoryのStored Dataの値がここまでかけ離れていては少々
不安になってしまいます。
| > なお、約400MB中約340MBが1種類のモデル(db.Model)で占められておりました。
| > ※平均サイズが2KB強・約16万件強のデータ。
| >
| > また、上記のデータを簡便に削除する方法はありますでしょうか？
| > とりあえず500件ずつ削除するような処理で試したところ、約6万件弱を削除
| > したところで、6.50 CPU Hoursを使い果たしてしまい……。
| > ※500件削除辺り約200000cpu_ms=200cpu_sec……こんなにかかるもの？
| >
|
| Entity に付いている Index が多かったりしますか？
| 僕の経験からも多すぎるように思いますけれど、どのように削除をしていますか？
dbUserInfoというモデルですが、こちらにはIndexは作成しておりません。
※Datastore Indexesは別テーブル用のものが二つだけです。
削除は、
entries=dbUserInfo.all().fetch(500)
db.delete(entries)
のように500件ずつ削除する処理を、taskqueueで順次呼び出すような処理にしていま
した。
※上述のように、アプリの作りを変更した結果、全データを削除して構わなくなった
ため、単純な処理になっております。
| > Datastore Adminの機能で一括削除がありますが、
| >
| > http://code.google.com/intl/en/appengine/docs/adminconsole/datastoreadmin.html#Deleting_Entities_in_Bulk
| > に
| > | Warning! Deleting entities in bulk happens within your
application,
| > and thus counts against your quota.
| >
| > とあったので、途中でCPU Timeを使い果たしておかしなことになったらと思い
| > 怖くて試せていません……。
| >
|
| CPU Time を使い果たしても Task が失敗するようになるだけで、翌日になれば動き出すはずですよ。
普通にアプリやremote_apiで削除する場合と同様と考えてよいのですね。
もっとも約6万件削除でFreeでは1日使えなくなるので、全データ(16万件)削除だと3日
間弱、実質全く使えなくなってしまう計算ですが(苦笑)。
| まあ CPU の課金レートも安いので少し予算を割り当ててはいかがですか？
$0.10/CPU hourをどう考えるか、ですよね……。
上記の例では、10万件のエントリ削除で約11cpu_hours、約$1.1かかるわけで。
本運用サービスがOver Quotaで停まるリスクを考えると$1.1なんて安いものととるか、
高々10万件のデータ削除程度で$1以上かかるのか、と驚くか。
自分が日常的に使用するアプリなら考えるのですが、試行品の場合はなかなかその気に
ならず……申し訳ありません。
On 5月13日, 午後10:54, Takashi Matsuo ♟ <tmat...@google.com> wrote:
> On Fri, May 13, 2011 at 6:26 AM, 風柳 <fury...@gmail.com> wrote:
> > 先日、自分のアプリが、DashboardやQuota Detailsでみたときに、100%で(Free
> > Quotaでの)Limited状態となっていました。
>
> storage の課金額は非常に安いので少し予算をあてがってみてはいかがですか？
>
>
>
> > ところが、Datastore StatisticsやDatastore Adminで確認した限り、容量は
> > 合計しても約400MBであり1.00GBの制限にかかりそうに思えなかったのですが
> > これはこういうものなのでしょうか？
> > いくらなんでも容量が目安の半分以下でQuotaにかかるとは考え辛いようにも
> > 感じるのですが……。
>
> task の payload なども全体の storage quota に関係してきます。そちらはどうでしょう。
> それでもおかしいということでしたら app-id を教えていただけますか？調べてみます。
> app-id はグループ宛に送信するのが気になるようでしたら個人宛でも良いです。
>
>
>
> > なお、約400MB中約340MBが1種類のモデル(db.Model)で占められておりました。
> > ※平均サイズが2KB強・約16万件強のデータ。
>
> > また、上記のデータを簡便に削除する方法はありますでしょうか？
> > とりあえず500件ずつ削除するような処理で試したところ、約6万件弱を削除
> > したところで、6.50 CPU Hoursを使い果たしてしまい……。
> > ※500件削除辺り約200000cpu_ms=200cpu_sec……こんなにかかるもの？
>
> Entity に付いている Index が多かったりしますか？
> 僕の経験からも多すぎるように思いますけれど、どのように削除をしていますか？
>
> > Datastore Adminの機能で一括削除がありますが、
>
> >http://code.google.com/intl/en/appengine/docs/adminconsole/datastorea...
najeira
> 1.01GB→0.07GBで、0.94GB容量が減っていることになりますが、この間に削除した
> データは実際には合計約340MB(平均2KB強・約16万件強のエントリ)に過ぎません。
> 差分の約0.6GBは何に相当する値なのでしょう？
複合インデックスを使わなくても、シングルプロパティインデックスがあります。
また、タスクで使用したデータもカウントされます。
僕も、Statisticsの2.5倍ほどのStored Dataになっています。
> | > とりあえず500件ずつ削除するような処理で試したところ、約6万件弱を削除
> | > したところで、6.50 CPU Hoursを使い果たしてしまい……。
> | > ※500件削除辺り約200000cpu_ms=200cpu_sec……こんなにかかるもの？
特に違和感ある数字ではないです。
> dbUserInfoというモデルですが、こちらにはIndexは作成しておりません。
プロパティいくつくらいありますか？
> 削除は、
> entries=dbUserInfo.all().fetch(500)
> db.delete(entries)
keys_onlyを指定したほうがよいです。
上記のクエリだと、クエリ自身のcpu消費が大きいです。
keys = dbUserInfo.all(keys_only=True).fetch(500)
db.delete(keys)
これでだいぶ違うはずです。
また、Stored Dataが安いので、データは削除せずに、
そのまま放置しておくのもありだと思います。
CPUのほうが高いので。
Ian Lewis
イアンです。
> | まあ CPU の課金レートも安いので少し予算を割り当ててはいかがですか？
>
> $0.10/CPU hourをどう考えるか、ですよね……。
> 上記の例では、10万件のエントリ削除で約11cpu_hours、約$1.1かかるわけで。
> 本運用サービスがOver Quotaで停まるリスクを考えると$1.1なんて安いものととるか、
> 高々10万件のデータ削除程度で$1以上かかるのか、と驚くか。
>
> 自分が日常的に使用するアプリなら考えるのですが、試行品の場合はなかなかその気に
> ならず……申し訳ありません。
10万件を削除するのが11CPU時間かかるのがそもそもおかしいようなきがしますね。僕は12個親エンティティに対して1分間毎にエンティティを作成して、毎日一日分のエンティティをタスクキューでまとめて削除しているアプリを運用していますが、全部で 3、4CPU 時間くらいかかるものです。60*24*12 = やく17万件。
データストアが遅れたりする感じなんでしょうか? 他にCPU時間をなめている処理がないよね? urlfetch とか。
エンティティはプロパティに対してインデクスが作成されるので、プロパティが多いと思うより大きいデータ量になるとおもいます。相当な数にいかない限り大丈夫と思うけど、プロパティが多くありませんか?
とにかく、11時間はかかり過ぎるので、何か情報足りないような気がします。
Ian Lewis
イアンです。
> > | > とりあえず500件ずつ削除するような処理で試したところ、約6万件弱を削除
> > | > したところで、6.50 CPU Hoursを使い果たしてしまい……。
> > | > ※500件削除辺り約200000cpu_ms=200cpu_sec……こんなにかかるもの？
>
> 1件削除あたりで400msですね。
> 特に違和感ある数字ではないです。
補足ですが、1件あたり400msがかなり遅いと思いますよ。
風柳
| 差分はインデックスなどだと思います。
| 複合インデックスを使わなくても、シングルプロパティインデックスがあります。
インデックスはてっきりDatastore Statisticsで表示されるMetadata中に含まれるの
だと思っていましたが違ったのですね、お恥ずかしい。
ついでといってはなんですが、インデックス分のサイズを把握するような方法はある
のでしょうか？
| また、タスクで使用したデータもカウントされます。
これがよくわかりません。
『タスクで使用されたデータ』とは具体的に何にあたるのでしょう？
| 1件削除あたりで400msですね。
そんなものなんでしょうか……。
| プロパティいくつくらいありますか？
プロパティは9個です。
内訳は、
IntegerProperty：2
StringProperty：3
TextProperty：1
DateTimeProperty：3
となっていました。
※ちなみに、親子関係は持たないエンティティです。
| keys_onlyを指定したほうがよいです。
| 上記のクエリだと、クエリ自身のcpu消費が大きいです。
remote_apiを使用したときの1例ですが、500件の場合、
・fetch()に 5249cpu_ms (keys_only未指定)
・db.delete()に 186756cpu_ms
要していました。
※remote_apiの場合はそれぞれの処理についてHTTP-Requestが出されるので、cpu値は
ログで確認したものです。
keys_onlyを指定してfetch()分が多少削減されたとしても誤差の範囲かと思います。
| また、Stored Dataが安いので、データは削除せずに、
| そのまま放置しておくのもありだと思います。
| CPUのほうが高いので。
(Freeのまま)別のことに使いたかったものですから…(苦笑)。
風柳
| 全部で 3、4CPU 時間くらいかかるものです。60*24*12 = やく17万件。
あれ、通常はその程度なんでしょうか……。
だとすると、私のケースはやはり少し変な気がしますね。
| データストアが遅れたりする感じなんでしょうか? 他にCPU時間をなめている処理がないよね? urlfetch とか。
ないです。
特に後半は、cronで1分あたり500件削除するだけのシンプルな処理でしたが、やはり
一貫して1回につき200,000cpu_ms前後を要していました。
| プロパティが多くありませんか?
上でも書きましたが、プロパティは9個です(なお、ListPropertyは持っていません)。
On 5月21日, 午前12:24, Ian Lewis <ianmle...@gmail.com> wrote:
> イアンです。
>
> > | まあ CPU の課金レートも安いので少し予算を割り当ててはいかがですか？
>
> > $0.10/CPU hourをどう考えるか、ですよね……。
> > 上記の例では、10万件のエントリ削除で約11cpu_hours、約$1.1かかるわけで。
> > 本運用サービスがOver Quotaで停まるリスクを考えると$1.1なんて安いものととるか、
> > 高々10万件のデータ削除程度で$1以上かかるのか、と驚くか。
>
> > 自分が日常的に使用するアプリなら考えるのですが、試行品の場合はなかなかその気に
> > ならず……申し訳ありません。
>
> 10万件を削除するのが11CPU時間かかるのがそもそもおかしいようなきがしますね。僕は12個親エンティティに対して1分間毎にエンティティを作成して、毎 日一日分のエンティティをタスクキューでまとめて削除しているアプリを運用していますが、全部で
風柳
| keys_onlyを指定してfetch()分が多少削減されたとしても誤差の範囲かと思います。
keysのみにすると、db.delete()自体の速度も速くなるのでしょうか？(こちらは試していなかったです)
そうだとしたら申し訳ないです。
風柳
なお、作成したエントリは、必須要素(id)以外は空としました。
※DateTimePropertyのうち2つはauto_now_addまたはauto_nowがTrueなので
自動で設定されますが。
■ エントリの実体を取得した場合
entries=db.put([dbUserInfo(id=str(c)) for c in range(500)])
# → /_ah/remote_api 200 1878ms 68870cpu_ms 68800api_cpu_ms
entries = dbUserInfo.all().fetch(500)
# → /_ah/remote_api 200 499ms 5062cpu_ms 4595api_cpu_ms
db.delete(entries)
# → /_ah/remote_api 200 1878ms 68870cpu_ms 68800api_cpu_ms
■ keyのみを取得した(keys_only=Trueをつけた)場合
entries=db.put([dbUserInfo(id=str(c)) for c in range(500)])
# → /_ah/remote_api 200 2262ms 83236cpu_ms 82583api_cpu_ms
keys = dbUserInfo.all(keys_only=True).fetch(500)
# → /_ah/remote_api 200 285ms 475cpu_ms 429api_cpu_ms
db.delete(keys)
# → /_ah/remote_api 200 1456ms 68886cpu_ms 68816api_cpu_ms
・keys_onlyを指定した場合、fetch()のcpu_msは5062→475と速くなる。
・keysで指定した場合でも、db.delete()のcpu_msは68870→68886と大差無い。
・以前試したときと比較して、db.delete()の所要時間は何故か短くなっている。
※186756cpu_ms → 68870cpu_ms
cronで500件ずつ削除していたころのログを遡ってみたところ、
2011-05-11 00:37:34.209 /d/?clear=1&all_user=1 200 3897ms 200398cpu_ms
199021api_cpu_ms
2011-05-12 21:40:47.108 /d/?clear=1&all_user=1 200 3736ms 172311cpu_ms
171238api_cpu_ms
2011-05-13 23:44:21.447 /d/?clear=1&all_user=1 200 3691ms 174235cpu_ms
172788api_cpu_ms
2011-05-14 23:46:55.554 /d/?clear=1&all_user=1 200 3037ms 122358cpu_ms
121471api_cpu_ms
2011-05-15 20:19:18.796 /d/?clear=1&all_user=1 200 3373ms 109198cpu_ms
108171api_cpu_ms
この場合のcpu_msはfetch()＋delete()の合計です。
必ずしもリニアにではありませんが、全数が減ると共に要するcpu_msも少なくなって
いく傾向があるように見えます。
それでも、2011-05-15 20:19:18.796は最後の500件を消したときで、109198cpu_ms
要していますが……。
Ian Lewis
イアンです。
すみません。僕は大きな勘違いをしました。僕はremote_api を使っていません。remote_api を使うとエンティティのデータをHTTP で通信のするので大きな負荷がかかってしまいます。
特にこういう処理をするとデータを全てクライアントまで通信する。もし、どうしても remote_api を使わないといけなければ、najeiraさんがおっしゃったようにkeys _only を使うのがおすすめです。
私がしている方法は全てappengine上で動かす方法でマッパークラスでエンティティを回わってバッチで削除するという方法です。
remote_api はたまにつかってもいいけれど、大きなデータ量を通信してしまうと大きな負荷かかるので、定期的に行うバッチ処理に使うのがおすすめできません。
勘違いをしてしまって申し訳ありません。
> このメールは Google グループのグループ「Google-App-Engine-Japan」の登録者に送られています。
> このグループに投稿するには、google-app-...@googlegroups.com にメールを送信してください。
najeira
ただ、個人的には想定の範囲内です。
いま試しに、
・DateTime 1つ
・Blob 1つ
のエンティティをremote_apiで削除したところ、
60cpu_ms、37api_cpu_msでした。
エンティティのサイズは4KBと60KBで試しましたが、
どちらも同じ値でした。
次に、
・DateTime 1つ
・Int 1つ
・Key 2つ
・Blob 2つ
のエンティティをremote_apiで削除したところ、
119cpu_ms、95api_cpu_msでした。
サイズは2KBくらいのものです。
2回やりましたが同じ値でした。
サンプルが少なくて申し訳ないですが、
プロパティが増えると削除のコストがあがっています。
これは、インデックスの更新が増えるからだと思います。
イアンの、17万件で4CPU時間というのとは大きく差があるので、
remote_apiのコストが大きいのかもしれません。
風柳
cronで500件削除するだけのバッチ処理を行なうタスク(/d/?clear=1&all_user=1)を起動して
いました。
今試しに予め2000件のデータを作っておいて、削除処理を4回実行してみましたが、
※削除の内容は、
keys = dbUserInfo.all(keys_only=True).fetch(500)
db.delete(keys)
/d/?clear=1&all_user=1 200 2153ms 63460cpu_ms 63296api_cpu_ms
/d/?clear=1&all_user=1 200 2001ms 74091cpu_ms 73438api_cpu_ms
/d/?clear=1&all_user=1 200 1775ms 69386cpu_ms 69246api_cpu_ms
/d/?clear=1&all_user=1 200 1584ms 69313cpu_ms 69196api_cpu_ms
のようになりました。
前回のremote_apiによる結果と比較しても、削除のみに限れば、それ程オーバヘッドに
よる結果(cpu_ms値)の差はないようにも見えます。
> で通信のするので大きな負荷がかかってしまいます。
>
> 特にこういう処理をするとデータを全てクライアントまで通信する。もし、どうしても remote_api
> を使わないといけなければ、najeiraさんがおっしゃったようにkeys _only を使うのがおすすめです。
>
> 私がしている方法は全てappengine上で動かす方法でマッパークラスでエンティティを回わってバッチで削除するという方法です。
>
> remote_api
> はたまにつかってもいいけれど、大きなデータ量を通信してしまうと大きな負荷かかるので、定期的に行うバッチ処理に使うのがおすすめできません。
>
> 勘違いをしてしまって申し訳ありません。
風柳
ようにして測定してみました。
※keys_only=Trueで1回辺り500件削除です。
|・DateTime 1つ
|・Blob 1つ
/d/?clear=1&test1=1 200 1900ms 27775cpu_ms 27612api_cpu_ms
/d/?clear=1&test1=1 200 1694ms 27685cpu_ms 27545api_cpu_ms
/d/?clear=1&test1=1 200 2810ms 27789cpu_ms 27579api_cpu_ms
/d/?clear=1&test1=1 200 1603ms 27752cpu_ms 27612api_cpu_ms
平均：27750cpu_ms/500エントリ→約56cpu_ms/1エントリ
→1.54cpu_hours/10万エントリ
|・DateTime 1つ
|・Int 1つ
|・Key 2つ
|・Blob 2つ
/d/?clear=1&test2=1 200 1743ms 61052cpu_ms 60912api_cpu_ms
/d/?clear=1&test2=1 200 1730ms 61075cpu_ms 60912api_cpu_ms
/d/?clear=1&test2=1 200 2301ms 61069cpu_ms 60929api_cpu_ms
平均：61064cpu_ms/500エントリ→約122cpu_ms/1エントリ
→3.39cpu_hours/10万エントリ
ほぼnajeiraさんのものと同等のCPU時間という結果になりました。
削除に関しては(keys_only=Trueで有る限り)remote_apiによるオーバヘッドはほとんど
問題とならないようです。
それにしても、先ごろ報告した、9つのプロパティをもつもの(dbUserInfo)で、同じ500件
削除でも、
199021api_cpu_ms
63296api_cpu_ms
これだけの差(1件あたり400ms vs 127ms)があるのは、何が原因なのか気になるところ
ではあります。