29

D0 サイズの Cloud SQL インスタンスがあります。シンプルな

select * from table

これには約 500 行あり、実行に平均 100 ミリ秒かかります (SQL プロンプトで報告)。一方、MySQL 5.5 のローカル インスタンスでは、1 ミリ秒しかかかりません。私の開発マシンには、2.9GHz デュアルコア Intel Core i7 と 8GB 1600MHz メモリがあります。FAQで、db のパフォーマンスはサイズに依存することを読みました。インスタンスが大きいほど、RAM と CPU が多くなります。

これは、インスタンス サイズを大きくすることでパフォーマンスの問題が解決されることを期待するのに妥当ですか? それとも、ここで何か他のものを見逃していますか?

4

5 に答える 5

6

ビューがパフォーマンス低下の原因でした。Google は独自の MySQL エンジンを実行しており、これはビューを損なう可能性がある方法で最適化されています。多くの結合または共用体がある場合、ビューの実行が遅くなることが予想されます。

ただし、この質問を投稿してからほぼ 1 年が経過しており、状況が変わっている可能性があります。ビューの使用をやめてから、ビューを再訪していません。

于 2014-08-16T11:45:39.287 に答える
6

編集: 2016 年 4 月 10 日

GAE は現在、第 2 世代のクラウド mysql を提供しており、「db-g1-small」のような基本的な層でさえ、古い Cloud SQL オファリングの D8 層と同じくらい高速に実行されます。また、大幅に安価です。これは大きなマイルストーンのようであり、もはやハッキングや回避策に頼る理由はありません.

Cloud SQL の料金を参照できますが、おおよその最小料金は月額約 20 ドルです。

元の投稿

Google は、D0 層のスロー ボックスに VM をプロビジョニングするだけです。D4 を選択することもできますが、RAM はプロセッサほど主要な問題ではありません (GHz については言及されていません)。

ネットワーク遅延は問題ではありません。たとえば、以下の 0.05 秒は、サーバーのみでのクエリ実行時間です。その後の任意の時間は、データ送信に費やされる可能性があります。

mysql> select * from tracking limit 5;
+--------------------------------+-----------+-----------+
| id                             | scan_date | status    |
+--------------------------------+-----------+-----------+
| 420006929400111899561510697350 | NULL      | Delivered |
| 420010859400111899561989496058 | NULL      | Delivered |
| 420019849400111899561989496331 | NULL      | Delivered |
| 420100109400111899561903290311 | NULL      | Delivered |
| 420100319400111899561944407020 | NULL      | Delivered |
+--------------------------------+-----------+-----------+
5 rows in set (0.05 sec)

編集: 2016 年 3 月

GAE がアウトバウンド ソケット接続を開いたので、いくつかのアプリでは Cloud SQL を使用しなくなり、代わりにリモートでホストされている基本的な MySql クラスタを使用しています。クレイジーに聞こえますか？数値によるものではありません - このソケット接続を介してクエリを送信し、データを取得することは、同じ場所にある D3 よりも高速です。

于 2014-08-15T20:02:42.310 に答える
3
  1. どこから Cloud SQL インスタンスに接続していますか?
  2. 層のサイズは、パフォーマンスに大きな影響を与えます。インスタンスの層を一時的に変更してテストできます。
于 2013-09-04T17:06:25.240 に答える