解析本地數據存儲性能

Question

我正在使用解析作爲雲存儲，並結合本地數據存儲進行一般訪問。我發現查詢本地數據存儲需要比我預期的要長得多。使用數據填充表格或更新圖形視圖時，這一點尤爲明顯。 Coredata中的等效函數幾乎是瞬時的，結果非常好。雖然我不指望coredata的性能，但它比我預期的離線訪問要慢得多，我想知道我是否做錯了什麼？

下面是一個例子查詢：

PFQuery *query = [PFQuery queryWithClassName:LOCATION_OBJECT]; 
[query fromLocalDatastore]; 
[query whereKey:MESSAGE_TO_FIELD equalTo:user.username]; 
[query orderByDescending:CREATED_FIELD]; 
NSLog(@"Query started"); 
NSArray* res = [query findObjects]; 
NSLog(@"Query finished, found %lu objects", (unsigned long)[res count]); 

在2015年iPad的迷你執行排序定時是我看到如下：

2015-06-16 18:56:38.883 app[1744:1668474] Query started 
2015-06-16 18:56:38.885 app[1744:1668474] Warning: A long-running operation is being executed on the main thread. 
Break on warnBlockingOperationOnMainThread() to debug. 
2015-06-16 18:56:39.177 app[1744:1668474] Query finished, found 17 objects 

我也明白，分析是提供遠遠超過只是一個數據庫，但這個查詢需要0.292秒，這似乎是一個年齡。對於我的應用程序，我經常在用戶瀏覽屏幕時使用這種操作。隨着coredata的結果非常好，解析滯後非常明顯。值得一提的是，在模擬器上的結果是相似的。當你做這種事情時警告解析問題並不令人鼓舞，但無論如何，我的問題有兩個：

1）我是否錯過了Parse中的任何性能調整/設置？ 2）有其他使用Parse的人是否找到類似的表現或有任何建議？

此時，看起來我需要在應用程序中使用coredata並編寫自己的例程來將數據推送到Parse的雲，這比我所期望的要多得多。

謝謝你的時間。

更新30Jun15

感謝您的意見，按照這些意見，這裏是從做解析它要你做的方式例如性能。與以前一樣，與coredata相比，表現仍然很差。示例代碼：

PFQuery *query = [PFQuery queryWithClassName:LOCATION_OBJECT]; 
[query fromLocalDatastore]; 
[query whereKey:MESSAGE_TO_FIELD equalTo:user.username]; 
[query orderByDescending:CREATED_FIELD]; 
NSLog(@"Query started ... "); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    NSLog(@"Query finished ... "); 
    if(!error) 
     NSLog(@"Found %lu message records in local datastore", (unsigned long)[objects count]); 
    else 
     NSLog(@"Parse error pulling messages from datastore: %@ %@", error, [error userInfo]); 
}]; 

性能在同一ipad公司：

2015-06-30 10:32:09.633 MvBii[205:5172] Query started ... 
2015-06-30 10:32:09.948 MvBii[205:5172] Query finished ... 
2015-06-30 10:32:09.948 MvBii[205:5172] Found 100 message records in local datastore 

查詢需要0.315秒。現在，和以前一樣，我並不是說這本身就不好，可能對於很多應用程序來說這很不錯，但它比coredata差幾個數量級，而且對我的應用程序來說太慢了。當用戶在屏幕上瀏覽圖形時，由於此查詢而繪製圖形，並且我無法使用解析來快速更新屏幕，以響應用戶輸入。使用coredata的結果是非常好的。

我的主要問題是這個查詢時間是否符合其他人的經驗？我想知道我的應用程序或數據集是否有什麼特殊之處？數據集不大（< 200項），解析對象只是字符串和整數。我仍然真的想爲它提供的所有其他設施使用Parse。也許這只是我的期望已經關閉，但對於基本查詢來說似乎很長時間。

Answer 1

解析現在是開源的，所以我對此進行了更深入的研究。這是我的發現。

解析構建一個按順序執行的順序執行的任務隊列。這與請求的形式無關（前臺，後臺或帶回調的背景）。任務從隊列中被處理，本質上需要大約幾百毫秒才能完成任務，爲任務創建一個線程，然後執行所述任務。請注意，列表中的下一個任務在上一個任務完成之前不會處理。因此，如果您推動大量任務進行快速解析，那麼這些任務將排隊等待，您將看到時間隨着任務數量的增加而線性增長。這裏是一些實驗代碼：

PFQuery* query = [PFQuery queryWithClassName:ANNOTATION_OBJECT]; 
[query fromLocalDatastore]; 
[query orderByAscending:CREATED_FIELD]; 
NSLog(@"Query 1 started"); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    if (!error) 
     NSLog(@"Query 1 finished"); 
}]; 
query = [PFQuery queryWithClassName:ANNOTATION_OBJECT]; 
[query fromLocalDatastore]; 
[query orderByAscending:CREATED_FIELD]; 
NSLog(@"Query 2 started"); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    if (!error) 
     NSLog(@"Query 2 finished"); 
}]; 
query = [PFQuery queryWithClassName:ANNOTATION_OBJECT]; 
[query fromLocalDatastore]; 
[query orderByAscending:CREATED_FIELD]; 
NSLog(@"Query 3 started"); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    if (!error) 
     NSLog(@"Query 3 finished"); 
}]; 

所以3個查詢被推送快速連續解析。他們排隊，以便查詢3需要3倍的時間才能完成的查詢1

2015-09-23 14:29:28.419 MvBii[257:59781] Query 1 started 
2015-09-23 14:29:28.420 MvBii[257:59781] Query 2 started 
2015-09-23 14:29:28.421 MvBii[257:59781] Query 3 started 
2015-09-23 14:29:28.658 MvBii[257:59781] Query 1 finished 
2015-09-23 14:29:28.854 MvBii[257:59781] Query 2 finished 
2015-09-23 14:29:29.011 MvBii[257:59781] Query 3 finished 

對於我的應用程序，幾百毫秒的查詢時間正要確定，但作爲用戶導航的請求將堆積起來意味着排隊結束的人需要很長時間。這不是不合理的解析，但應該意識到這是它的表現。如果在此任務中間存在銷釘或保存，則查詢將延遲銷釘或保存時間的長度。這可能是幾秒鐘。

Parse提供了很多免費的功能，請注意，如果您連續快速請求很多，您可能會看到一些性能問題，這取決於您的應用和您的需求。