55

バックエンドに Parse.com のサービスを使用することを検討していますが、そのスケーラビリティに懐疑的です。

本当に数千人の同時ユーザーを処理できますか? そうでない場合、彼らはそれから移行する良い方法はありますか?

4

9 に答える 9

76

質問が古いかもしれないことは知っていますが、解析を検討している可能性のある他の人に私の2セントを提供したかった....

最も単純なシナリオでは、parse がうまく機能する可能性があります。より複雑なクエリにスケールアップする必要があるとすぐに、私は個人的に頭痛の種しか見つけませんでした.

  1. クエリは 1000 レコードに制限されています。最初は、これは問題ではないと思うかもしれませんが、サブ クエリの処理を開始すると、サブ クエリが警告やエラーなしでレコードを切り捨てるため、奇妙なデータが返されることがわかります。(参考までに、1000 までの制限を指定しない限り、デフォルトは 100 レコードなので、注意を怠ると問題はさらに悪化します)。

  2. 奇妙な理由により、1 分間にカウント クエリを発行できる回数に制限があります。(そして、この制限は非常に低いようです)。この制限に達しないように、コードを調整する準備をしてください。そうしないと、エラーがスローされます。

  3. バックグラウンド ジョブは確実に実行されません。バックグラウンド ジョブを 5 分ごとに実行するように設定しましたが、ジョブが開始されるまでに 20 分以上かかる場合があります。

  4. タイムアウトが多い。これは私に最も胸焼けを与えるものです。A. 処理に時間がかかるクラウド機能がある場合、完了するまでに約 6 ～ 7 秒かかります。
    B. システムが全体的に不安定になっているように感じます。定期的に、タイムアウトがより頻繁に発生する約 1 時間ほど続くように見える問題に遭遇します (そして、すぐに返される比較的単純な関数で)。

私は parse を使用するという決定を完全に後悔しており、プラットフォームから移行できるように、資金を得るのに十分な期間アプリを存続させるためにできる限りのことを行っています。誰かがパースに代わるより良い方法を持っているなら、私はすべて耳にします。

于 2014-06-17T00:04:26.963 に答える
24

アプリのバックエンドとして Parse を選択しました。結論：しないでください。

安定性は災難であり、パフォーマンスも災難であり、サポートも同様です (おそらく、すべての問題が再現不可能であるため、実際には役に立たないためです)。

最も単純な関数を実行しても、Parse 内でランダムなタイムアウトが発生する可能性があります (たとえば、単純な PFUser ログイン呼び出しについて話しています)。

