Parse的可扩展性如何？

时间：2012-07-01 16:28:50

标签： iphone parsing scalability parse-platform

我一直在考虑将Parse.com的服务用于我的后端，但我对它的可扩展性持怀疑态度。

真的可以处理几千个并发用户吗？如果没有，他们有什么好的方式从它过渡？

9 个答案:

答案 0 :(得分：75)

我知道这个问题可能已经过时了，但我想为那些可能正在考虑解析的人提供2美分......

在最简单的场景下，解析可能效果很好。一旦你需要扩展到更复杂的查询，我个人发现只有头痛。

  1. 查询限制为1000条记录。最初，您可能认为这不是问题，直到您开始处理子查询，并且实现了奇怪的数据，因为子查询会在没有警告或错误的情况下关闭记录。 （仅供参考，默认为100条记录，除非您指定的限制最多为1000条，因此如果您不注意，问题会更严重。）

  2. 由于某些奇怪的原因，您可以在一分钟内发出计数查询的次数有限制。 （这个限制似乎非常低）。准备好尝试限制你的代码，这样你就不会达到这个限制，否则会引发错误。

  3. 后台作业无法可靠运行。我有一个后台工作设置每5分钟运行一次，有时需要20分钟才能开始工作。

  4. 很多超时。这是给我最多胃灼热的一个。  答：如果你有一个需要一段时间才能处理的云功能，你有大约6到7秒的时间来完成它，否则它会让你失望。
     B.我觉得系统普遍存在不稳定性。我会定期遇到一些问题，这些问题似乎持续了大约一个小时左右，其中超时发生的频率更高（而且相对简单的功能应立即返回）。

    5. 我完全后悔自己决定使用解析，我正竭尽所能让应用程序保持足够长的时间以便我们获得资金，这样我们就可以离开平台了。如果有人有任何更好的解析方法，我会全力以赴。

答案 1 :(得分：35)

[编辑：在与团队共度三年之后，我决定继续前进，不再是Parse或Facebook的员工。团队掌握得很好，做了很棒的事情。整个后端已被重写，以显着提高性能和可靠性。路线图很棒，我希望团队能够做出很棒的贡献。在我离开时，Parse为超过600,000个应用程序提供了支持，并且每天提供令人难以置信的请求数量。如果将每个Parse推送到一个独特的人，他们可以在一天内成为世界第四大国家。有关Parse的未来帮助，请在此处使用parse.com标记发布问题或发布到解析开发人员Google小组。]

完全披露：我是一名解析工程师。

Parse已经托管了数千个应用，更不用说用户了。当我们在3月下旬退出测试版时，我们announced在Parse上运行的10,000多个应用程序的月增长率为40％。 Parse拥有一支世界级的团队，其中许多人拥有多年的大数据和大量流量经验。

我们张开双臂欢迎您的交通;您将与Band of the Day和Hipmunk等优秀团队合作。我们对我们的服务非常有信心，我们建立了One Click Export系统，所以像你这样的人可以尝试Parse风险。如果您觉得Parse不符合您的性能期望，我们很乐意将您的所有数据保存完好。

答案 2 :(得分：23)

我们选择Parse作为我们应用的后端。 结论：DON＆＃39; T。

稳定性是一场灾难，性能也是灾难，支持也是如此（可能因为它们无法帮助您，因为所有问题都是不可重现的。）

运行即使是最简单的函数也可能导致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分钟后尝试相同，并在不到一秒的时间内运行。 20分钟后再试一次，执行需要30秒。

因为没有事务性，所以在1个云代码函数中存储例如3个对象时真的很有趣，其中Parse决定在让我们保存3个中的2个之后随机退出函数对象。很高兴保持数据库的一致性。

＆＃34; best＆＃34;我们得到的地方。请注意，这是从云代码功能返回的实际数据：

 {"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人开始在这个后端使用我的应用程序会发生什么。

编辑：

现在我在进行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)

难道不是很好吗？

答案 3 :(得分：20)

如果您正在编写一个小/简单的应用程序（或一次性原型），后端几乎没有逻辑，那就去做吧，但对于更大/可扩展的东西，最好避免它，我可以从第一手经验说出来。这一切听起来不错，包括用户管理，推送通知，抽象存储以及什么不是，但最终它不值得麻烦。也就是我正在开发Parse应用程序的后端，客户非常喜欢它，因为它听起来很酷且很有前景（我猜的是强大的营销），被Facebook收购但是什么不是，但是几个星期的生产主要问题/限制与平台开始出现，应该是一个简单的应用程序，结果证明是一个开发和扩展的噩梦。

