我們正在考慮將parse.com用作我們的數據庫後端，目前我們正在尋找用於解析的Java SDK。據我所知，有兩個，一個是Almonds（https://bitbucket.org/jskrepnek/almonds），另一個是Parse的官方Android SDK（https://parse.com/downloads/android/Parse/latest）。在Java服務器中使用Parse.com Android SDK而不是Android應用
我們打算從基於Java的服務器（Jetty）撥打電話給Parse，並且我們沒有Android應用程序或計劃在可預見的未來有一個應用程序。
我傾向於Android SDK，因爲它是官方的。但是，我主要關心的是Jetty服務器在多線程環境中的性能，這可能會啓動許多請求來同時解析相同或不同的數據集。
我的另一種選擇顯然是使用他們的REST API並編寫我自己的實用程序來封裝函數。如果有人有此經驗並願意與我們分享，我將非常感謝。謝謝！
我在2014年1月寫了這篇文章。Parse.com正在迅速發展並擴展他們的平臺。我不能說這些信息將會持續多長時間，或者我的觀察將持續多長時間。
這就是說...
第一。 Parse.com通過交易數量收費。許多小型交易可能會導致應用程序所有者的成本更高。我們正在使用Parse.com的專業計劃。臨計劃有這些限制：每月
如果你有4500個用戶，每個發送125個HTTP請求Parse.com每天，那麼你已經在每30天查看16,850,000個請求。 Parse.com還提供稱爲Parse Enterprise的更高級別的服務。有關此計劃的詳細信息未發佈。
其次，Parse.com的預期目的是成爲移動應用的輕量級後端後端。我相信Parse.com是一個非常好的移動後端即服務（MBaaS - 鏈接到關於此主題的Forrester文章）。
我正在使用Parse.com構建服務器端應用程序。我使用REST界面，雲功能和雲作業。在我看來，Parse.com是一個笨拙的應用服務器。它不公開強大的工具來操縱數據。例如，刪除表的唯一方法是單擊Parse的Web數據瀏覽器中的按鈕。另一個例子是Parse在第一次保存對象時設置了一個屬性的類型。如果數據類型在對象中發生變化，例如從字符串到指針，Parse.com將拒絕保存該對象。
雲功能編程模型建立在Node.js上。複雜的業務邏輯將迅速將您置於回調地獄中，因爲所有數據庫查詢和保存操作都是異步的。也就是說，當你保存或查詢一個對象時，你可以手動解析一個函數並且說「保存/查詢完成時，運行這個函數」。這對LISP程序員來說可能很自然，但對於在Java或.Net上提出的OO程序員而言則不然。如果您打算爲您的應用程序編寫Cloud Code，請注意這一點。當我開始編寫雲端函數時，我的生產力大打折扣。
我在Parse.com遇到的最大挑戰是往返時間。這裏有一些非正式的基準測試：
通過REST API獲取一個對象已經相當一致的RTT的800ms的
ICMP被阻塞，但敲門時間需要400-800毫秒，具體取決於一天。
Parse.com處於Northern Virginia Amazon的數據中心。我用Ookla的Speedtest來估計我的延遲。在Ashburn訪問里士滿商務中心服務器（75.103.15.244）時，我的ping時間爲95ms。 D.C.中的一臺服務器給了我97ms的ping時間。 200毫秒的互聯網開銷不是問題。
雲功能執行的查詢或保存操作越多，響應時間就越長。具有一個或兩個查詢或保存操作的雲功能具有1到3秒的RTT。具有多個查詢和保存操作的雲功能的RTT在3到10秒之間。
15秒後發送給Parse.com的HTTP請求超時。我有一個用於測試的雲功能，用於刪除數據庫中的所有對象。這個雲功能可以在超時之前刪除幾百行。我將雲端功能轉換爲雲端作業，因爲作業最多可以運行15分鐘。作業刪除400-500個對象，需要30-60秒才能完成。作業狀態只能通過Web瀏覽器獲得。我必須創建一個輕量級的工作狀態系統，以便其他開發人員可以查詢他們的工作狀態。
解析的最佳使用案例是iPhone開發人員編寫的一款遊戲，需要存儲用戶的高分，但對服務器一無所知。使用分析功能強大的地方。
難道你不能試試看看它是如何執行許多併發請求？ – Brennan