如何扩展是parsing？
我一直在考虑为我的后端使用Parse.com的服务，但是我对它的可伸缩性持怀疑态度。
它可以处理几千个同时在线的用户吗？ 如果不是的话，他们有什么好的办法可以过渡呢？
我知道这个问题可能很老，但是想给我的2美分给那些可能正在考虑parsing的人。
在最简单的情况下，parsing可能运作良好。 只要你需要扩大到更复杂的查询，我个人发现什么，但头痛。
-
查询限制为1000条logging。 最初，你可能会认为这不是一个问题，直到你开始处理子查询，并实现奇怪的数据返回，因为子查询剪切logging没有警告或错误。 （仅供参考，默认值为100条logging，除非您指定限制为1000，所以如果您不注意，问题会更加严重）。
-
出于一些奇怪的原因，您可以在一分钟内发出计数查询的次数是有限制的。 （这个限制看起来非常低）。 准备尝试扼制你的代码，这样你就不会遇到这个限制，否则就会抛出错误。
-
后台作业无法可靠运行。 我有一个背景工作每5分钟运行一次，有些时间需要20多分钟才能完成。
-
很多超时。 这是最让我感到沮丧的。 答：如果您的云端function需要一段时间才能处理，您需要等待大约6或7秒才能完成，否则会导致您无法使用。
B.我感觉到这个系统总体上是不稳定的。 我经常遇到这样的问题，这些问题似乎持续了大约一个小时左右，因为超时发生得比较频繁（而且function比较简单，应该立即返回）。
我对我使用parsing的决定感到非常遗憾，我正在尽我所能使应用程序长久存活，以便我们获得资金，所以我们可以离开平台。 如果任何人有更好的select来parsing，我是全部耳朵。
[编辑：在与团队合作三年后，我决定继续前进，不再是Parse或Facebook员工。 这支队伍掌握着优秀的成绩。 整个后端已被重写，以显着提高性能和可靠性。 路线图是惊人的，我希望伟大的事情来自团队。 在我离开的时候，Parse支持超过60万个应用程序，每天的请求数量惊人。 如果把每个parsing推送给一个独特的人，他们就能在一天之内形成世界第四大国。 对于将来Parse的帮助，请将问题在这里发送到parse.com标签，或发布给parsing开发者Google小组。
充分披露：我是一名parsing工程师。
parsing已经拥有数千个应用程序 ，更不用说用户了。 当我们在3月底退出testing版时，我们宣布在Parse上运行的应用程序超过10,000个，月环比增长率为40％。 Parse拥有世界级的团队，其中许多人拥有大数据和高stream量的经验。
我们欢迎您的交通张开双臂; 你将会拥有像“每日新闻”和“ Hipmunk”这样的优秀团队。 我们对我们的服务非常有信心，所以我们build立了一键式导出系统，像您这样的人可以免费parsing风险。 如果您觉得Parse不符合您的性能预期，我们将很乐意将您的所有数据完整地发送给您。
我们select了Parse作为我们的应用程序的后端。 结论：不。
稳定是一场灾难，性能也是一场灾难，支持（也许是因为它们不能真正帮助你，因为所有问题都是不可重现的）。
运行即使是最简单的函数也会导致Parse内出现随机超时（我正在谈论简单的PFUserlogin调用）：
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) 我们每天都会遇到超时，而且这是我们正在testing的应用程序，最多10个用户！
这是我们在任何时候都会回来的典型的东西，完全随心所欲，不可能重现。 调用云代码函数，执行几个查询和几个插入：
{"code":124,"message":"Request timed out"}
10分钟后再试一次，运行时间不到一秒钟。 20分钟后再试，30秒后执行。
因为没有事务性，所以在一个Cloud Code函数中存储实例3个对象时真的很有趣，Parse决定在保存3个对象中的2个之后随机地从函数中抽出。 太好了，保持你的数据库一致。
这些“最好的”我们得到了。 请注意，这是Cloud Codefunction返回的实际数据：
{"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个错误（我在一个月里遇到过两次错误）之外，其他的都是每天都看到的。
所以是的，开始很容易，但是你必须考虑到你正在一个不稳定的平台上工作，所以要确保你的重试和指数退避系统正常运行，因为你需要这个！
最让我担心的是，我不知道一旦有20,000人在这个后端开始使用我的应用会发生什么。
编辑：
现在我做PFUserlogin时有这个：
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)
这不是很好吗？
如果你正在编写一个小的/简单的应用程序（或一次性原型），而后端逻辑很less或没有逻辑，那就去做吧，但是对于更大/可扩展的东西，最好避免它，我可以从第一手的经验中说出来。 这一切都听起来不错，用户pipe理，推送通知，抽象存储，但最终不值得麻烦。 也就是说，我正在为Parse上的一个应用程序开发后端，客户非常喜欢它，因为它听起来很酷且很有前途（我猜是强大的营销），被Facebook收购了，什么不是，但几个星期生产主要问题/限制平台开始兴起，应该是一个简单的应用程序竟然是一个噩梦发展和规模。
项目结果/结论： – 打破了一个相对简单的应用程序的时间窗口 – 应该持续2-3个月，持续近一年，仍然不稳定/可靠，如果我们使用定制的堆栈，因为我在5-10天内用一个自定义节点堆栈做了一个类似的演示项目 – 失去了客户端的信任，现在他们正在与另一个将使用定制堆栈的团队重新编写应用程序 – 为了打破时间窗口而努力工作 – 为此付出了太多的加class费，导致它开始反映我的健康状况 – 从来没有使用一些承诺拥有这一切的平台/解决scheme。 /尝试堆栈
首先是服务器停机时间和随机错误等平台的稳定性问题和不断的失败，但是他们已经把所有这些（2014年中期开始）都解决了，但是还存在以下问题：
- 至less在那个时候，你不能debugging你的代码（有办法可以使它与另一个节点服务器和一些模糊的lib一起工作）
- 限制是荒谬的，一个可扩展的平台，可以做每秒50-60 API请求（或更多，取决于您的订阅），这不是低听起来，直到你开始做压力testing，当你打它的代码将不断失败
- API调用的测量是这样的：调用一个服务器函数（parsing工作） – 1个调用，查询数据库 – 1个调用，另一个查询（因为他们没有一些高级/复杂的查询系统，如果你有一个更复杂的数据库模式，你会很快意识到我的意思） – 1调用，如果你需要得到超过1000个查询猜测什么 – 再次查询等，查询计数（你需要做一个单独的查询），这是不可靠的（倾向于返回几千个条目的近似值）
- 创build/保存1000多个简单对象是平台/数据库上的一个负担，删除1000个或更多的对象，甚至更多，这对正常的数据库来说是非常快的，但是parsing它往往需要5-10分钟（如果你检查它更接近每批删除20个对象）
- 没有办法使用大部分的npm包（只有直接包含源代码的纯JS包）
- 如果你去阅读Parse论坛，你会看到用户不断地对Parse团队进行downvoting /烘焙，因为这个平台缺乏function，需要跳过任意的逻辑实现，比如获取随机条目和类似的东西
- 他们支持条纹集成，但如果你想使用贝宝或其他支付服务（我们决定使用贝宝因为它有一个优越的国家对Stripe的支持），你不能让它在Parse上工作，因为我不得不使用一个单独的服务器将其closures
- 没有简单的方法来同步用户和处理并发问题，你必须使用黑客和一些有趣的逻辑，你不会使用或承认永远不会使用
- 想要100+，更不用说1000多个同时在线的用户，祝你好运
- 当你想找出一个表中的条目数时，你可以在调用计数查询的时候达到极限，这很有趣，没有logging，完全荒谬，最后返回一个大概的数字
- 模块化对于平台来说是陌生的，你从工作中调用的function不能超过几秒（我想是7秒），当考虑到查询时间时，它会发生很多更复杂的查询和一些复杂的逻辑
- 你可以拥有像Cron这样的工作，但是他们不能超过15分钟（由于平台的性能低下，比如多个查询非常非常短），他们仅限于2-3-4个同时工作，具体取决于你的订阅费，并有一个非常有限/很差的日程安排系统（例如，你不能从你的代码编辑，它是非常有限的，所以你必须使用黑客在一天中的2个确切时间运行相同的工作或类似的东西，它不能节省时间等）
- 当你在服务器上出现错误时，这可能是完全误导性的，检查论坛，记不起任何东西
- 推送通知通常晚于20-30分钟
一个任意的例子：你想从他们的数据库中获取一个随机项目，你的应用程序调用一个将提供它的作业（1个API调用），作业查询数据库，但是你必须先做2个调用获得项目的数量（1个API调用），然后第二个得到一个随机项目（1个API调用），这是3个API调用的function，每秒60个请求，20个用户可以在在达到请求限制和平台发生故障之前的某个特定时间，在您包括其他用户浏览应用程序屏幕和内容之后，您会看到这会导致…
如果有什么好处的话，那么即使是某些应用程序使用它，Facebook也不会把它每一次都买下来吗？ 我build议3件事情： – 首先 – 不要听Parse的人，这是他的平台，所以他必须推广它，听听那些使用它的人使用它
– 第二 – 如果您需要一个认真的，可扩展的平台，并且不想完全定制，那么去亚马逊云服务或类似的testing和可靠 – 第三 – 如果您有任何服务器端的经验，远离平台那么你不会去为项目雇佣一个后端开发人员，这将会更便宜，最终你会得到一个可行的解决scheme
我已经花了一天的时间来看parse.com，这是我目前的意见，基于我发现的（请记住，我只有非常简短的SDK开发经验）。
Parse.com显然有一些非常有吸引力的积极因素，这就是为什么我发现自己正在寻找它的原因，但为了辩论的目的，我将把精力集中在关键因素上，因为好的积极因素都列在他们的网站上。 （做得很好parse.com试图解决这样一个伟大的问题！）…
- 在证言中，Hipmunk是我想说的最大的名字。 它被列为使用SDK的数据部分的应用程序。 没有接触到Hipmunk开发人员，我无法确定，但我无法想象他们将所有数据存储在parse.com云中。
- 尝试和浏览列出的大部分应用程序后。 没有一个真正脱颖而出，因为它非常依赖于服务器后端，所以我发现不可能知道是否使用基于这些的parse.com解决了可伸缩性问题。
- 该网站提供了40,000个应用程序并计数。 我觉得（但不知道），基于应用程序库，这个数字是基于他们的用户群中的应用程序的数量，而不是应用程序商店中的实际生产应用程序。 如果许多应用程序使用parse.com，那么应用程序库将包含更多的大名称。
Parse.com是一个非常新的概念，与其最接近的竞争对手截然不同。 所以如果没有关于可扩展性和稳定性（以及所有其他方面）的具体证据，那么项目的开发人员就很难考虑承诺，因为涉及的太多了。
我为自己的答案跑了类似的问题的testing ，它可以非常，非常快。 但是，您获得的结果可能取决于您的实施细节…
testing比较Android SDK使用本机HTTP堆栈进行Parse / REST调用…
testing细节：
testing环境 – 在10个月的手机上通过快速WIFI连接的最新Android版本。
（上传63个图片，其中avg filesize = 80K）
testing1使用android SDK RESULT =性能较差
testing2使用本机REST调用通过android RESULT = VERT FAST
– EDIT–因为这里有兴趣….
关于http thruput，parsingSDK（android）和性能，可能是parse.com没有优化性能的方式，他们在parse.android SDK中实现android asyncTask（）？ 如何工作，需要8分钟。 在parse.sdk上可以在3秒内完成一个优化的REST，DIY框架（请参阅链接的实现细节），我真的不知道。 如果parsing还没有解决他们的SDK实现，因为这些比较testing运行，那么你可能不希望他们的默认SDK asnycTask的东西做任何接近networking上的真实工作负载。
关于Parse（以及类似的SaaS）的巨大吸引力在于，您可以节省数以万计的后端开发成本。 鉴于后端通常是Web应用程序中最昂贵的方面， 那头痛一下子噗的一声。
Parse和大多数（所有）SaaS的问题在于您不能控制区域，电源，内存，带宽，可扩展性，阈值，警报和各种操作。
和Shopify一样。 Saas对产品，订单，库存和美学有全面的控制，但是对机器的控制是零。 所以，今天的SaaS与Godaddy不是一回事。 为了赚钱，他们总是把他们的机器卖掉或者卖出去。 如果你真的关心踢屁股的performance，你会被卡住。 你甚至不能买到这样的服务水平。
我希望至less像AWS控制台一样强大和全面。 大多数技术人员知道并接受Heroku和Parse都在AWS上托pipe。 谁在乎。 因此，为附加服务收取更多费用，但不要拒绝访问构成网站和应用程序的重要低级工具以及用户体验。 提示那些parsing员工。
无论如何，回答这个问题：
Parse API是简单的JSON。 因此，您可以使用Parse应用程序所需的相同JSON格式抽取数据。
你甚至可以利用他们的PFObject（iOS）。 在某些时候，所有高级API都会转到一个普通的HTTP请求/响应。 关于REST的一般性的好处是指普通的; 像http，url，string和utf。 这里没有时髦的宝珠。
parsing是非常好的，特别是关于用户pipe理的辅助函数/特性。 但是我开始遇到问题..
很长的执行/ ping时间，1000个对象限制包括子查询，欧洲没有数据中心（就我所知）
如果能够对性能和稳定性问题进行分类，那将是一个神圣的平台。 我以某种方式后悔开发，但我把5000多行代码，所以我要坚持下去。
也许他们应该将他们的DEV应用程序和PROD应用程序环境分开，并且只能在某种监督之后允许PROD应用程序，或者只为付费客户创build不同的环境？
我们是在2014年，20美元/月的服务器可以处理未经优化的网站（在主页上有60个非caching的分贝查询），每月访问量为100万次，这应该不会那么难！
原型开发应用程序是可以的，特别是如果iOS / Android开发人员不知道如何自己构buildDB / API后端。
当开发一个逻辑需要比以下更复杂的查询的应用程序时，
SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100;
相关查询和内部连接在Parse上不存在。 如果你需要更新/删除320 000条logging，那么祝你好运（这是我现在使用的数字）。
唯一有用的是通过SDK处理用户。 如果我可以find一个好的文档，甚至教程如何通过使用Django和DRF / Tastypie的iOS / Android应用程序来处理/创build用户，我马上就会转换我们公司正在开发的所有东西来使用它。