项目的结果/结论： - 打破了一个相对简单的应用程序的时间窗口 - 它应该持续2-3个月，它持续了近一年但仍然不稳定/可靠，如果我们使用自定义堆栈它可以在里面完成确定的时间窗口我在5-10天内使用自定义节点堆栈制作了类似的演示项目 - 失去了客户的信任，他们现在正在与另一个使用自定义堆栈的团队重新构建应用程序 - 为打破时间窗口并试图使其工作而丢失了大量现金 - 做了这么多加班的原因，它开始反映我的健康状况 - 永远不要使用一些承诺拥有一切的平台/解决方案，总是使用自定义/尝试过的堆栈

首先是稳定性问题以及服务器停机和随机错误等平台的不断失败，但它们已经整理好了（即2014年中期），但仍存在以下问题：

  • 你不能调试你的代码，至少目前是这样的（有很多方法可以让它与其他节点服务器和一些模糊的lib一起使用）
  • 限制是荒谬的，一个可扩展的平台，每秒可以执行50-60个API请求（或者更多，具体取决于您的订阅），在您开始进行应变测试之前，它的声音并不低，当你点击它，你的代码将不断失败
  • API调用是这样测量的：调用服务器函数（解析作业） - 1次调用，查询数据库 - 1次调用，另一次查询（因为他们没有一些高级/复杂的查询系统，如果你有一个更复杂的数据库模式，你很快就会意识到我的意思） - 1个电话，如果你需要超过1000个查询猜测什么 - 再次查询等等，查询计数（你需要这样做）作为一个单独的查询），这是不可靠的（往往会返回几千个条目的近似值）
  • 创建/保存~1000 +简单对象是平台/数据库的压力，删除1000个或更多对象，甚至更多，这对于普通数据库来说是快得离谱的，但是在Parse上它往往需要5-10分钟（如果你仔细检查它，每批删除20个对象）
  • 无法使用大多数npm软件包（仅通过直接包含源代码来使用纯JS软件包）
  • 如果你去阅读Parse论坛，你会看到用户为了平台缺乏功能而不断向Parse团队进行downvoting / roasting，并且需要跳过任意逻辑实现的箍，例如获取随机条目和类似东西
  • 他们支持Stripe集成，但是如果你想使用Paypal或其他一些支付服务（我们决定使用Paypal，因为它比Stripe有更优越的国家支持），你无法使其在Parse上工作，因为Paypal集成我不得不使用单独的服务器将其关闭
  • 没有简单的方法来同步用户和处理并发问题，你必须使用黑客和一些你不会使用或承认无处不在的有趣逻辑
  • 想要100+，更不用说1000多个并发用户了，祝你好运
  • 当你想知道表格中的条目数量时，你可以达到调用计数查询的极限，它有趣，没有记录，完全荒谬，最后返回一个近似数字< / LI>
  • 模块化对平台来说是陌生的，你从你的工作中调用的功能可以持续超过几秒钟（我认为是7秒），并且当你考虑查询时间时它会被约束使用更复杂的查询和一些复杂的逻辑来发生很多事情
  • 你可以拥有像Cron这样的工作，但是它们的持续时间不会超过15分钟（由于平台的性能低，例如非常非常短的多个查询），它们仅限于2 -3-4个同时工作取决于您的订阅费用，并且具有非常有限/差的调度系统（例如，您无法从您的代码编辑它，它非常有限所以您必须使用黑客如果在白天的两个确切时间运行相同的工作或类似的东西，它就不能注意节省时间等。）
  • 如果您在服务器上收到错误，可能会产生误导，请在论坛上查看，无法记住任何事情
  • 推送通知定期延迟20-30分钟

一个任意的例子：你想从他们的数据库中获取一个随机项，你的应用程序调用一个提供它的作业（1个API调用），该作业查询数据库，但你必须做2个调用，首先获取项目的计数（1个API调用），然后是第二个获取随机项目（1个API调用），这是针对该功能的3个API调用，每秒60个请求，20个用户可以在达到请求限制之前的某个时间进行该呼叫，并且平台变得混乱，在您包含浏览应用程序屏幕和其他内容的其他用户之后，您会看到这导致... ...

如果有任何优秀的Facebook不会因为某些应用程序使用它而一次性购买它吗？我建议3件事： - 首先 - 不要听Parse家伙，这是他的平台，所以他必须推广它，听听那些一直用它来制作东西的人 - 第二 - 如果您需要一个严肃且可扩展的平台并且不想完全定制，请使用Amazon Cloud服务或类似的经过测试和可靠的类似服务 - 第三 - 如果您有任何服务器方面的经验，请远离平台，如果您不去为该项目雇用后端开发人员，那么它会更便宜并且您将获得一个有效的解决方案端

答案 4 :(得分：11)

我花了一天的时间研究parse.com，这是我目前基于我发现的事情的意见（请记住，我对使用SDK进行开发只有非常简短的经验）..

