最佳DynamoDB實施結構

我正在處理一個保存應用程序，基本上用戶可以轉到一篇文章並單擊保存將其存儲在他的配置文件中。 Application不使用關係數據庫，而是使用dynamodb。每篇文章都有特定類型的文章。目前結構被用於這種應用的方法是：最佳DynamoDB實施結構

user-id [string][DynamoDBHashKey] 
type-of-article [string] [DynamoDBRangeKey] 
json [string]

用戶ID是用戶的唯一標識符，類型的-製品是以及..文章，和JSON的類型是所有以json格式保存的文章。 JSON格式之中：

[{article-id: timestamp}, {article-id: timestamp}] 
    Article #1^   Article #2^

文章-id爲（再次）物品唯一的標識符和時間戳是儲存該文章時的時間戳。

注意這是在dynamodb開始支持json文檔作爲Map和Lists之前完成的。代碼不是我的..它已經完成..

因此，當應用程序需要刪除保存的文章它調用發電機讓json修改json然後再存儲它。什麼時候添加一篇新文章會做同樣的事情。現在，當我想顯示按時間戳排列的所有文章時，出現了一個問題。我不得不打電話來獲取所有類型，並將它們合併到字典中進行排序。（在用戶配置文件中，我需要顯示所有保存的文章，不管是什麼類型，排序）現在，應用程序需要超過700或900毫秒的響應時間。

我個人並不認爲這是解決這個問題的最好方法。所以我正在考慮重寫前面的代碼來實現dynamodb（List和Maps）的新功能。現在我在dynamodb結構的想法是這樣的：

user-id [string] [DynamoDBHashKey] 
saved-articles [List] 
    article-type_1 
     article_1 [Map] {id: article-id, timestamp: date} 
     article_2 [Map] {id: article-id, timestamp: date} 
    article-type_2 
     article_1 [Map] {id: article-id, timestamp: date}

但我是比較新的dynamodb，我做了一些測試代碼中使用列表和地圖存儲在這個發電機。我使用低級別的API和對象持久性模型做了它。

現在，我的問題是：這是一個更好的方法，或者如果不是爲什麼？什麼是更好的方法。

這種方式我想我可以使用低級別的Api來獲取文章類型＃2的已保存文章。或者，如果我需要他們，我只是把它全部叫完。

來源

2014-11-06 vicgonzalez25

我會堅持一個更像NoSQL的解決方案。對於NoSQL數據庫，如果您有嵌套數據模型和/或更新現有記錄，那麼這些通常是您的數據模型可以優化的指標。我真的看到了你的應用程序使用的兩個對象，'用戶'和'文章'。我會避免嵌套數據模型，並通過執行以下操作更新現有記錄：

「用戶」表

用戶ID作爲哈希鍵

「文章」表

文章ID爲散列鍵
時間戳作爲範圍鍵
用戶ID
物品類型和任何其它屬性（在下文中描述的全局二級索引使用）將是非鍵屬性

也就會有一個全球二級索引在項目表，將允許你搜索的用戶ID的文章，這看起來像什麼（假設你希望用戶的文章按日期排序）：

用戶ID作爲哈希鍵
時間戳範圍鍵
文章編號爲預計屬性

在這種模式下，你永遠需要回去和編輯現有記錄，你只需要添加那些「編輯」作爲新的記錄的記錄，你拿最新的時間戳作爲當前版本。

NoSQL要記住的一件事是存儲空間便宜，讀取便宜，但編輯現有記錄通常是昂貴的和不受歡迎的操作。

來源

2014-11-10 05:25:39 dvdmmc

最佳DynamoDB實施結構

回答

相關問題