Error: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo=0x17e42480 {NSErrorFailingURLStringKey=https://api.parse.com/2/client_events, NSErrorFailingURLKey=https://api.parse.com/2/client_events, NSLocalizedDescription=The request timed out., NSUnderlyingError=0x17d10e60 "The request timed out."} (Code: 100, Version: 1.2.20)

毎日タイムアウトが発生します。これは、最大 10 ユーザーでテストしているアプリで発生します。

これは、完全に恣意的な瞬間に常に返される典型的なものであり、再現することは不可能です. いくつかのクエリといくつかの挿入を行う Cloud Code 関数を呼び出します。

 {"code":124,"message":"Request timed out"}

10 分後に同じことを試すと、1 秒もかからずに実行されます。20 分後に再試行すると、実行に 30 秒かかります。

トランザクションがないため、たとえば 3 つのオブジェクトを 1 つの Cloud Code 関数に保存すると、とても楽しいものになります。この場合、3 つのオブジェクトのうち 2 つを保存した後、Parse がランダムに関数から抜け出すことを決定します。データベースの一貫性を保つのに最適です。

これらの場所で得た「最高の」もの。これは、Cloud Code 関数から返される実際のデータです。

 {"code":107,"message":"Received an error with invalid JSON from Parse: <!DOCTYPE html>\n<html>\n<head>\n  <title>We're sorry, but something went wrong (500)</title>\n  <style type=\"text/css\">\n    body { background-color: #fff; color: #666; text-align: center; font-family: arial, sans-serif; }\n    div.dialog {\n      width: 25em;\n      padding: 0 4em;\n      margin: 4em auto 0 auto;\n      border: 1px solid #ccc;\n      border-right-color: #999;\n      border-bottom-color: #999;\n    }\n    h1 { font-size: 100%; color: #f00; line-height: 1.5em; }\n  </style>\n</head>\n\n<body>\n  <!-- This file lives in public/500.html -->\n  <div class=\"dialog\">\n    <h1>We're sorry, but something went wrong.</h1>\n    <p>We've been notified about this issue and we'll take a look at it shortly.</p>\n  </div>\n</body>\n</html>\n"}

ここで説明することは、私たちのプロジェクトでブルームーンで一度だけ起こることではありません。500 件のエラー (月に 2 回発生しました) を除いて、他のすべてのエラーは毎日表示されます。

そうです、始めるのは非常に簡単ですが、不安定なプラットフォームで作業していることを考慮する必要があります。そのため、再試行と指数関数的バックオフ システムが稼働していることを確認してください。これが必要になるからです。

私が最も心配しているのは、このバックエンドで 20.000 人が私のアプリを使い始めたら何が起こるかわからないということです。

編集：

現在、PFUserログインを行うときにこれがあります：

Error: Error Domain=PF_AFNetworkingErrorDomain Code=-1011 "Expected status code in (200-299), got 502" UserInfo=0x165ec090 {NSLocalizedRecoverySuggestion=<html><body><h1>502 Bad Gateway</h1>
The server returned an invalid or incomplete response.
</body></html>
, PF_AFNetworkingOperationFailingURLResponseErrorKey=<NSHTTPURLResponse: 0x16615c10> { URL: https://api.parse.com/2/get } { status code: 502, headers {
    "Cache-Control" = "no-cache";
    Connection = "keep-alive";
    "Content-Length" = 107;
    "Content-Type" = "text/html; charset=utf-8";
    Date = "Mon, 08 Sep 2014 13:16:46 GMT";
    Server = "nginx/1.6.0";
} }, NSErrorFailingURLKey=https://api.parse.com/2/get, NSLocalizedDescription=Expected status code in (200-299), got 502, PF_AFNetworkingOperationFailingURLRequestErrorKey=<NSMutableURLRequest: 0x166f68b0> { URL: https://api.parse.com/2/get }} (Code: 100, Version: 1.2.20)

それは素晴らしいことではありませんか？

于 2014-09-06T10:53:43.060 に答える
21

バックエンドにロジックがほとんどまたはまったくない小さな/単純なアプリ (または使い捨てのプロトタイプ) を作成している場合は、それを使用しますが、より大きな/スケーラブルなものの場合は、それを避けるのが最善です。直接の経験から言えます。ユーザー管理、プッシュ通知、抽象化されたストレージなどはすべて良さそうに思えますが、結局のところ、面倒なことをする価値はありません。つまり、私は Parse でアプリのバックエンドを開発していました。クライアントは、それがクールで有望に聞こえたので (私が推測する強力なマーケティング)、それに夢中になり、Facebook などに買収されましたが、生産開始から数週間後に大きな問題/制限が発生しました。プラットフォームが台頭し始めたとき、単純なアプリのはずが、開発とスケーリングの悪夢であることが判明しました。

プロジェクトの結果/結論: - 比較的単純なアプリのタイム ウィンドウを壊した - カスタム スタックを使用した場合、それは 2 ～ 3 か月続くはずでしたが、ほぼ 1 年続きましたが、それでも安定性や信頼性はありません。カスタム ノード スタックを使用して 5 ～ 10 日で同様のデモ プロジェクトを作成したため、時間枠内で確実に実行する必要があります - クライアントの信頼を失い、カスタム スタックを使用する別のチームでアプリを作り直しています -時間枠を破り、それを機能させようとしたために多額の現金を失いました - それが私の健康を反映し始めたほどの残業をしました - すべてを約束するプラットフォーム/ソリューションを決して使用せず、常にカスタムに従っていきます/試したスタック

最初は、安定性の問題と、サーバーのダウンタイムやランダム エラーなどのプラットフォームの絶え間ない障害でしたが、それらはすべて解決されました (2014 年の初めから半ばまで) が、次の問題が残っています。

  • 少なくとも現時点では、コードをデバッグすることはできません (追加のノード サーバーとあいまいなライブラリで動作させる方法があります)。
  • 制限はばかげており、1 秒あたり 50 ～ 60 件の API リクエスト (サブスクリプションによってはそれ以上) を実行できるスケーラブルなプラットフォームであり、ひずみテストを開始するまでそれほど低くはありません。常に失敗します
  • API 呼び出しは次のように測定されます: サーバー関数 (解析ジョブ) の呼び出し - 1 回の呼び出し、データベースのクエリ - 1 回の呼び出し、別のクエリデータベース スキーマの意味はすぐにわかります) - 1 回の呼び出し、1000 を超えるクエリを取得する必要がある場合は、何を推測しますか - もう一度クエリを実行するなど、カウントのクエリ (別のクエリとして実行する必要があります)信頼できない (数千のエントリの概算を返す傾向がある)
  • 1000 以上の単純なオブジェクトを作成/保存すると、プラットフォーム/データベースに負荷がかかり、1000 以上のオブジェクトを削除するとさらに負担が大きくなり、通常のデータベースでは途方もなく高速ですが、Parse では 5 ～ 10 分かかる傾向があります (チェックした場合より厳密には、バッチごとに 20 個のオブジェクトが削除されます)
  • ほとんどの npm パッケージを使用する方法はありません (ソースを直接含めることによる純粋な JS パッケージのみ)
  • Parseフォーラムに行って読むと、ユーザーがプラットフォームの機能の欠如のためにParseチームに絶えず反対票を投じたりローストしたりしており、ランダムなエントリや同様のものをフェッチするなどの任意のロジック実装のためにフープを飛び越える必要があることがわかります.
  • それらはStripe統合をサポートしていますが、Paypalまたはその他の支払いサービスを使用したい場合（Stripeよりもはるかに優れた国のサポートがあるため、Paypalを使用することにしました）、Parseで動作させることはできません。別のサーバーを使用してそれをやってのける
  • ユーザーを同期して同時実行の問題を処理する簡単な方法はありません。
  • 100 人以上、ましてや 1000 人以上の同時ユーザーが必要です。幸運を祈ります。
  • テーブル内のエントリ数を知りたい場合、count クエリの呼び出しで制限に達する可能性がありますが、これはおかしく、文書化されておらず、まったくばかげており、最終的にはおおよその数を返します。
  • モジュール性はプラットフォームにとって異質であり、ジョブから呼び出す関数は数秒 (7 秒だと思います) しか持続できず、クエリ時間を考慮すると、より複雑なクエリと多くの場合に発生するはずです。いくつかの複雑なロジック
  • Cron ジョブのようなものを使用できますが、15 分以上持続することはできません (非常に短い複数のクエリなどのプラットフォームのパフォーマンスが低いため)。サブスクリプション料金、および非常に制限された/貧弱なスケジューリングシステムが配置されています (たとえば、コードから編集することはできません。非常に制限されているため、ハックを使用して、1 日の 2 つの正確な時間に同じジョブを実行する必要があります。 、時間節約などのために監視することはできません。)
  • サーバーでエラーが発生した場合、それは完全に誤解を招く可能性があります。フォーラムでそのことを確認してください。頭の中で何も思い出すことができません
  • プッシュ通知は定期的に 20 ～ 30 分ほど遅れます

