3

私は最初のアプリを持っていますが、それほど大きくはありませんが、これは最初のステップです。（途中で次の大きなもの）

これを自分の Linode VPS に配置したい場合は、mod_python or mod_wsgi,memcache、Ngix、mySQL、Postgresql などと同様に構成して機能させる必要があります。GAE と言えば、GAE の API を使用するようにモデルを変換するだけです。

私が GAE で気に入っているのはスケーリングです。(本当にできるなら)

そうすれば、ロード シェア/バランス、キャッシュ、データベース / IO の冗長性などを心配する代わりに、アプリの開発とそれらの SEO 作業だけを心配することができます。

後で移植したくありません。（私は今決めなければならない、そしてそれに固執しなければならない）

それで、これについて何か経験があるなら、あなたは何をお勧めしますか：

1- Use VPS(s) for everthing
2- Use VPS(s) plus Amazon S3
3- Use VPS(s) plus Amazon S3 & SimpleDB
4- Use GAE

また: BigTable を使用するときに JOIN 権限を持たなくても済むでしょうか?

注: 今は空間的な必要はありませんが、後で場所テーブルが必要になる可能性があります。

どう思うか知りたいです！

4

6 に答える 6

3

ビジネスリスクと技術リスクがあります。

ビジネス上のリスクは、何らかの外的理由で後でホストを移動しなければならない可能性があることです。VPS、EC2 などは、より多くの先行投資を必要としますが、独立性を保ちます。Chefなどのツールは、構成作業に役立ちます。

技術的なリスクは、アプリケーションがプラットフォームに簡単に実装されない可能性があることです。ほとんどの VPS オプションでは任意のソフトウェアをインストールできるため、これを最小限に抑えることができますが、これも構成作業が増えるという犠牲を伴います。私の知る限り、GAE が強制する最大の制約は、長時間実行されるバックグラウンド タスクを実行するのが難しいことです。(JOIN や非正規化されたデータのその他の側面を使用せずに作業するには、別の考え方が必要ですが、SQL データベースが単一のホストでサポートできるサイズを超えると、Web アプリケーションがどこで実行されるかに関係なく、このアプローチはかなり一般的になります。)

これらの両方のリスクに耐えることができる場合、GAE はかなりの量の労力を節約するように見えます。これらのリスクに耐えられない場合は、独自の環境を調整する必要があります。

余談ですが、S3 は環境に関係なく価値があると思います。ローカル サーバーの静的ファイル ストレージを確実にバックアップするよりもはるかに簡単で、容量について心配する必要はありません。アップロードされているが、めったに上書きまたは削除されないデータ (Facebook のフォト アルバムを考えてください) に使用するのが最適です。

于 2009-06-05T03:51:35.603 に答える
2

後で移植したくありません。（私は今決めなければならない、そしてそれに固執しなければならない）

だったら最初から展開をコントロールした方がいいんじゃない？GAE の限界に達した場合 (技術的な限界であろうと、単にアプリの将来の計画に反する Google によるビジネス上の決定であろうと)、後で GAEから移植するのは非常に苦痛になる可能性があります。

また、mod_wsgi の構成、postgres のインストールなどは特に難しいことではありません。負荷分散やデータベースの冗長性などについては、まだしばらく心配する必要はありません。

私だったら、GAE の迅速な勝利よりも、従来のサーバーの長期的な確実性を好みます。ただし、それはアプリに対するあなたのビジョン次第です。

于 2009-06-05T03:14:39.593 に答える
1

決定する前に、アプリをGAEに簡単にプロトタイプで適合させる価値があるかもしれません。あなたは決定を強制するストッパーに遭遇するかもしれません。考えられるストッパーの問題は次のとおりです。

  • スキーマがBigTableに移行しません
  • GAEがサポートしていないCベースのライブラリに依存しています
  • GAEが課すしきい値を超える実行中のリクエストがいくつかあります
于 2009-06-05T02:29:32.960 に答える
1

私は偏見を持っているかもしれませんが、GAE の制限を受け入れることができれば、実際に多くの作業を節約でき、システム管理の問題 (およびある程度のスケーリング) を心配する必要がなくなります。さらに、リソースの消費量が少ない限り (基本的にはトラフィックが少ないことを意味します)。

結合なしでできますか？私はあなたのアプリを知らないのでわかりません-私自身、SQLの狂信者ですが、十分に単純なニーズのために、適応するのがそれほど難しいとは思いませんでした. 私が見ているように、非リレーショナル DB の主な制限は、「アドホック」クエリのリレーショナル DB ほど優れていないことです...通常、適切な SELECT を 1 つまたは 2 つ使用する代わりに、多くの手続き型コードを作成する必要があります。 :-(。ただし、これは Web アプリの提供に関連する問題というよりは、「後でデータ マイニングを行う」問題です。おそらく、Web アプリのオンライン ストレージから定期的にデータを一括ダウンロードして、「データ ウェアハウス」のような設定を行うことで解決するのが最善でしょう。とにかく、そもそもそのようなストレージがリレーショナルだったとしても;-)。

于 2009-06-05T01:59:12.413 に答える
0

私がしなければならないことは、GAE の API を使用するようにモデルを変換することだけです。

すみません、あなたは完全に間違っています。

viewsまた、ORM を使用するすべてのコードを書き直す必要があります。結合はありません。そのため、必要なものをすべて提供する気の利いた SQL の代わりに、多くの手続き型コードを処理して記述する必要があります。

クエリが遅い。各モデルの save メソッドをオーバーライドして、そのモデルの追加情報を保存する必要があります。これは、必要に応じて計算に時間がかかる場合があります。memcacheまた、クエリを十分に高速化するために作業する必要があります。

そして、Guido は、Django 1.1 が Appengine の将来のバージョンに含まれる予定であると述べています。すぐに使用できる汎用 ORM から BigTable マッパーへの対応を望んでいます。

とはいえ、アプリが多くの結合を必要としない単純なものであれば、appengine パッチ プロジェクトを使用して、Appengine で現在のバージョンの django を使用できます。方法は次のとおりです。

于 2009-06-05T15:10:45.917 に答える
0

答えは、モデル レイヤーの複雑さと性質によって異なります。コードが複雑であるか、コードの残りの部分に密接に結びついている場合、移植はかなりの労力になる可能性があります。それがかなり簡単であるか、引き裂いて交換するのが簡単であれば、私はそれを選ぶと思います.

最近は主に GAE の新しいコードを作成していますが、1 つのコマンドで簡単にデプロイできるという事実により、クールな新しいアプリを作成する際の障壁が本当に低くなりました。展開とホスティングについて心配する必要がないということは、非常に解放的です。

于 2009-06-05T03:22:11.637 に答える