Насколько масштабируемым является Parse? [закрытый]

Я рассматривал возможность использования Parse.com ' s сервис для моего бэкэнда, но я скептически отношусь к его масштабируемости.

Он может действительно обрабатывать несколько тысяч одновременных пользователей? Если нет, то является ли их хорошим способом перехода от него?

9 55
parsing iphone scalability parse.com

9 ответов:

Я знаю, что вопрос может быть старым, но хотел бы предоставить свои 2 цента для других, кто может рассматривать разбор....

в самых простых сценариях разбор может работать хорошо. Как только вам нужно масштабировать до более сложных запросов, я лично не нашел ничего, кроме головных болей.

  1. запросы ограничены до 1000 записей. Первоначально вы можете подумать, что это не проблема, пока вы не начнете работать с подзапросами и не поймете, что странные данные возвращается, потому что вложенный запрос отключает записи без предупреждения или ошибки. (FYI, по умолчанию 100 записей, Если вы не укажете предел до 1000, так что проблема еще хуже, если вы не обращаете внимания).

  2. по какой-то странной причине существует ограничение на количество раз, когда вы можете выполнить запрос count за минуту. (и этот предел, кажется, действительно низкий). Будьте готовы попробовать и дросселировать свой код, чтобы вы не попали в этот предел, иначе ошибки заброшенный.

  3. фоновые задания не выполняются надежно. У меня было фоновое задание, установленное для запуска каждые 5 минут, и иногда требуется 20+ мин, прежде чем работа начнет работать.

  4. много тайм-аутов. Это тот, который дает мне больше всего изжоги. О. Если у вас есть облачная функция, которая занимает некоторое время для обработки, у вас есть около 6 или 7 секунд, чтобы сделать это, или это отключит вас.
    B. У меня такое чувство, что есть общая нестабильность с системой. Периодически я сталкиваюсь с проблемами, которые, кажется, длятся около часа или около того, где тайм-ауты происходят чаще (и с относительно простыми функциями, которые должны немедленно возвращаться).

Я полностью сожалею о своем решении использовать parse, и я делаю все возможное, чтобы сохранить приложение достаточно долго, чтобы мы могли получить финансирование, чтобы мы могли уйти с платформы. Если у кого есть лучшие альтернативы для разбора, я все уши.

75

[Edit: после трех удивительных лет работы в команде я решил двигаться дальше и больше не являюсь сотрудником Parse или Facebook. Команда находится в больших руках и сделала удивительные вещи. Весь бэкэнд был переписан, чтобы значительно повысить производительность и надежность. Дорожная карта удивительна, и я ожидаю, что от команды придут большие вещи. На момент моего отъезда Parse подавал более 600 000 заявок и обслуживал умопомрачительное количество запросов каждый день. Были ли каждый разбор толчком к отправляясь к уникальному человеку, они могли бы за один день сформировать четвертую по величине страну мира. Для будущей помощи с разбором, пожалуйста, либо разместить вопросы здесь с помощью parse.com тег или сообщение в группу parse-developers Google.]

полное раскрытие: я инженер разбора.

разбор уже хостов тысячи приложения, не говоря уже о пользователях. Когда мы вышли из бета-версии в конце марта, мы объявил более 10 000 приложений, работающих на разборе с 40% месячный темп роста. Parse укомплектован командой мирового класса, многие из которых имеют многолетний опыт работы с большими данными и большим объемом трафика.

мы приветствуем ваше движение с распростертыми объятиями; вы будете в компании больших команд как группа дня и Hipmunk. Мы настолько уверены в наших услугах, что построили наш Один Клик Экспортировать система так что люди, как вы можете попробовать разобрать без риска. Если вы чувствуете, что разбор не соответствует вашей производительности ожидания, мы с радостью отправим вас со всеми вашими данными в целости и сохранности.

35

мы выбрали 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 минут спустя, и он работает менее чем за секунду. Повторите попытку через 20 минут,и она займет 30 секунд.

потому что нет транзакционности это действительно очень весело при хранении для экземпляр 3 объектов в 1 функции облачного кода, где Parse решает выйти из функции случайным образом после того, как, скажем, сохранив 2 из 3 объектов. Отлично подходит для обеспечения согласованности вашей базы данных.

