55

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

它真的可以同时处理几千个用户吗？如果没有，他们有什么好办法摆脱它吗？

4

9 回答 9

76

我知道这个问题可能很老了，但想为可能正在考虑解析的其他人提供我的 2 美分。

在最简单的情况下，解析可能会很好地工作。一旦你需要扩展到更复杂的查询，我个人发现除了头痛什么都没有。

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

  2. 由于某种奇怪的原因，您在一分钟内可以发出计数查询的次数是有限制的。（而且这个限制似乎真的很低）。准备好尝试限制您的代码，以免达到此限制，否则会引发错误。

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

  4. 很多超时。这是最让我心痛的一个。A. 如果您有一个需要一段时间来处理的云功能，您有大约 6 或 7 秒的时间来完成它，否则它会打断您。
    B. 我感觉系统普遍不稳定。定期地，我遇到的问题似乎持续了大约一个小时左右，其中超时发生得更频繁（并且相对简单的函数应该立即返回）。

我对我使用 parse 的决定感到非常遗憾，我正在尽我所能让应用程序保持足够长的时间让我们获得资金，这样我们就可以离开平台。如果有人有更好的解析替代方案，我全神贯注。

于 2014-06-17T00:04:26.963 回答
35

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

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

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

我们张开双臂欢迎您的流量；您将与Band of the Day和Hipmunk等伟大的团队合作。我们对我们的服务非常有信心，因此我们构建了One Click Export系统，因此像您这样的人可以无风险地试用 Parse。如果您觉得 Parse 没有达到您的性能预期，我们很乐意将您的所有数据完好无损地送走。

于 2012-07-02T17:01:08.187 回答
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 分钟后尝试相同的操作，它会在不到一秒的时间内运行。20 分钟后重试，执行需要 30 秒。

因为没有事务性，所以在 1 个 Cloud Code 函数中存储例如 3 个对象时确实很有趣，其中 Parse 决定在保存 3 个对象中的 2 个之后随机退出该函数。很好地保持您的数据库一致。

我们在这些地方得到了“最好的”。请注意，这是从 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 错误（我在一个月内遇到两次）之外，其他所有错误都是每天都会看到的。

所以是的，它很容易上手，但你必须考虑到你在一个不稳定的平台上工作，所以确保你的重试和指数退避系统启动并运行，因为你需要这个！

最让我担心的是，我不知道一旦 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 个月，持续了将近一年，但仍然不稳定/可靠，如果我们使用自定义堆栈它' d 肯定会在时间窗口内完成，因为我在 5-10 天内使用自定义节点堆栈制作了一个类似的演示项目 - 失去了客户的信任，他们现在正在与另一个将使用自定义堆栈的团队重新制作应用程序 -因打破时间窗口并试图使其发挥作用而损失了大量现金 - 加班太多导致它开始反映我的健康状况 - 从不使用一些承诺拥有一切的平台/解决方案，总是使用自定义/尝试堆栈

首先是稳定性问题和平台的持续故障，例如服务器停机时间和随机错误，但它们已经解决了所有问题（那是在 2014 年年中），但以下问题仍然存在：

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

任意示例：您想从他们的数据库中获取随机项目，您的应用程序调用将提供它的作业（1 个 API 调用），该作业查询数据库，但您必须进行 2 次调用，首先获取项目的数量（1 个 API 调用），然后第二个获取随机项目（1 个 API 调用），这是针对该功能的 3 个 API 调用，每秒 60 个请求，20 个用户可以在在达到请求限制和平台失控之前的给定时间，在您包括浏览应用程序屏幕和内容的其他用户之后，您会看到这会导致什么......

如果它有任何好处，Facebook 不会每次提到都使用它来购买它的一些应用程序吗？我建议三件事：-第一-不要听 Parse 的家伙，这是他的平台，所以他必须推广它，听那些一直在使用它的人使用它来制作东西
-第二-如果你需要一个严肃的和可扩展的平台，不想完全定制，去亚马逊云服务或类似的经过测试和可靠的东西 - 第三 - 如果你有任何服务器端经验，请远离平台，如果你不去雇佣该项目的后端开发人员，它会更便宜，你最终会得到一个可行的解决方案

于 2015-02-07T22:02:30.263 回答
11

我花了一天时间研究 parse.com，这是我目前根据我发现的观点得出的结论（请记住，我目前只有非常简短的 SDK 开发经验）..

Parse.com 显然有一些非常吸引人的积极因素，这就是为什么我发现自己正在研究它，但为了辩论，我将专注于批评，因为伟大的积极因素都列在他们的网站上。（干得好 parse.com 试图解决如此大的问题！）...

  • 在推荐中，Hipmunk 是我想说的最大的名字。它被列为使用 SDK 数据部分的应用程序。如果不接触 Hipmunk 开发人员，我无法确定，但我无法想象他们将所有数据存储在 parse.com 云中。
  • 在尝试并浏览了列出的大多数应用程序之后。没有一个真正脱颖而出，因为它非常依赖服务器后端，所以我发现无法了解基于这些使用 parse.com 是否解决了可伸缩性问题。
  • 该网站列出了 40,000 个应用程序并且还在不断增加。我觉得（但不知道）基于应用程序库，这个数字是基于用户群中的应用程序数量，而不是应用程序商店中真实的实时生产应用程序。如果有那么多应用程序使用 parse.com，那么应用程序库将拥有更多大牌。

Parse.com 是一个非常新的概念，甚至与其最接近的竞争对手也大不相同。因此，如果没有关于它的可扩展性和稳定性（以及所有其他方面）的具体证据，那么项目的开发人员很难考虑投入它，因为风险太大。

于 2012-10-30T21:28:14.907 回答
11

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

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

测试详情：

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

（上传63张图片，平均文件大小=80K）

使用 android SDK 测试 1 RESULT=Slow performance

测试 2 在 android RESULT=VERT FAST 上使用本机 REST 调用

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

关于 http thruput 、 parse SDK(android) 和性能，可能是 parse.com 在 parse.android SDK 中实现 android asyncTask() 的方式上没有优化性能？需要8分钟的工作如何。在 parse.sdk 上可以在 3 秒内在优化的 REST、DIY 框架上完成（有关实现的详细信息，请参阅链接），我真的不知道。如果 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 员工。

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

Parse API 是简单的 JSON。因此，您可以以 Parse 应用程序期望的相同 JSON 格式提取数据。

您甚至可以使用他们的 PFObject (iOS)。在某些时候，所有高级 API 都用于一个常见的 HTTP 请求/响应。REST 通用性的好处是通用的。诸如 http、url、字符串和 utf 之类的东西。这里没有时髦的 Orb。

于 2013-07-30T20:21:45.083 回答
5

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

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

如果他们可以解决性能和稳定性问题，那将是一个神圣的平台。我不知何故后悔使用它进行开发，但我输入了 5000 多行代码，所以我会坚持使用它。

也许他们应该将他们的 DEV 应用程序和 PROD 应用程序环境分开，并且在某种监督之后才允许 PROD 应用程序，或者创建一个只有付费客户的不同环境？

我们在 2014 年，每月 20 美元的服务器可以处理未优化的网站（主页上 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 回答