1
我們嘗試將Titan（1.0.0版本）與DynamoDB後端一起使用，就像我們的推薦系統引擎一樣。我們有一個龐大的用戶數據庫與他們的關係。它包含大約350萬用戶和大約20億用戶之間的關係。 這裏是我們用來創建模式Titan + dynamodb遍歷後端性能
https://gist.github.com/angryTit/3b1a4125fc72bc8b9e9bb395892caf92
正如你所看到的，我們使用一個綜合指數，以尋找穿越啓動速度快，5邊的類型和一些屬性點的代碼。
在我們的案例中，用戶可以擁有非常多的邊緣。每個可以有數萬個邊緣。
這裏是我們用來提供在線
https://gist.github.com/angryTit/e0d1e18c0074cc8549b053709f63efdf
的穿越作品非常慢的問題建議的代碼。 這一個
https://gist.github.com/angryTit/e0d1e18c0074cc8549b053709f63efdf#file-reco-L28
tooks 20 - 30秒的情況下，當用戶具有約5000 - 6000的邊緣。
我們DynamoDB的表有足夠的讀/寫能力（我們可以從消費比1000個單位提供的能力較低的CloudWatch看到。）
這裏是我們的泰坦
的配置https://gist.github.com/angryTit/904609f0c90beca5f90e94accc7199e5
我們試圖在最大內存和大實例（r3.8xlarge）的Lambda函數中運行它，但結果相同...
我們是在做錯什麼或者在我們的情況下是正常的嗎？
謝謝。
pantalohnes正確使用以頂點爲中心的索引。此外，您的查詢正在查找'has（USER_LABEL，USER_ID_PROPERTY，userId）'，但複合索引不受標籤限制。嘗試在[定義索引]（https://gist.github.com/angryTit/3b1a4125fc72bc8b9e9bb395892caf92#file-schema-L25-L29）時包括'indexOnly（USER_LABEL）'。 http://s3.thinkaurelius.com/docs/titan/1.0.0/indexes.html#_label_constraint –