任意の例: データベースからランダムなアイテムを取得したい場合、アプリはそれを提供するジョブを呼び出し (1 つの API 呼び出し)、ジョブはデータベースにクエリを実行しますが、最初に 2 つの呼び出しを行う必要があります。アイテムの数を取得し (1 つの API 呼び出し)、次にランダムなアイテムを取得するための 2 つ目の呼び出し (1 つの API 呼び出し)。これは、その機能に対する 3 つの API 呼び出しであり、1 秒あたり 60 のリクエストで、20 人のユーザーがその呼び出しを行うことができます。リクエストの制限に達してプラットフォームが混乱するまでの特定の時間、アプリの画面などを閲覧している他のユーザーを含めた後、これがどこにつながるかがわかります...

それが良いものであるとすれば、それを購入したFacebookは、アプリの一部でさえそれを使用していることに言及していませんか? 私は3つのことを提案します
:スケーラブルなプラットフォームであり、完全にカスタマイズしたくない場合は、テスト済みで信頼性の高い Amazon Cloud サービスまたは同様のものを使用します - 3 つ目 - サーバーサイドの経験がある場合は、プラットフォームから離れてください。プロジェクトのバックエンド開発者、それは安くなり、最終的には実用的なソリューションを手に入れるでしょう

于 2015-02-07T22:02:30.263 に答える
11