"лучшие" из них мы получили, где эти. Имейте в виду, что это фактические данные, возвращающиеся из функции облачного кода:

 {"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 ошибок (с которыми я столкнулся дважды в a месяц) все остальные наблюдаются ежедневно.

так что да, это очень легко начать, но вы должны принять во внимание, что вы работаете на нестабильной платформе, поэтому убедитесь, что вы получили ваши повторы и экспоненциальные системы отката и работает, потому что вам это понадобится!

что меня больше всего беспокоит, так это то, что я понятия не имею, что произойдет, когда 20 000 человек начнут использовать мое приложение на этом бэкэнде.

edit:

сейчас у меня есть это при выполнении входа в систему 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)

разве это не здорово?

23

Если вы пишете небольшое / простое приложение (или одноразовый прототип) с небольшим количеством логики на бэкэнде, тогда идите на это, но для чего-то большего/масштабируемого лучше всего избегать этого, я могу сказать, что из первых рук. Все это звучит хорошо с их управлением пользователями, push-уведомлениями, абстрактным хранилищем и тем, что нет, но в конце концов это не стоит хлопот. А именно я разрабатывал бэкэнд для приложения на Parse, клиенты были так много в него, потому что это звучало круто и многообещающе (сильный маркетинг, я думаю), будучи купленным Facebook, а что нет, но через несколько недель в производстве начали возникать серьезные проблемы/ограничения с платформой, что должно быть простым приложением, оказалось кошмаром для разработки и масштабирования.

результат / заключение проекта: - сломал окно времени для относительно простого приложения - он должен был длиться 2-3 месяца, он длился почти год и все еще не стабилен/надежен, если бы мы использовали пользовательский стек, это было бы сделано в течение времени окно наверняка, потому что я сделал аналогичный демо-проект за 5-10 дней с пользовательским стеком узлов - потерял доверие клиента, теперь они переделывают приложение с другой командой, которая будет использовать пользовательский стек - потерянные грузы наличных денег для взлома временного окна и попытки заставить его работать - из-за этого было так много сверхурочных, что это начало отражаться на моем здоровье - никогда не используйте какую-либо платформу/решение, которое обещает иметь все это, всегда идя с пользовательским/пробным стеком

сначала были вопросы стабильности и постоянные сбои платформы, такие как простои серверов и случайные ошибки, но они все это разобрали (это было в начале-середине 2014 года), но остаются следующие проблемы:

  • вы не можете отлаживать свой код, по крайней мере в настоящее время (есть способы заставить его работать с дополнительным узловым сервером и некоторой неясной lib)
  • ограничения смешны, масштабируемая платформа, которая может выполнять 50-60 запросов API в секунду (или больше в зависимости от вашего подписка), которая не так низка, как кажется, пока вы не начнете делать тест на растяжение, и когда вы нажмете на нее, ваш код будет постоянно терпеть неудачу
  • вызовы API измеряются следующим образом: вызов функции сервера (задание синтаксического анализа) - 1 вызов, запрос к базе данных-1 вызов, другой запрос (потому что у них нет какой - то продвинутой/сложной системы запросов, если у вас есть более сложная схема базы данных, вы очень скоро поймете, что я имею в виду) - 1 вызов, если вам нужно получить более 1000 запросов угадайте, что-запрос опять же, и т. д., запрос для подсчета (вам нужно сделать это как отдельный запрос), который является ненадежным (имеет тенденцию возвращать приближение для нескольких тысяч записей)
  • создание / сохранение ~1000 + простых объектов-это нагрузка на платформу / базу данных, удаление 1000 или более объектов, даже более того, что смешно быстро для обычных баз данных, но при разборе это занимает 5-10 минут (если вы проверите его более внимательно, он удаляет 20 объектов за пакет)
  • невозможно использовать большинство пакетов npm (только на чистом JavaScript и близкими, в том числе источника напрямую)
  • если вы идете и читаете форумы разбора, вы увидите, что пользователи постоянно понижают / обжаривают команду разбора из-за отсутствия функций платформы и необходимости прыгать через обручи для произвольной логической реализации, такой как выборка случайных записей и тому подобное
  • они поддерживают интеграцию с полосой, но если вы хотите использовать Paypal или какой-либо другой платежный сервис (мы решили использовать Paypal, потому что у него есть значительно превосходящая страна поддержка над полосой) вы не можете заставить его работать на разборе, для интеграции Paypal мне пришлось использовать отдельный сервер, чтобы вытащить его
  • нет простого способа синхронизировать пользователей и обрабатывать проблемы параллелизма, вы должны использовать хаки и некоторые забавные логики, которые вы бы не использовали или не признавали использование нигде никогда
  • хотите 100+, не говоря уже о 1000 + одновременных пользователей, удачи в этом
  • когда вы хотите узнать количество записей в таблице, вы можете лимит на вызов графа запрос, который это смешно, не документирован и совершенно нелеп, и в конце концов возвращает приблизительное число
  • модульность чужда платформе, функции, которые вы вызываете из своих заданий, не могут длиться более нескольких секунд (я думаю, 7 секунд), и когда вы принимаете во внимание время запроса, это обязательно произойдет с более сложными запросами и некоторой сложной логикой
  • вы можете иметь что-то вроде заданий Cron, но они не могут длиться более 15 минут (из-за низкая производительность платформы, такая как несколько запросов, которые очень, очень короткие), они ограничены 2-3-4 одновременными заданиями в зависимости от вашей абонентской платы и имеют очень ограниченную/плохую систему планирования (например, вы не можете редактировать ее из своего кода, она очень ограничена, поэтому вам нужно использовать хаки для запуска одной и той же работы в 2 точных раза в течение дня или что-то подобное, он не может следить за экономией времени и т. д.)
  • когда вы получаете сообщение об ошибке на сервере это может быть полностью вводит в заблуждение, проверьте форумы для этого, не могу вспомнить ничего из верхней части моего ума
  • Push-уведомления регулярно опаздывают на 20-30 минут