Parse.com显然有一些非常有吸引力的积极因素，这就是为什么我发现自己正在调查它，但为了辩论，我将集中精力批评，因为伟大的积极因素都列在他们的网站上。 （为了解决这么大的问题，parse.com做得很好！）......

  • 在推荐书中，Hipmunk是我所说的最大的名字。它被列为使用SDK数据部分的应用程序。在没有接近Hipmunk开发人员的情况下，我无法确定，但我无法想象他们将所有数据存储在parse.com云中。
  • 尝试浏览列出的大多数应用后。没有人真正脱颖而出，因为它非常依赖于服务器后端，所以我发现无法根据这些内容使用parse.com来了解可扩展性是否已经解决。
  • 该网站陈述了40,000个应用程序并计算在内。我觉得（但不知道）基于应用程序库，这个数字基于用户群中的应用程序数量，而不是应用程序商店中的真实实时制作应用程序。如果许多应用程序使用parse.com，那么应用程序库将包含更多大牌。
Parse.com是一个非常新的概念，甚至与其最接近的竞争对手也截然不同。因此，如果没有关于可扩展性和稳定性（以及其他所有）的具体证据，那么项目的开发人员很难考虑承诺它，因为存在太多的利害关系。

答案 5 :(得分：11)

我为自己的类似question的答案运行了测试，它可能非常，非常快。但是，您获得的结果可能取决于您的实施细节......

测试将Android SDK与Android进行了比较，使用本机HTTP堆栈进行Parse / REST调用...

测试详情：

测试环境 - 通过快速WIFI连接在10个月大的手机上的最新Android版本。

（上传63张图片，其中avg filesize = 80K）

使用android SDK RESULT =慢性能

测试1

使用原生REST调用通过android RESULT = VERT FAST

进行测试2

- 编辑 - 因为这里有兴趣......

关于http thruput，解析SDK（android）和性能，可能是parse.com在parse.android SDK中实现android asyncTask（）的方式上没有优化性能？如何工作需要8分钟。在parse.sdk上可以在3秒内完成优化的REST，DIY框架（请参阅链接了解有关实现的详细信息），我真的不知道。如果解析没有修复他们的SDK实现，因为这些比较测试运行，那么你可能不希望他们的默认SDK asnycTask东西做任何接近网络上的实际工作负载。

答案 6 :(得分：8)

Parse（和类似的SaaS）的巨大吸引力在于，您可以节省数万个后端开发成本。鉴于后端通常是Web应用程序中最昂贵的方面;头疼的是突然 poof 。

Parse和大多数（所有）SaaS的问题在于您无法控制区域，电源，内存，带宽，可伸缩性，阈值，警报和各种操作。

与Shopify相同。这是一个伟大的萨斯，可以全面控制产品，订单，库存和美学 - 但对机器无控制。所以，今天的SaaS并不比godaddy有很多不同。为了赚钱，他们总是夸大或超出他们的机器;如果你真的关心屁股踢性能你就会陷入困境。你甚至不能购买这种服务水平。

我想要的东西至少与AWS控制台一样强大和全面。大多数技术人员都知道并接受Heroku和Parse都在AWS上托管。谁在乎。因此，为增加的服务收取更多费用，但不要拒绝访问那些使网站和应用程序以及用户体验zing的关键低级工具。提示那些Parse员工。

无论如何，回答这个问题：

Parse API是简单的JSON。因此，您可以使用与Parse应用程序所期望的相同JSON格式抽出数据。

您甚至可以使用他们的PFObject（iOS）。在某些时候，所有高级API都会转到常见的HTTP请求/响应。关于REST的一般性的好处意味着普通的货架;像http，url，字符串和utf这样的东西。这里没有时髦的Orb。

答案 7 :(得分：5)

Parse非常适合从特别是有关用户管理的辅助功能/功能开始。但我开始遇到问题..

执行/ ping时间长，1000个对象限制包含子查询，欧洲没有数据中心（据我所知）

如果能够对性能和稳定性问题进行排序，那将是一个神圣的平台。我不知道后悔用它开发，但我放了5000多行代码，所以我会坚持下去。

也许他们应该将他们的DEV应用程序和PROD应用程序环境分开，只允许在某种监督下使用PROD应用程序，或者只为付费客户创建不同的环境？

我们在2014年，每月20美元的服务器可以处理未经优化的网站（主页上有60个未缓存的数据库查询），每月访问量达100万次，这对Parse来说应该不会那么难！

答案 8 :(得分：2)

可以对应用程序进行原型设计，特别是如果iOS / Android开发人员不知道如何自己构建DB / API后端。

当开发一个需要比以下查询更复杂的逻辑的应用程序时，它根本不行; 

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

Parse上不存在相关查询和内部联接。如果你需要，那么祝你好运更新/删除320 000条记录（这就是我现在正在使用的数字）。

唯一真正有用的是通过SDK处理用户。如果我能找到一个好的文档甚至教程如何使用Django和DRF / Tastypie通过iOS / Android应用程序处理/创建用户，我立即转换所有内容正在我们公司开发使用它。

相关问题
最新问题