私は parse.com を 1 日かけて調べました。ここに、私が見つけたものに基づく現在の意見を示します (SDK を使用した開発の経験はまだ非常に短いことを覚えておいてください)。

Parse.com には明らかに非常に魅力的なポジティブな点がいくつかあるため、調べてみましたが、議論のために、素晴らしいポジティブな点はすべて Web サイトにリストされているため、批判的であることに集中します。(このような大きな問題を解決しようとしてくれた parse.com さん、よくやった!)...

  • 証言では、Hipmunk は私が言う最大の名前です。SDK のデータ部分を使用するアプリとしてリストされています。Hipmunk の開発者に連絡しないと、確かなことはわかりませんが、彼らがすべてのデータを parse.com クラウドに保存するとは想像できません。
  • リストされているほとんどのアプリを試して閲覧した後。サーバーのバックエンドに大きく依存していることは特に目立たないので、これらに基づいてparse.comを使用してスケーラビリティが解決されたかどうかを判断することは不可能です.
  • Web サイトには 40,000 のアプリがあり、数え切れないほどあります。アプリギャラリーに基づいて、この数字はユーザーベースのアプリの量に基づいており、アプリストアで実際に稼働しているアプリではないと感じています (しかしわかりません)。それだけ多くのアプリが parse.com を使用していれば、アプリ ギャラリーにははるかに多くの有名人が登場するでしょう。

Parse.com は非常に新しいコンセプトであり、最も近いライバルとも大きく異なります。そのため、スケーラビリティと安定性 (およびその他すべて) に関する具体的な証拠がなければ、プロジェクトの開発者がプロ​​ジェクトにコミットすることを検討することは非常に困難です。

于 2012-10-30T21:28:14.907 に答える
11

同様の質問に対する自分の回答をテストしましたが、非常に高速である可能性があります。ただし、得られる結果は、実装の詳細に依存する場合があります...

Parse/REST 呼び出しを行うネイティブ HTTP スタックを使用して Android SDK と Android を比較するテスト...

テストの詳細:

テスト環境 - 高速 WIFI 接続を介した 10 か月前の携帯電話での最新の Android バージョン。

(平均ファイルサイズが 80K の写真を 63 枚アップロードします)

Android SDK を使用したテスト 1 RESULT=パフォーマンスの低下

android RESULT=VERT FAST を介したネイティブ REST 呼び出しを使用したテスト 2

--編集--ここに興味があるので....

http thruput 、parse SDK(android) およびパフォーマンスに関して、parse.com が parse.android SDK に android asyncTask() を実装する方法でパフォーマンスを最適化していない可能性がありますか? なんと8分もかかった作業。on parse.sdk は、最適化された REST 、DIY フレームワーク (実装の詳細についてはリンクを参照) で 3 秒で実行できますが、本当にわかりません。これらの比較テストが実行されてから parse が SDK の実装を修正していない場合、デフォルトの SDK の asnycTask がネットワーク上の実際のワークロードに近づくことを望んでいない可能性があります。