произвольный пример: вы хотите получить случайный элемент из базы данных, ваше приложение делает вызов на работу, что ее предоставим (1 вызов API), задание запросы к базе данных, но вы должны сделать 2 звонки, во-первых, чтобы получить количество элементов (1 вызов API), а затем второй, чтобы получить случайный предмет (1 вызов API), это 3 вызовов API для этой функциональности и с 60 запросами в секунду 20 пользователей могут сделать этот вызов в заданное время, прежде чем нажимать предел запроса и платформу, идущую вразнос, после включения других пользователей, просматривающих экраны приложений и прочее, вы видите, к чему это приводит...

Если бы это было хорошо, разве Facebook не купил бы его каждое упоминание, используя его даже для некоторых своих приложений? Я предлагаю 3 вещи: - во-первых-не слушайте парня разбора, это его платформа, поэтому он должен продвигать ее, слушайте для людей, которые использовали его, чтобы сделать что-то с его помощью
- во-вторых - если вам нужна серьезная и масштабируемая платформа и вы не хотите идти полностью на заказ, перейдите на облачные сервисы Amazon или что-то подобное, что проверено и надежно - в-третьих-держитесь подальше от платформы, если у вас есть опыт работы на стороне сервера, если вы не пойдете и не наймете бэкэнд-разработчика для проекта, это будет дешевле, и вы получите рабочее решение в конце

20

Я провел день, изучая parse.com и вот мое текущее мнение, основанное на том, что я нашел (пожалуйста, имейте в виду, что у меня есть только очень короткий опыт разработки с SDK)..

Parse.com очевидно, есть некоторые очень привлекательные положительные стороны, поэтому я обнаружил, что изучаю его, но ради дебатов я сосредоточусь на том, чтобы быть критичным, поскольку все великие положительные стороны перечислены на их веб-сайте. (Молодец parse.com за попытку решить такую отличная проблема!)...

  • в отзывах, Hipmunk-это самое большое имя, которое я бы сказал. Он указан как приложение, которое использует часть данных SDK. Не приближаясь к разработчикам Hipmunk, я не могу знать наверняка, но я не могу представить, что они хранят все свои данные в parse.com облако.
  • после попытки и просмотра большинства перечисленных приложений. Ни один из них действительно не выделяется как сильно зависящий от серверной части, поэтому я считаю невозможным получить представление о том, есть ли или нет масштабируемость была решена с помощью parse.com исходя из этого.
  • на веб-сайте указано 40 000 приложений и подсчет. Я чувствую (но не знаю), что на основе галереи приложений эта цифра основана на количестве приложений в их пользовательской базе, а не на реальных живых производственных приложениях в магазинах приложений. В галерее приложений было бы гораздо больше крупных имен, если бы многие приложения использовали parse.com.

Parse.com это очень новая концепция, и очень отличается даже от своих ближайших конкурентов. Так что без конкретные доказательства того, насколько масштабируемым и стабильным (и все остальное) он является, тогда разработчику проекта очень трудно рассмотреть возможность его принятия, поскольку слишком многое поставлено на карту.

11

Я провел тесты для моего собственного ответа на подобный вопрос и это может быть очень, очень быстро. Однако , результаты, которые вы получите, могут зависеть от деталей реализации...

тест сравнил Android SDK с Android, используя собственный стек HTTP, делая вызовы Parse / REST...

