鍵值存儲庫
您好，對於你的遇到的問題，我很高興能為你提供幫助，我之前也遇到過喲，以下是我的個人看法，希望能幫助到你，若有錯誤，還望見諒！。鍵值對存儲是資料庫最簡單的組織形式。基本上全部的編程語言都帶有應用在內存中的鍵值對存儲。C++STL的映射容器（map container）和Java的HashMap以及Python的字典類型都是鍵值對存儲。鍵值對存儲通常都有例如以下介面：
Get( key ): 獲取之前存儲於某標示符「key」之下的一些數據，或者「key」下沒有數據時報錯。
Set( key, value ): 將「value」存儲到存儲空間中某標示符「key」下。使得我們能夠通過調用同樣的「key」來訪問它。
假設「key」下已經有了一些數據，舊的數據將被替換。
Delete( key ): 刪除存儲在「key」下的數據。
大部分低層實現都是使用哈希表或者某種自平衡樹（比如B-樹或者紅黑樹）。有時候數據太大而不裝不進內存，或者必須維持數據謹防系統由於未知原因而崩潰。在這些情況下。就必須使用到文件系統。
鍵值對存儲是NoSQL運動的一部分。NoSQL將全部不使用基於關系型資料庫概念的資料庫系統組合在一起。
維基網路上的NoSQL詞條非常好的總結了這些資料庫的特徵。
不使用SQL查詢語言
可不全面支持ACID（原子性、一致性、隔離性、持久性）。
可提供分布式、容錯強的結構非常感謝您的耐心觀看，如有幫助請採納，祝生活愉快！謝謝！
2. 鍵值資料庫為什麼無法存儲結構化信息
鍵值資料庫不兼容
鍵值資料庫是一種非關系資料庫，它使用簡單的鍵值方法來存儲數據。鍵值資料庫將數據存儲為鍵值對集合，其中鍵作為唯一標識符。鍵和值都可以是從簡單對象到復雜復合對象的任何內容。鍵值資料庫是高度可分區的，並且允許以其他類型的資料庫無法實現的規模進行水平擴展。 例如，如果現有分區填滿了容量，並且需要更多的存儲空間，Amazon DynamoDB 就會將額外的分區分配給表。
3. 關於資料庫存儲鍵值對的問題
這是前端（應用端）和後端（服務端）的問題，這個應該是每個用戶的單獨配置，那麼應該放在前端而是不是放在後端，如果放在後端，那麼每個用戶都要讀取，那麼體驗一定不好。
對於前端來說，只要加一個「配置文件」（其實就是一段代碼）就可以，然後通過服務端的程序讀取這個「配置文件」，就知道相應的順序了，這樣總比，連通伺服器讀取相應的表，來的要快。
如果非要用資料庫解決，那我們做一個假設，有100項，某人將所有的項目變成了從後往前倒著寫的，也就是第100項與第1項位置互換，第99項與第2項位置互換，這樣，那麼最後是第50項與第51項調換，也就是100項完全變換了位置，那麼不管你怎麼存儲，怎麼讀取，這些項都必須全部保存起來，因為每一項的順序都變了，所以這個方案並不是十分好。
當然，如果非要這么做的話，那麼有一個稍微簡單一點的辦法，不過也需要前端的配合而且，很可能出現徵用的情況，使用效果也不一定能太好。
我的辦法是建立userid 10001 10002 10003 這樣一張表，說白了就是一張以默認順序MoleID（個人覺得這個可能是你的表頭代碼，如果不是不要介意）為欄位名的表，然後每條用戶id，對應一組編號比如（默認編號為1,2,3,4）：
userid 10001 10002 10003 10004
1 4 3 1 2
2 2 1 4 3
3 1 2 3 4
類似於這樣就能直接得到用戶的編號順序了，不過這種還是不如在前端一個配置文件來的舒服（用戶修改配置文件後，服務端也會備份（類似於上表這種也可以作為一個客戶端配置的備份），但是這種備份比直接修改資料庫要要省事不少，至少節省了資料庫的資源），而且可能出現徵用的問題，比如兩個人或更多的人同時修改代碼，那麼一張表不可能讓這么多人同時update，肯定要出現徵用，那麼服務體驗就不會太好（備份的話，不用那麼及時，所以徵用的可能性不大，即使出現也是發生在後端，用戶的體驗並沒有什麼影響）。
以上均為個人理解，共同探討。