Parse는 얼마나 확장 가능합니까?
백엔드에 Parse.com의 서비스 사용을 고려하고 확장성에 대해 회의적입니다.
실제 수천 명의 동시 사용자를 처리 할 수 있습니까 ? 당신은 그것으로부터 멀어지고 있습니까?
나는 질문이 오래 될 수있는 생각이있는 다른 파싱을 고려하고 싶었습니다 ....
가장 간단한 시나리오에서는 구문 분석이 잘 작동 할 수 있습니다. 더 복잡한 쿼리로 확장해야하자마자 저는 개인적으로 골칫거리 밖에없는 것을 발견했습니다.
쿼리는 1000 개의 개의 레코드로 제한됩니다. 처음에는 하위 쿼리를 처리하기 시작하고 하위 쿼리가 경고 나 오류없이 레코드를 잘라 내기 때문에 이상한 데이터가 반환 될 때까지 문제가 해결되지 않습니다. (참고로, 최대 1000 개까지 제한을 지정하지 않는 한 방송은 100 개 레코드에서 나열주의를 기울이지 않게됩니다.)
이상한 언어 분당 언어 쿼리를 수있는 횟수에 제한이 있습니다. (그리고이 제한은 정말 낮은 것입니다). 이 제한에 도달하지 않도록 코드를 시도하고 제한 할 준비를하십시오. 개체 오류가 발생합니다.
백그라운드 작업이 안정적으로 실행되지 않습니다. 나는 5 분마다 실행 가능한 백그라운드 작업을 설정하고 작업이 시작되기까지 20 분 이상이있는 경우가 있습니다.
많은 시간 초과. 이것은 나에게 가장 속쓰림을주는 것입니다. A. 처리하는 데 시간이 배치 된 기능이있는 경우 완료하는 데 약 6 ~ 7 초가 걸리지 필터링 차단합니다.
B. 시스템이 전반적으로 바보 같은 느낌을받습니다. 주기적으로 약 한 시간 정도 지속되는 것처럼 보이는 문제가 발생하여 시간 초과가 더 자주 발생합니다 (즉시 반환하는 간단한 함수).
구문 분석을 사용하기로 결정한 것을 전적으로 후회하며, 자금을 확보 할 수있는 앱을 오래 유지하여 플랫폼에서 사용하기 위해 최선을 다하고 있습니다. 누구든지 구문 분석에 대한 더 나은 대안이 있다면 나는 모두 귀입니다.
[편집 : 팀과 함께한 놀라운 3 년 후, 저는 계속 진행하기로 결정하고 더 이상 Parse 또는 Facebook 직원이 아닙니다. 팀은 훌륭한 손에 뛰어난 일을 해. 성능과 안정성을 대폭 향상시키기 위해 전체 백엔드가 다시 작성됩니다. 로드맵은 놀랍고 팀에서 큰 성과가 나올 기대합니다. 출국 지금 Parse는 600,000 개 이상의 애플리케이션을 지원하고 매일 엄청난 요청을 처리했습니다. 각각의 Parse 푸시를 고유 한 사람에게 보내면 하루 만에 세계에서 네 번째로 큰 국가가 될 수 있습니다. Parse에 대한 우려를 투표하려면 parse.com 태그를 사용하여 여기에 질문을 게시하거나 parse-developers Google 그룹에 게시하세요.]
전체 공개 : 저는 Parse 엔지니어입니다.
구문 분석 이미는 user-는 물론 수천 개의 앱을 호스팅하고 있습니다. 3 월 말 베타를 종료했을 때 Parse에서 실행되는 10,000 개 이상의 애플리케이션을 월간 40 % 성장률로 발표했습니다. Parse는 빅 데이터 및 대용량 트래픽 분야에서 수년간의 경험을 가진 수준의 팀으로 구성되어 있습니다.
우리는 두 팔을 벌려 귀하의 교통을 환영합니다. 밴드 오늘의 및 Hipmunk 와 같은 훌륭한 김태연의 회사에 속하게 됩니다. 우리는 서비스에 대한 확신이있어서 One Click Export 시스템을 구축하여 여러분과 같은 사람들이 위험 부담없이 Parse를 볼 수 있습니다. 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 명의 사용자로 테스트중인 앱입니다!
이것은 우리가 항상 완전히 임의의 순간에 되돌려주고 재현 할 수없는 전형적인 것입니다. 몇 가지 쿼리와 몇 가지 삽입을 수행하는 Cloud Code 함수 호출 :
{"code":124,"message":"Request timed out"}
10 분 후에 동일한 작업을 시도하면 1 초 내 실행됩니다. 20 분 다시 시도하고 실행하는 데 30 다시가 시도하고 실행합니다.
트랜잭션이 없기 때문에 인스턴스 3 개를 Cloud Code 함수 1 개에 표시 할 때 정말 재미 있습니다. 여기서 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)
대단하지 않나요?
백엔드에 작은 것이 거의 또는 전혀없는 것이 좋습니다. 직접 경험에서 말할 수 있습니다. 모든 것이 사용자 관리, 푸시 알림, 추상화 된 저장소와 잘 어울리지 만 결국 문제가되지 않습니다. 즉, 저는 Parse에서 앱의 백엔드를 개발하고 있었는데, 클라이언트는 멋지고 유망한 것처럼 들렸고 (강력한 마케팅이라고 생각합니다) Facebook에서 구입 한 것과 동일한 것 같았지만 몇 주 동안 주요 문제 / 제한 사항을 제작했습니다. 플랫폼이 생겨나 기 시작되고, 단순한 앱이되어야하는 것이 개발 및 확장에 악몽으로 만들어졌습니다.
프로젝트의 결과 / 결론 :-비교적 단순한 앱의 시간 창을 깨뜨 렸습니다.-2 ~ 3 개월 동안 지속되어야했고, 거의 1 년 동안 지속되었지만 여전히 안정적 / 신뢰할 수 없습니다. 사용자 지정 노드 스택을 사용하여 5-10 일 만에 비슷한 데모 프로젝트를 만들었습니다. 클라이언트의 신뢰를 잃고 이제 사용자 지정 스택을 사용할 다른 팀과 함께 앱을 다시 만들고 있습니다. 시간 창을 깨고 그것을 작동 시키려고 노력하여 현금을 잃었습니다-너무 많은 초과 근무 원인이 제 건강에 반영되기 시작했습니다-모든 것을 가질 것을 약속하는 플랫폼 / 솔루션을 사용하지 않고 항상 관례를 따르십시오 / 시도 스택
첫 번째는 서버 다운 및 무작위 오류와 같은 플랫폼의 지속적인 지속적과 안정성 문제 였지만 모든 지속적인 문제가 해결 (2014 초반) 다음과 같은 문제가 남아 있습니다.
- 현재 추가 코드를 사용할 수 없습니다 (노드 서버 및 일부 모호한 lib로 작동시키는 방법이 있습니다)
- 한계는 터무니없고, 초당 50-60 API 요청 (또는 구독에 따라 그 이상)을 수행 할 수있는 확장 가능한 플랫폼으로, 스트레인 테스트를 시작하고 코드에 도달 할 때까지 그다지 낮지 언어를 사용합니다. 끊임없이 실패 할 것이다
- API 호출은 다음과 같이 측정됩니다. 서버 함수 호출 (Parse 작업) -1 회 호출, 데이터베이스 쿼리 -1 회 호출, 다른 쿼리 (더 복잡한 경우 고급 / 복잡한 쿼리 시스템이 설치되어 있지 않습니다) 데이터베이스는 의미하는 바를 곧 알게됩니다) -한 번의 호출, 1000 개 이상의 쿼리를 수행하는 경우 추측-다시 쿼리 등, 개수에 대한 쿼리 (별도의 쿼리로 수행해야 함)입니다. (수천 항목에 대한 근사치를 반환하는 경향이 있음)
- ~ 1000 개의 이상의 간단한 개체를 생성 / 저장하는 플랫폼 / 데이터베이스에 부담이됩니다. 더 가깝게 배치 당 20 개의 개체를 삭제합니다.)
- 대부분의 npm 패키지를 사용할 수 없습니다 (소스를 직접 포함하여 순수한 JS 패키지 만).
- Parse 포럼을 읽어 보면 사용자가 플랫폼의 기능 부족으로 Parse 팀을 계속해서 반대 / 로스팅하고 무작위 항목 및 무작위 항목 가져 오기 오기와 같은 임의의 논리 구현을 위해 점프해야하는 것을 볼 수 있습니다.
- Stripe 통합을 지원하지만 Paypal 또는 다른 지불 서비스를 사용하려는 경우 (우리는 Stripe보다 훨씬 우수한 국가 지원을 제공하므로 Paypal을 사용하기로 결정했습니다) Paypal 통합을 위해 Parse에서 작동하도록 할 수 없습니다. 별도의 서버를 사용하여 분리
- 사용자를 동기화하고 동시성 문제를 처리하는 쉬운 방법이 없습니다. 해킹과 재미있는 것입니다.
- 100 명 이상을 원하고, 1000 명 이상의 동시 사용자는 물론이고, 행운을 빕니다.
- 테이블의 항목 수를 알고 싶을 때 재미 있고 문서화하지 않고 완전히 우스꽝스러운 카운트 쿼리 호출에 대한 제한에 도달 할 수 있고 결국적인 숫자를 반환합니다.
- 모듈성은 플랫폼과 관련이 제한, 작업에서 호출하는 함수는 몇 초 (제 생각에는 7 초) 이상 지속될 수있는 쿼리 시간을 고려하면 더 복잡한 쿼리에서 많은 일이 있습니다. 복잡한 논리
- Cron 작업과 같은 작업을 할 수 있지만 15 분 이상 지속될 수 없습니다 (매우 매우 짧은 여러 쿼리와 같은 플랫폼의 성능이 낮기 때문에), 작업에 따라 2-3-4 개의 동시 작업으로 제한됩니다. 구독료 및 일정 시스템이 매우 제한적이거나 열악합니다 (예 : 코드에서 편집 할 수없고 매우 제한적이므로 해킹을 사용하여 하루에 정확히 2 번 또는 비슷한 작업을 수행해야합니다.) , 시간 절약 등을 볼 수 없습니다.)
- 서버에서 오류가 발생하면 완전히 오해의 소지가있을 수 있습니다. 포럼에서 확인하십시오. 내 마음 속에서 아무것도 기억할 수 없습니다.
- 푸시 알림은 정기적으로 20 ~ 30 분 정도 늦습니다.
임의의 예 : 데이터베이스에서 임의의 항목을 가져 오려는 경우 앱이이를 제공 할 작업을 호출하고 (1 API 호출), 작업이 데이터베이스를 쿼리하지만 먼저 두 번 호출해야합니다. 항목 수 (API 호출 1 회)를 가져온 다음 임의 항목을 가져 오기위한 두 번째 항목 (API 호출 1 회)을 가져옵니다. 이는 해당 기능에 대한 3 회의 API 호출이며, 초당 60 개의 요청으로 20 명의 사용자가 해당 호출을 할 수 있습니다. 요청 한도에 도달하기 전에 주어진 시간과 플랫폼이 불안정 해지기 전에, 앱 화면과 물건을 탐색하는 다른 사용자를 포함하면 이것이 어디로 가는지 알 수 있습니다.
페이스 북이 어떤 앱에도 그것을 사용하는 것을 언급 할 때마다 구입 한 것이 좋지 않을까요? 저는 3 가지를 제안합니다 :-첫째-Parse 녀석의 말을 듣지 마세요. 그의 플랫폼이기 때문에 그는 그것을 홍보
해야합니다. 확장 가능한 플랫폼이고 완전히 사용자 지정하고 싶지 않습니다. 테스트되고 신뢰할 수있는 Amazon Cloud 서비스 또는 이와 유사한 서비스를 선택합니다.-세 번째-서버 측 경험이있는 경우 플랫폼에서 멀리 떨어져 있습니다. 프로젝트의 백엔드 개발자라면 더 저렴할 것이며 결국 작업 솔루션을 얻게 될 것입니다.
나는 parse.com을 살펴보면서 하루를 보냈고 여기에 내가 발견 한 것을 기반으로 한 현재의 의견이 있습니다 (아직 SDK로 개발 한 경험이 아주 짧다는 점을 명심하십시오) ..
Parse.com은 분명히 매우 매력적인 긍정적 인 부분을 가지고있어서 내가 그것을 조사한 이유입니다. 그러나 토론을 위해 나는 그들의 웹 사이트에 모두 나열되어 있기 때문에 나는 비판적인 것에 집중할 것입니다. (이런 큰 문제를 해결하기 위해 parse.com을 잘 수행했습니다!) ...
- 회원 평가에서 Hipmunk는 제가 말하고 싶은 가장 큰 이름입니다. SDK의 데이터 부분을 사용하는 앱으로 나열됩니다. Hipmunk 개발자에게 접근하지 않고는 확실히 알 수는 없지만 parse.com 클라우드에 모든 데이터를 저장하는 것은 상상할 수 없습니다.
- 나열된 대부분의 앱을 시도하고 탐색 한 후. 서버 백엔드에 크게 의존하는 것은 실제로 눈에 띄지 않으므로이를 기반으로 parse.com을 사용하여 확장 성이 해결되었는지 여부를 알 수 없습니다.
- 웹 사이트는 40,000 개의 앱을 언급하고 있습니다. 앱 갤러리를 기반으로이 수치는 앱 스토어의 실제 라이브 프로덕션 앱이 아니라 사용자 기반의 앱 수를 기반으로한다고 생각합니다 (모르겠습니다). 많은 앱이 parse.com을 사용하는 경우 앱 갤러리에는 훨씬 더 큰 이름이 표시됩니다.
Parse.com은 매우 새로운 개념이며 가장 가까운 라이벌과도 매우 다릅니다. 따라서 그것이 얼마나 확장 가능하고 안정적인지 (그리고 나머지 모든 것)에 대한 구체적인 증거 없이는 프로젝트 개발자가 너무 많은 위험이 있기 때문에 프로젝트에 참여하는 것을 고려하기가 매우 어렵습니다.
비슷한 질문에 대한 내 답변에 대한 테스트를 실행 했으며 매우 빠를 수 있습니다. 그러나 결과는 구현 세부 사항에 따라 달라질 수 있습니다.
Parse / REST 호출을 만드는 네이티브 HTTP 스택을 사용하여 Android SDK를 Android와 비교 테스트 ...
테스트 세부 사항 :
테스트 환경-빠른 WIFI 연결을 통해 10 개월 된 휴대 전화의 최신 Android 버전.
(평균 파일 크기 = 80K 인 사진 63 장 업로드)
Android SDK를 사용하여 테스트 1 RESULT = 느린 성능
Android RESULT = VERT FAST를 통해 네이티브 REST 호출을 사용하여 테스트 2
-편집-여기에 관심이 있기 때문에 ....
http thruput, parse SDK (android) 및 성능과 관련하여 parse.com이 parse.android SDK에서 android asyncTask ()를 구현하는 방식에서 성능을 최적화하지 않았을 수 있습니다. 8 분 소요되는 작업 방법. parse.sdk에서 최적화 된 REST, DIY 프레임 워크에서 3 초 만에 완료 될 수 있습니다 (구현에 대한 자세한 내용은 링크 참조). 정말 모르겠습니다. 이러한 비교 테스트가 실행 된 이후 구문 분석이 SDK 구현을 수정하지 않은 경우 네트워크에서 실제 워크로드에 접근하는 작업을 수행하는 기본 SDK asnycTask 작업을 원하지 않을 것입니다.
Parse (및 유사한 SaaS)의 가장 큰 매력은 백엔드 개발 비용에서 수만 달러를 절약 할 수 있다는 것입니다. 백엔드가 웹 앱에서 가장 비용이 많이 드는 부분 인 경우가 많습니다. 것을 머리 통증은 갑자기 휙 .
Parse 및 대부분의 (모든) SaaS의 문제는 지역, 전력, 메모리, 대역폭, 확장 성, 임계 값, 경고 및 다양한 작업이 제어 할 수 없다는 것입니다.
Shopify와 동일합니다. 제품, 주문, 재고 및 미학을 포괄적으로 제어하지만 기계에 대한 제어는 전혀없는 훌륭한 Saa입니다. 따라서 오늘날의 SaaS는 godaddy와 크게 다르지 않습니다. 그들은 돈을 벌기 위해 항상 자신의 기계를 과도하게 판매하거나 최대로 사용합니다. 엉덩이를 걷어차는 성능에 정말로 관심이 있다면 갇혀 있습니다. 그런 수준의 서비스를 구매할 수도 없습니다.
AWS 콘솔만큼 강력하고 포괄적 인 것을 원합니다. 대부분의 기술자는 Heroku와 Parse가 모두 AWS에서 호스팅된다는 사실을 알고이를 수용합니다. 무슨 상관이야. 따라서 추가 된 서비스에 대해 더 많은 비용을 청구하되 사이트와 앱 및 사용자 경험을 고조시키는 중요한 하위 수준 도구에 대한 액세스를 거부하지 마십시오. 해당 Parse 직원에게 힌트.
여하튼, 질문에 대한 대답 :
Parse API는 간단한 JSON입니다. 따라서 Parse 애플리케이션이 예상하는 것과 동일한 JSON 형식으로 데이터를 펌핑 할 수 있습니다.
PFObject (iOS)를 활용할 수도 있습니다. 어느 시점에서 모든 고급 API는 공통 HTTP 요청 / 응답으로 이동합니다. REST의 일반성의 좋은 점은 상용화를 의미합니다. http, url, strings 및 utf와 같은 것. 여기에는 펑키 오브가 없습니다.
Parse는 특히 사용자 관리에 대한 도우미 기능 / 기능으로 시작하는 것이 좋습니다. 하지만 문제가 발생하기 시작했습니다 ..
긴 실행 / 핑 시간, 하위 쿼리를 포함한 1000 개의 개체 제한, 유럽에 데이터 센터 없음 (내가 아는 한)
성능 및 안정성 문제를 분류 할 수 있다면 신성한 플랫폼이되었을 것입니다. 어떻게 든 개발 한 것을 후회하지만 5000 줄 이상의 코드를 넣었으므로 계속 진행할 것입니다.
DEV 앱과 PROD 앱 환경을 분리하고 일종의 감독 후에 만 PROD 앱을 허용하거나 유료 고객 만있는 다른 환경을 만들어야할까요?
우리는 2014 년에 $ 20 / 월 서버가 최적화되지 않은 웹 사이트 (홈페이지의 캐시되지 않은 db 쿼리 60 개)를 처리 할 수 있으며 월 100 만 번 방문합니다. Parse에서는 그렇게 어렵지 않습니다!
특히 iOS / Android 개발자가 DB / API 백엔드를 직접 구축하는 방법을 모르는 경우 앱 프로토 타이핑에 문제가 없습니다.
다음보다 더 복잡한 쿼리가 필요한 로직을 사용하여 애플리케이션을 개발하는 경우에는 전혀 문제가 없습니다.
SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100;
관련 쿼리 및 내부 조인이 Parse에 없습니다. 그리고 필요한 경우 320,000 레코드를 업데이트 / 제거하는 행운을 빕니다 (지금 작업중인 번호입니다).
정말 유용한 유일한 것은 SDK를 통해 사용자를 처리하는 것입니다. Django 및 DRF / Tastypie를 사용하여 iOS / Android 앱을 통해 사용자를 처리 / 생성하는 방법에 대한 좋은 문서 나 자습서를 찾을 수 있다면 회사에서 개발중인 모든 것을 즉시 변환하여 사용합니다.
참조 URL : https://stackoverflow.com/questions/11283729/how-scalable-is-parse
'ProgramingTip' 카테고리의 다른 글
| Meteor :없는 mongo 종료 코드 100 (0) | 2020.12.31 |
|---|---|
| 대용량 파일 복사 중 진행률 (Copy-Item & Write-Progress?) (0) | 2020.12.31 |
| django 관리자 생성 후 사이트 일치 쿼리 가져 오기 오기가 존재하지 않음 발생 오류 (0) | 2020.12.31 |
| Android 날짜 선택기에서 미래 날짜를 선택하는 방법 (0) | 2020.12.31 |
| 신속하게 배열을 JSON 문자열로 변환 (0) | 2020.12.31 |