Тест Детали:

испытательная среда-самая новая версия Андроида на телефоне 10 месяцев старом над быстрым соединением вифи.

(загрузить 63 фотографии, где средний размер файла=80K )

тест 1 с помощью Android SDK результат=низкая производительность

тест 2 с использованием собственных вызовов REST через android RESULT=VERT FAST

-- EDIT-- как есть интерес здесь....

Что касается http thruput, Parse SDK (android) и производительности, это может быть так parse.com не оптимизирована производительность на пути, что они реализуют android asyncTask () в разборе.SDK для Android? Как работа, которая требовала 8 мин. на разборе.SDK может быть сделано в течение 3 секунд на оптимизированный REST, DIY framework (см. ссылки для получения подробной информации о реализациях), я действительно не знаю. Если parse не исправили их реализацию SDK с момента запуска этих сравнительных тестов, то вы, вероятно, не хотите, чтобы их SDK по умолчанию asnyctask делал что-то приближающееся к реальной рабочей нагрузке в сети.

11

большая привлекательность Parse (и подобных SaaS) заключается в том, что вы можете сэкономить десятки тысяч на внутренних затратах на разработку. Учитывая, что back-end часто является самым дорогим аспектом веб-приложения; эта головная боль внезапно бац.

проблема с Parse и большинством (всех) SaaS заключается в том, что область, мощность, память, пропускная способность, масштабируемость, пороги, предупреждения и различные действия находятся вне вашего контроля.

то же самое с Shopify. Это отличный Saas с всесторонний контроль над продуктами, заказами, запасами и эстетикой - но нулевой контроль над машиной. Итак, сегодняшний SaaS не сильно отличается от godaddy. Они неизменно перепродают или максимизируют свои машины, чтобы заработать деньги; и вы застряли, если вы действительно заботитесь о производительности задницы. Вы даже не можете купить этот уровень обслуживания.

Я хотел бы что-то, по крайней мере, столь же мощное и всеобъемлющее, как консоль AWS. Большинство технарей знают и принимают это Heroku и разобрать оба, размещенных на платформе AWS. Кого волнует. Поэтому взимайте дополнительную плату за добавленную услугу, но не отказывайте в доступе к тем критическим низкоуровневым инструментам, которые делают сайт и приложение и пользовательский интерфейс zing. Намекните тем, кто разбирает сотрудников.

в любом случае, в ответ на вопрос:

API разбора-это простой JSON. Таким образом, вы можете выкачивать данные в том же формате JSON, что и приложение синтаксического анализа.

вы могли бы даже быть в состоянии использовать их объектов (ио). В какой-то момент весь этот высокоуровневый API переходит к общему HTTP-запросу/ответу. Хорошая вещь об общности REST означает common-of-the-shelf; такие вещи, как http, url, strings и utf. Здесь нет фанкового шара.

8

Parse отлично подходит для начала с особенно вспомогательных функций / функций управления пользователями. Но я начал сталкиваться с проблемами ..

длительное время выполнения / ping, ограничение на 1000 объектов, включая подзапросы, нет центров обработки данных в Европе (насколько я знаю)

Это была бы Божественная платформа, если бы они могли сортировать проблемы производительности и стабильности. Я как-то сожалею о разработке с ним, но я поставил 5000+ строк кода, поэтому я собираюсь придерживаться его.

может быть, они должны ли они отделять свои приложения для разработчиков и среды приложений PROD и разрешать приложения PROD только после какого-либо наблюдения или создавать другую среду только с платежными клиентами?

мы находимся в 2014 году, $20/месяц серверы могут обрабатывать неоптимизированные веб-сайты (60 не-кэшированные запросы БД на главной странице) с 1 млн посещений/месяц, это не должно быть так трудно прийти на разбор!

5

это нормально для прототипирования приложений, особенно если разработчик iOS/Android не знает, как построить БД/API бэкэнд сам.

это совсем не нормально, когда речь заходит о разработке приложения с логикой, которая требует запросов более сложных, чем:

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

связанные запросы и внутренние соединения не существуют при синтаксическом анализе. И удачи в обновлении / удалении 320 000 записей, Если вам нужно (это число, с которым я сейчас работаю).

единственное, что действительно полезно обрабатывать пользователей через SDK. Если бы я мог найти хорошие документы или даже учебник, как обрабатывать/создавать пользователей через приложения iOS/Android с помощью Django и DRF/Tastypie, я мгновенно конвертирую все, что разрабатывается в нашей компании, чтобы использовать это.

2