Я рассматривал возможность использования Parse.com для моего бэкэнд, но я скептически отношусь к его масштабируемости.
Может ли он обрабатывать несколько тысяч одновременных пользователей? Если нет, может ли их какой-либо хороший способ отказаться от него?
Я знаю, что вопрос может быть старым, но хотел предоставить мои 2 цента для других, которые могут рассматривать синтаксический анализ....
В простейшем из сценариев анализ может работать хорошо. Как только вам нужно масштабировать до более сложных запросов, я лично не нашел ничего, кроме головных болей.
Запросы ограничены 1000 записями. Первоначально вы можете подумать, что это не проблема, пока вы не начнете разбираться с подзапросами и не поймете, что странные данные возвращаются, потому что подзапрос сокращает записи без предупреждения или ошибки. (FYI, по умолчанию 100 записей, если вы не указали ограничение до 1000, поэтому проблема еще хуже, если вы не обращаете внимания).
По какой-то странной причине существует ограничение на количество раз, когда вы можете выдать запрос count в мин. (и этот предел действительно очень низкий). Будьте готовы попробовать и дросселировать свой код, чтобы вы не попали в этот предел, иначе будут выброшены ошибки.
Фоновые задания не работают надежно. У меня было задание фонового задания, которое запускается каждые 5 минут, и есть время, когда требуется 20+ минут, прежде чем работа начнет работать.
Множество тайм-аутов. Это тот, который дает мне самую изжогу.
A. Если у вас есть облачная функция, которая требует времени для обработки, у вас есть около 6 или 7 секунд, чтобы выполнить ее, или она отключит вас.
B. У меня возникает ощущение, что в системе существует общая нестабильность. Периодически я сталкиваюсь с проблемами, которые, как представляется, продолжаются около часа или около того, когда тайм-ауты случаются чаще (и с относительно простыми функциями, которые должны немедленно возвращаться).
Я полностью сожалею о своем решении использовать синтаксический анализ, и я делаю все возможное, чтобы поддерживать приложение достаточно долго, чтобы мы могли получить финансирование, чтобы мы могли покинуть платформу. Если у кого-то есть лучшие альтернативы синтаксическому анализу, я все уши.
[Edit: после трех удивительных лет с командой, я решил двигаться дальше и больше не являюсь сотрудником Parse или Facebook. Команда в отличных руках и сделала удивительные вещи. Весь бэкэнд был переписан, чтобы значительно повысить производительность и надежность. Дорожная карта поразительна, и я ожидаю, что из команды придут большие дела. Во время моего отъезда, Parse приводил в действие более 600 000 приложений и каждый день подавал огромное количество запросов. Если бы каждый сингл Parse был отправлен уникальному человеку, он мог бы составить четвертую по величине страну в мире за один день. Для дальнейшей помощи в Parse, пожалуйста, отправляйте вопросы здесь с тегом parse.com или по почте в группу разработчиков Google.]
Полное раскрытие информации: Я инженер-аналитик.
В Parse уже есть тысячи приложений, не говоря уже о пользователях. Когда мы вышли из бета-версии в конце марта, объявила более 10 000 приложений, работающих на Parse, с темпами роста на 40% по сравнению с предыдущим месяцем. Parse укомплектован командой мирового класса, многие из которых имеют многолетний опыт работы с большими объемами данных и большим объемом трафика.
Мы приветствуем ваш трафик с распростертыми объятиями; вы будете в компании отличных команд, таких как Band of the day и Hipmunk. Мы настолько уверены в наших услугах, что построили нашу One Click Export, чтобы такие люди, как вы, могли попробовать без риска анализа. Если вы чувствуете, что 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 пользователей max!
Это типичный, который мы возвращаемся все время, в совершенно произвольные моменты и невозможно воспроизвести. Вызов функции Cloud Code, которая выполняет несколько запросов и несколько вставок:
{"code":124,"message":"Request timed out"}
Попробуйте те же 10 минут спустя, и он пройдет менее чем за секунду. Повторите попытку через 20 минут, и для выполнения потребуется 30 секунд.
Поскольку транзакции не существует, на самом деле это очень забавно при хранении, например, трех объектов в 1 функции Cloud Code, где Parse решает освободиться от функции случайным образом, после того как скажу, что сохранил 2 из 3 объектов. Отлично, чтобы ваша база данных была последовательной.
"Лучшие" мы получили там, где они. Имейте в виду, что это фактические данные, возвращаемые из функции 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)
Разве это не здорово?
Если вы пишете небольшое/простое приложение (или прототип прототипа) с практически никакой логикой на бэкэнд, то идите на него, но для чего-то большего/масштабируемого лучше всего его избежать, могу сказать, что с первого ручной опыт. Все это звучит хорошо с их управлением пользователями, push-уведомлениями, абстрактным хранилищем, а что нет, но в конце концов это не стоит проблем. А именно, я разрабатывал бэкэнд для приложения на Parse, клиенты были так много в нем, потому что это звучало круто и многообещающе (сильный маркетинг, я думаю), который купил Facebook, а что нет, но несколько недель в производстве значительных проблем/ограничений с платформа начала возникать, то, что должно быть простым приложением, оказалось кошмаром для развития и масштабирования.
Результат/заключение проекта: - сломал окно времени для относительно простого приложения - оно должно было длиться 2-3 месяца, оно продолжалось почти год и все еще не стабильно/надежно, если бы мы использовали собственный стек, который он делал бы во временном окне для уверен, что я сделал аналогичный демонстрационный проект за 5-10 дней с помощью пользовательского node стека - потеряли доверие клиентов, теперь они переделывают приложение с другой командой, которая будет использовать собственный стек - потерянные наличные деньги за нарушение временного окна и попытки заставить его работать - сделал так много сверхурочной причины, что он начал размышлять о моем здоровье - никогда не использовать какую-либо платформу/решение, чтобы promises иметь все это, всегда используя специализированный/проверенный стек
Сначала были проблемы с стабильностью и постоянным сбоем платформы, например, время простоя сервера и случайные ошибки, но все они были отсортированы (это было в начале-середине 2014 года), но остаются следующие проблемы:
Произвольный пример: вы хотите получить случайный элемент из своей базы данных, приложение делает вызов заданию, которое его предоставит (1 вызов API), задание запрашивает базу данных, но вам нужно сделать 2 вызова, сначала получить количество элементов (1 вызов API), а затем второй, чтобы получить случайный элемент (1 вызов API), это 3 вызова API для этой функции и с 60 запросами в секунду, 20 пользователей могут сделать что вызов в заданное время, прежде чем попасть в лимит запроса, и платформу, идущую haywire, после того, как вы включите других пользователей, просматривающих экраны приложений и прочее, вы увидите, где это ведет...
Если бы это было хорошо, Facebook не купил бы его, если бы упоминал об использовании его даже для некоторых своих приложений? Я бы предложил 3 вещи:
- сначала - не слушайте Парса Парса, это его платформа, поэтому он должен продвигать его, слушать людей, которые использовали его, чтобы сделать что-то, используя его
- второй - если вам нужна серьезная и масштабируемая платформа и вы не хотите полностью настраиваться, перейдите на сервисы Amazon Cloud или что-то подобное, что проверено и надежно
- в-третьих - держаться подальше от платформы, если у вас есть опыт работы на стороне сервера, если вы не поедете и не наняте backend dev для проекта, это будет дешевле, и вы в конечном итоге получите рабочее решение.
Я провел день, глядя на parse.com, и вот мое текущее мнение, основанное на том, что я нашел (Пожалуйста, имейте в виду, что у меня есть только очень короткий опыт разработки с SDK пока).
Parse.com явно имеет некоторые очень привлекательные положительные моменты, поэтому я обнаружил, что смотрю на него, но для обсуждения я сконцентрируюсь на том, чтобы быть критическим, поскольку все положительные результаты перечислены на их веб-сайте. (Хорошо сделанный parse.com для попытки решить такую большую проблему!)...
Parse.com - это очень новая концепция и очень отличается даже от ближайших конкурентов. Таким образом, без конкретных доказательств того, насколько масштабируемы и стабильны (и все остальное), это очень сложно для разработчика по проекту рассмотреть возможность совершения этого, поскольку слишком много поставлено на карту.
Я провел тесты для своего собственного ответа на аналогичный question, и это может быть ОЧЕНЬ, ОЧЕНЬ БЫСТРО. Однако полученные вами результаты могут зависеть от деталей вашей реализации...
Тест сравнивает Android SDK с Android, используя собственный HTTP-стек, создающий вызовы Parse/REST...
Детали теста:
Тестовая среда - новейшая версия Android на 10-месячном телефоне по быстрому WIFI-соединению.
(загрузите 63 снимка, где avg filesize = 80K)
тест 1 с использованием SDK android SDK = медленная производительность
test 2 с использованием собственных вызовов REST через android RESULT = VERT FAST
- РЕДАКТИРОВАТЬ - как есть интерес здесь....
Что касается http thruput, синтаксического анализа SDK (android) и производительности, может быть, что parse.com не оптимизировал производительность на том, как они реализуют android asyncTask() в SDK parse.android? Как работа, которая требуется 8 мин. на parse.sdk можно сделать за 3 секунды на оптимизированной структуре REST, DIY (см. ссылки для подробностей о реализации), я действительно не знаю. Если синтаксический анализ не исправил реализацию SDK, так как эти сравнительные тесты выполнялись, то вы, вероятно, не хотите, чтобы их файлы по умолчанию asnycTask по умолчанию делали что-либо, приближающееся к реальной рабочей нагрузке в сети.
Большая привлекательность в отношении Parse (и аналогичных SaaS) заключается в том, что вы можете сэкономить десятки тысяч на стоимости разработки. Учитывая, что back-end часто является самым дорогим аспектом веб-приложения; что голова-болит внезапно пуф.
Проблема с Parse и большинством (всего) SaaS заключается в том, что область, мощность, память, пропускная способность, масштабируемость, пороговые значения, предупреждения и различные действия выходят из-под вашего контроля.
То же самое с Shopify. Это отличный саас с полным контролем продуктов, заказов, инвентаря и эстетики, но без контроля над машиной. Итак, сегодня SaaS не чертовски много отличается от godaddy. Они всегда перепродают или максимизируют свои машины, чтобы заработать деньги; и вы застреваете, если вы действительно заботитесь о производительности задницы. Вы даже не можете купить этот уровень обслуживания.
Я бы хотел, чтобы что-то AT LEAST было столь же мощным и всеобъемлющим, как консоль AWS. Большинство технарей знают и принимают, что Heroku и Parse оба размещены на AWS. Какая разница. Поэтому платите больше за добавленную услугу, но не запрещайте доступ к тем критически важным инструментам низкого уровня, которые делают сайт и приложение, а пользовательский интерфейс zing. Подсказка для сотрудников Parse.
Во всяком случае, в ответ на вопрос:
API-интерфейс Parse - простой JSON. Таким образом, вы можете откачивать данные в том же формате JSON, который ожидает приложение Parse.
Возможно, вы даже сможете использовать свой PFObject (iOS). В какой-то момент все эти API высокого уровня идут на общий HTTP-запрос/ответ. Хорошая вещь об общей природе REST означает обычную основу; такие вещи, как http, url, strings и utf. Здесь нет фанки.
Parse отлично работает с особенно вспомогательными функциями/функциями управления пользователями. Но я начал сталкиваться с проблемами.
Длительное время выполнения/пинга, ограничение 1000 объектов ВКЛЮЧАЯ подзапросы, нет центров обработки данных в Европе (насколько я знаю)
Это была бы божественная платформа, если бы они могли сортировать проблемы производительности и стабильности. Я как-то сожалею об этом, но я поставил 5000 строк кода, поэтому я буду придерживаться его.
Может быть, они должны отделить свои приложения DEV и приложения PROD-приложений и разрешить приложения PROD после какого-то контроля или создать другую среду с оплатой только клиентов?
Мы в 2014 году, серверы $20/month могут обрабатывать неоптимизированные веб-сайты (60 не-кэшированных запросов db на главной странице) с 1 миллионом посещений/месяц, это не должно быть так сложно на Parse!
Это нормально для прототипирования приложений, особенно если разработчик iOS/Android не знает, как создать сам БД /API.
Это совсем не нормально, когда дело доходит до разработки приложения с логикой, которая требует более сложных запросов:
SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100;
Связанные запросы и внутренние соединения не существуют в Parse. И удачи, чтобы обновить/удалить 320 000 записей, если вам нужно (с номером, с которым я сейчас работаю).
Единственное, что действительно полезно, - это обработка Пользователей через SDK. Если бы я мог найти хорошие документы или даже учебник, как обрабатывать/создавать пользователей через приложения iOS/Android с помощью Django и DRF/Tastypie, я мгновенно конвертирую все, что разрабатывается в нашей компании, чтобы использовать это.