8

アプリケーションをマスター/スレーブからHRDに移行中です。すでに移行を行った方からのコメントをお願いします。

  1. 祖先なしで新しいエンティティを投稿し、そのモデルのすべてのエンティティを一覧表示するページにリダイレクトする簡単な例を試しました。私はそれを数回試しました、そしてそれは常に一貫していました。それらに500のインデックス付きプロパティを配置し、常に一貫性を保ちます...

  2. また、エンティティグループごとに1秒あたり1 put（）という制限があるという主張も心配でした。私は同じ祖先を持つ30個のエンティティをput（）しました（同じHTTPリクエストですが、put（）を1つずつ）。基本的に、祖先なしで30個のエンティティを置くことと違いはありませんでした。（私はNDBを使用していますが、何らかの最適化を行っている可能性がありますか？）

トラフィックのない空のアプリでこれをテストしましたが、実際のトラフィックが「結果整合性」にどの程度影響するのか疑問に思っています。

ローカル開発で「結果整合性」をテストできることを認識しています。私の質問は：

結果整合性を処理するために、本当にアプリを再構築する必要がありますか？

または、結果整合性が実際には99％一貫しているため、結果整合性をそのままにしておくことは許容されますか？

4

3 に答える 3

1

小さなアプリの場合、データはおそらく同じディスクの同じ部分にあり、インスタンスは 1 つです。おそらく結果整合性に気付かないでしょう。アプリが成長するにつれて、より多くのことに気付きます。通常、一貫性に達するまでに数ミリ秒かかりますが、1 時間以上かかるケースを見たことがあります。

一般に、クエリは最も注目される場所です。影響を軽減する 1 つの方法は、キーのみでクエリを実行し、ndb.get_multi() を使用してエンティティをロードすることです。キーでエンティティをフェッチすると、そのエンティティの最新バージョンを確実に取得できます。ただし、キー リストの一貫性が高いとは限りません。そのため、クエリ条件に一致しないエンティティを取得する可能性があるため、エンティティをループして、一致しないエンティティをスキップします。

私が気づいたことから、結果整合性の痛みは、アプリが成長するにつれて徐々に大きくなります。ある時点で、それを真剣に受け止め、コードの重要な領域を更新して処理する必要があります。

于 2014-02-12T01:17:39.930 に答える
0

レプリケーション速度は、主にサーバーのワークロードに依存します。通常、アンロードされたシステムでは、レプリケーションの遅延はミリ秒になります。

しかし、「結果整合性」の考え方は、それに依存しないようにアプリを作成する必要があるということです。レプリケーションの遅延は、アプリケーションの制約内で許容できる必要があります。

于 2012-11-19T16:17:01.537 に答える
0

一貫性のない結果が得られた場合の最悪のケースは何ですか?

  • 重要ではない古い情報がユーザーに表示されますか? それはおそらく大丈夫です。

  • 何かの価格など、何か重要なことを誤って計算しますか? それとも店舗の在庫数？その場合、その偶然の発生は避けたいと思うでしょう。

観察のみから、データセットが大きくなるにつれて、最終的に一貫した結果がより多く表示されるように見えます.データがより多くのタブレットに分割されているのではないかと思います.

また、キー/ID による get() リクエストでエンティティを読み戻す場合、常に一貫性が保たれます。結果的に一貫性のある結果を得るためにクエリを実行していることを確認してください。

于 2012-11-19T16:08:14.997 に答える