于 2012-11-09T16:12:48.267 に答える
8

Parse (および同様の SaaS) の大きな魅力は、バックエンドの開発コストを何万も節約できることです。多くの場合、バックエンドが Web アプリの最も高価な側面であることを考えると、その頭痛は突然だ.

Parse とほとんどの (すべての) SaaS の問題は、リージョン、電力、メモリ、帯域幅、スケーラビリティ、しきい値、アラート、およびさまざまなアクションが制御できないことです。

Shopifyと同じです。これは、製品、注文、在庫、および美学を包括的に制御できる優れた SaaS ですが、マシンを制御することはできません。したがって、今日の SaaS は、godaddy と大差ありません。彼らは常に、お金を稼ぐために自分のマシンを過剰に販売したり、最大限に使いすぎたりします。お尻を蹴るパフォーマンスを本当に気にするなら、あなたは立ち往生しています。そのレベルのサービスを購入することさえできません。

少なくとも AWS コンソールと同じくらい強力で包括的なものが欲しいです。ほとんどの技術者は、Heroku と Parse の両方が AWS でホストされていることを知っており、受け入れています。誰も気にしない。したがって、追加されたサービスに対してより多くの料金を請求しますが、サイトとアプリ、およびユーザーエクスペリエンスを魅力的にする重要な低レベルツールへのアクセスを拒否しないでください. それらのパースの従業員にヒントを与えてください。

とにかく、質問への答えとして：

Parse API は単純な JSON です。そのため、Parse アプリケーションが期待するのと同じ JSON 形式でデータを送り出すことができます。

彼らの PFObject (iOS) を利用することさえできるかもしれません。ある時点で、すべての高レベル API が共通の HTTP 要求/応答に送られます。REST の汎用性の良いところは、ありふれたものであることです。http、url、文字列、utf などです。ここにはファンキーなオーブはありません。

于 2013-07-30T20:21:45.083 に答える
5

解析は、特にユーザー管理に関するヘルパー関数/機能から始めるのに最適です。しかし、私は問題に遭遇し始めました..

長い実行/ping時間、サブクエリを含む1000オブジェクト制限、ヨーロッパにデータセンターなし（私の知る限り）

パフォーマンスと安定性の問題を解決できれば、それは素晴らしいプラットフォームだったでしょう. どういうわけかそれで開発したことを後悔していますが、5000行以上のコードを入れたので、それを使い続けるつもりです.

DEV アプリと PROD アプリの環境を分離し、何らかの監督の後に PROD アプリのみを許可するか、有料の顧客のみで別の環境を作成する必要があるのではないでしょうか?

私たちは2014年で、月額20ドルのサーバーは、最適化されていないWebサイト（ホームページで60のキャッシュされていないデータベースクエリ）を処理でき、月に100万回の訪問があります。これはParseにとってそれほど難しいことではありません!

于 2014-10-14T11:36:49.000 に答える
2

特に iOS/Android 開発者が自分で DB/API バックエンドを構築する方法を知らない場合は、アプリのプロトタイプを作成しても問題ありません。

以下よりも複雑なクエリを必要とするロジックを持つアプリケーションの開発に関しては、まったく問題ありません。

SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100;

関連するクエリと内部結合は、Parse には存在しません。そして、必要に応じて 320 000 レコードを更新/削除してください (これは私が現在取り組んでいる数です)。

本当に便利なのは、SDK を介してユーザーを処理することだけです。Django と DRF/Tastypie を使用して iOS/Android アプリを介してユーザーを処理/作成する方法に関する優れたドキュメントやチュートリアルを見つけることができれば、社内で開発されているすべてのものをそれを使用するように即座に変換しています。

于 2015-03-12T08:12:43.400 に答える