Parseはどれくらいスケーラブルですか？
Parse.comのサービスをバックエンドに使用することを検討してきましたが、そのスケーラビリティについては懐疑的です。
本当に数千の同時ユーザーを処理できますか？そうでない場合、彼らの良い方法はそこから移行していますか？
私は質問が古いかもしれないことを知っていますが、解析を検討しているかもしれない他の人々のために私の2セントを提供したかったです...
最も単純なシナリオでは、解析がうまく機能する場合があります。より複雑なクエリにスケールアップする必要があるとすぐに、私は頭痛だけを発見しました。
クエリは1000レコードに制限されています。最初は、サブクエリの処理を開始し、警告やエラーなしでサブクエリがレコードをカットするため、奇妙なデータが返されるまで、これは問題ではないと考えるかもしれません。 （参考までに、1000までの制限を指定しない限り、デフォルトは100レコードであるため、注意を怠ると問題はさらに悪化します）。
奇妙な理由により、1分でcountクエリを発行できる回数には制限があります。 （そして、この制限は本当に低いようです）。この制限に達しないようにコードを調整しようと準備してください。そうしないと、エラーがスローされます。
バックグラウンドジョブは確実に実行されません。 5分ごとに実行するようにバックグラウンドジョブを設定しましたが、ジョブが開始されるまでに20分以上かかることがあります。
たくさんのタイムアウト。これは私に最も胸焼けを与えるものです。 A.処理に時間がかかるクラウド機能がある場合、約6〜7秒で完了します。そうしないと、切断されます。
B。システムに一般的な不安定性があると感じています。定期的に、タイムアウトがより頻繁に発生する（そしてすぐに返されるはずの比較的単純な関数で）約1時間程度続くと思われる問題に遭遇します。
Parseを使用するという決定を完全に後悔し、資金を得るのに十分な時間アプリを存続させるためにできる限りのことを行っているので、プラットフォームから移動できます。誰かが解析するためのより良い代替手段を持っている場合、私はすべて耳です。
[編集：チームで驚くほどの3年を過ごした後、私は先に進むことに決め、ParseまたはFacebookの従業員ではなくなりました。チームは素晴らしい手であり、驚くべきことをしました。バックエンド全体が書き直され、パフォーマンスと信頼性が劇的に向上しました。ロードマップは驚くべきものであり、チームから素晴らしいものが来ることを期待しています。私が出発した時点で、Parseは60万を超えるアプリケーションに対応し、毎日膨大な数のリクエストを処理していました。各Parse Pushが一意の人に送信されると、1日で世界で4番目に大きい国を形成できます。今後のParseのサポートについては、parse.comタグで質問を投稿するか、parse-developers Googleグループに投稿してください。]
完全な開示：私は解析エンジニアです。
解析では、ユーザーはもちろん、数千のappsを既にホストしています。 3月下旬にベータ版を終了すると、 発表済み Parseで実行されている10,000を超えるアプリケーションが毎月40％の成長率で実行されています。 Parseには、ビッグデータと大量のトラフィックで長年の経験を持つ世界クラスのチームが配置されています。
両手を広げてトラフィックを歓迎します。 Band of the Day や Hipmunk のような素晴らしいチームの一員になります。私たちはサービスに非常に自信を持っているので、私たちは ワンクリックエクスポート システムを構築しましたので、あなたのような人はリスクのない解析を試すことができます。 Parseがパフォーマンスの期待を満たしていないと思われる場合は、すべてのデータをそのままにして喜んでお送りします。
アプリのバックエンドとして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ユーザーでテストしているアプリの場合です！
これは、完全に任意の瞬間に再現することが不可能な、私たちが常に取り戻す典型的なものです。いくつかのクエリといくつかの挿入を行うクラウドコード関数の呼び出し：
{"code":124,"message":"Request timed out"}
10分後に同じことを試してみると、1秒以内に実行されます。 20分後にもう一度試してください。実行には30秒かかります。
トランザクション性がないため、1つのクラウドコード関数にインスタンス3つのオブジェクトを格納する場合、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のエラー（1か月に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)
それは素晴らしいことではありませんか？
バックエンドでロジックをほとんどまたはまったく持たない小さな/シンプルなアプリ（または使い捨てのプロトタイプ）を作成している場合は、それを選択しますが、より大きく/スケーラブルなものを避けるためには、それを回避するのが最善であると言えます。ユーザー管理、プッシュ通知、抽象化されたストレージなど、すべてが良いように思えますが、結局のところ、トラブルに見合う価値はありません。つまり、私はParseでアプリのバックエンドを開発していましたが、クライアントはとても魅力的で有望でした（強力なマーケティングだと思います）、Facebookで購入されましたが、数週間で主要な問題/制限が生産されましたプラットフォームの登場が始まりました。シンプルなアプリであるべきものが、開発とスケーリングの悪夢であることが判明しました。
プロジェクトの結果/結論：-比較的シンプルなアプリの時間枠を破りました-2〜3か月続くはずでしたが、ほぼ1年続きましたが、カスタムスタックを使用した場合はまだ安定していません。 d確かに時間枠内で行われ、カスタムノードスタックを使用して5〜10日で同様のデモプロジェクトを作成しました-クライアントの信頼を失い、カスタムスタックを使用する別のチームでアプリを作り直しています-時間枠を破ってそれを機能させようとしたために大量の現金を失いました-残業が多すぎて私の健康に反映し始めました-すべてを約束するプラットフォーム/ソリューションを使用せず、常にカスタムで/試したスタック
1つは、サーバーのダウンタイムやランダムエラーなど、プラットフォームの安定性の問題と絶え間ない障害でしたが、それらはすべて整理されています（2014年の初めの中頃）が、次の問題が残っています。
- 少なくとも現時点では、コードをデバッグすることはできません（追加のノードサーバーといくつかのあいまいなlibで動作させる方法があります）
- 制限はとんでもない、毎秒50〜60 APIリクエスト（またはサブスクリプションに応じてそれ以上）を実行できるスケーラブルなプラットフォームです。これは、ひずみテストを開始し、コードにヒットするまで聞こえるほど低くはありません。常に失敗します
- API呼び出しは次のように測定されます。サーバー関数の呼び出し（ジョブの解析）-1回の呼び出し、データベースのクエリ-1回の呼び出し、別のクエリ（より複雑な高度な/複雑なクエリシステムがないため）すぐにわかるデータベーススキーマ）-1回の呼び出し、1000を超えるクエリを取得する必要がある場合は、何を推測するか-クエリの再実行など、カウントのクエリ（別のクエリとして実行する必要があります）信頼できない（数千エントリの近似値を返す傾向がある）
- 〜1000以上の単純なオブジェクトの作成/保存はプラットフォーム/データベースに負担をかけ、1000以上のオブジェクトを削除します。これは通常のデータベースではとてつもなく高速ですが、Parseでは5〜10分かかります（チェックした場合より密接に、バッチごとに20個のオブジェクトを削除します）
- ほとんどのnpmパッケージを使用する方法はありません（ソースを直接インクルードして純粋なJSパッケージのみ）
- parseフォーラムにアクセスすると、プラットフォームの機能不足のためにParseチームを絶えずダウンボット/ローストし、ランダムエントリや同様のものを取得するような任意のロジック実装のためにフープをジャンプする必要があるユーザーが表示されます
- 彼らはStripeの統合をサポートしていますが、Paypalまたは他の支払いサービスを使用したい場合（Paypalを使用することに決めました。Paypalを使用することを決めました。別のサーバーを使用してそれを引き出します
- ユーザーを同期し、同時実行の問題を処理する簡単な方法はありません。ハックと、使用しないか、どこにも使用しないことを認めない面白いロジックを使用する必要があります。
- 100人以上、1000人以上の同時ユーザーはもちろん、幸運を祈ります
- テーブル内のエントリの数を知りたいときは、カウントクエリの呼び出しの制限に達することができますが、それは面白く、文書化されておらず、まったくばかげており、最終的にはおおよその数を返します
- モジュール性はプラットフォームにとって異質であり、ジョブから呼び出す関数は数秒（7秒だと思います）を超えて持続することはできず、クエリ時間を考慮すると、より複雑なクエリで頻繁に発生します。いくつかの複雑なロジック
- Cronジョブのようなものを使用できますが、15分以上持続することはできません（複数のクエリが非常に短いなど、プラットフォームのパフォーマンスが低いため）。サブスクリプション料金、および非常に限られた/貧弱なスケジューリングシステムが用意されている（たとえば、コードから編集できない、非常に限られているため、ハッキングを使用して同じジョブを1日の間に2回正確に実行する必要がある、時間の節約などを監視することはできません）
- サーバーでエラーが発生した場合、それは完全に誤解を招く可能性があります。フォーラムでそのことを確認してください。
- プッシュ通知は通常20〜30分遅れています
任意の例：データベースからランダムなアイテムを取得したい場合、アプリはそれを提供するジョブ（1つのAPI呼び出し）を呼び出し、ジョブはデータベースを照会しますが、最初に2つの呼び出しを行う必要がありますアイテムのカウント（1 API呼び出し）を取得してから、ランダムアイテム（1 API呼び出し）を取得するために2番目のカウントを取得します。これは、その機能の3 API呼び出しであり、1秒あたり60リクエストで、20ユーザーがその呼び出しを行うことができますリクエストの制限に達する前の一定の時間とプラットフォームが混乱する前に、アプリの画面などを閲覧している他のユーザーを含めた後、これがどこにつながるのかがわかります...
もしそれが良ければ、Facebookがすべての言及を買って、彼らのアプリのいくつかでさえそれを使用しないでしょうか？私は3つのことをお勧めします：-最初に-Parseの人の言うことを聞かないでください、それは彼のプラットフォームなので、彼はそれを宣伝しなければなりません。
-2番目-真剣でスケーラブルなプラットフォームが必要で、完全にカスタム化したくない場合は、Amazon Cloudサービスまたはテスト済みで信頼性のある同様のものに進みます-3番目-プラットフォームがある場合はプラットフォームに近づかないサーバー側の経験。プロジェクトのバックエンド開発者を雇わなければ、より安くなり、最終的には実用的なソリューションが得られます。
私はparse.comを調べるのに1日を費やしましたが、これは私が見つけたものに基づいた現在の意見です（まだSDKでの開発経験は非常に短いことに留意してください）。
Parse.comには明らかに非常に魅力的なポジティブなものがあるので、私はそれを検討していることに気付きましたが、議論のために、すばらしいポジティブなものはすべてウェブサイトにリストされているので、批判的に集中します。 （このような大きな問題を解決しようとしてparse.comをよくやった！）...
- 証言では、Hipmunkは私が言う最大の名前です。 SDKのデータ部分を使用するアプリとしてリストされています。 Hipmunkの開発者にアプローチしなければ、確実に知ることはできませんが、すべてのデータをparse.comクラウドに保存することは想像できません。
- リストされているアプリのほとんどを試してみた後。サーバーのバックエンドに大きく依存しているとは本当に目立っていないため、これらに基づいてparse.comを使用してスケーラビリティが解決されたかどうかを知ることは不可能です。
- Webサイトには、40,000個のアプリとカウントが記載されています。アプリギャラリーに基づくと、この数値はユーザーベースのアプリの量に基づいており、アプリストアの実際の運用環境のアプリには基づいていないように感じます（わかりません）。多くのアプリがparse.comを使用している場合、アプリギャラリーにははるかに多くのビッグネームがあります。
Parse.comは非常に新しいコンセプトであり、最も近いライバルとはまったく異なります。したがって、スケーラブルで安定していること（およびその他のすべて）の具体的な証拠がなければ、プロジェクトの開発者が、あまりにも多くのリスクがあるため、コミットすることを検討するのは非常に困難です。
同様の question に対する自分の答えのテストを実行しましたが、非常に高速です。ただし、結果は実装の詳細に依存する場合があります...
テストの比較Android SDKとAndroid Parse/REST呼び出しを行うネイティブHTTPスタックを使用して...
テストの詳細：
テスト環境-最新のAndroid高速WIFI接続での10か月前の携帯電話のバージョン。
（avg filesize = 80Kの63枚の写真をアップロードします）
Android SDK RESULT =パフォーマンスの低下を使用してテスト1
ネイティブを使用したテスト2 REST上の呼び出しAndroid RESULT = VERT FAST
-編集-ここに興味があるので....
Http thruput、parse SDK（Android）およびパフォーマンスに関して、parse.comがparse.Android SDKでAndroid asyncTask（）を実装する方法でパフォーマンスを最適化していない可能性がありますか？最適化されたREST、DIYフレームワーク（実装の詳細についてはリンクを参照）で、parse.sdkで8分を必要とする作業が3秒でどのように行われるか、私は本当に知りません。これらの比較テストが実行されて以来、parseはSDKの実装を修正していません。おそらく、デフォルトのSDK asnycTaskがネットワーク上の実際のワークロードに近づくようなことをしたくないでしょう。
Parse（および同様のSaaS）の大きな魅力は、バックエンドの開発コストを数万個節約できることです。多くの場合、バックエンドはWebアプリの最も高価な側面です。その頭痛は突然poofです。
Parseおよびほとんどの（すべての）SaaSの問題は、地域、電力、メモリ、帯域幅、スケーラビリティ、しきい値、アラート、およびさまざまなアクションが制御できないことです。
Shopifyと同じです。製品、注文、在庫、美観を包括的に制御できる優れたサースですが、機械を制御することはできません。ですから、今日のSaaSはgodaddyとは大きく異なります。彼らは常にお金を稼ぐために機械を売ったり、使い切ったりします。そのレベルのサービスを購入することさえできません。
AT AWSコンソールと同じくらい強力かつ包括的です。ほとんどの技術者は、HerokuとParseの両方がAWSでホストされていることを知っています。だれが気にします。ただし、サイトとアプリを作成し、ユーザーエクスペリエンスを向上させる重要な低レベルツールへのアクセスを拒否しないでください。
とにかく、質問に対する答えとして：
Parse APIは単純なJSONです。そのため、Parseアプリケーションが期待するのと同じJSON形式でデータを出力できます。
PFObject（iOS）を利用できる場合もあります。ある時点で、その高レベルAPIはすべて、共通のHTTP要求/応答に送られます。 RESTの一般性の良いところは、一般的なことです。 http、url、strings、utfなど。ここにはファンキーなオーブはありません。
解析は、特にユーザー管理に関するヘルパー機能/機能から始めるのに最適です。しかし、私は問題に遭遇し始めました..
長い実行/ ping時間、サブクエリを含む1000オブジェクトの制限、ヨーロッパにデータセンターはありません（私の知る限り）
パフォーマンスと安定性の問題を分類できれば、神聖なプラットフォームになっていたでしょう。なんとかして開発を後悔していますが、5000行以上のコードを入れたので、これに固執します。
たぶん、DEVアプリとPRODアプリの環境を分けて、何らかの監視の後にのみPRODアプリを許可するのでしょうか、それとも有料の顧客だけで別の環境を作成するのでしょうか？
2014年に、月20ドルのサーバーが最適化されていないWebサイト（ホームページで60のキャッシュされていないdbクエリ）を月100万回の訪問で処理できるようになりました。
特にiOS/Android開発者がDB/APIバックエンドを自分で構築する方法を知らない場合、アプリのプロトタイプを作成しても問題ありません。
次よりも複雑なクエリを必要とするロジックを備えたアプリケーションの開発に関しては、まったく問題ありません。
SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100;
Parseには、関連するクエリと内部結合は存在しません。また、必要に応じて320 000レコードを更新/削除してください（これが現在作業中の数値です）。
本当に役立つのは、SDKを介してユーザーを処理することだけです。 DjangoとDRF/Tastypieを使用してiOS/Androidアプリを介してユーザーを処理/作成するための優れたドキュメントまたはチュートリアルを見つけることができた場合、当社で開発中のすべてを即座に変換していますそれを使用します。