鍵值資料庫

適用案例

現在講幾個適合使用鍵值資料庫的情況。

1 存觸會話資訊
通常來說，每一次網路會話都是唯一的，所以分配給它們的session id 值也各不相同。如果應用程式原來要把session id 存在磁碟上或關係型資料庫中，那麼將其遷移到鍵值資料庫之後， 會獲益良多， 因為全部會話內容都可以用一條PU T 請求來存放，而且只需一條GET 請求就能取得。由於會話中的所有資訊都放在一個物件中，所以這種" 單請求操作" (single-request operation ) 很迅速。許多網路應用程式都使用像Memcached 這樣的解決方案。如果"可用性" 較為重要，可使用Riak .
2 使用者配置資訊
幾乎每位使用者都有userld 、usemame 或其他獨特的屬性， 而且其配置資訊也各自獨立， 諸如語言、顏色、時區、訪問過的產品等。這些內容可全部放在一個物件裡，以便只用一次GET 操作即獲取某位使用者的全部配置資訊。同理，產品資訊也可如此存放。
3 購物車資料

電子商務網站的使用者都與其購物車相繫結。由於購物車的內容要在不同時間、不同瀏覽器、不同電腦、不同會話中保持一致，所以可把購物資訊放在value 屬性中，並將其繫結到userid 這個鍵名上。此類應用程式最宜使用Riak 叢集了。

不適用場合
鍵值資料庫在某些場合下並不是最佳方案。
1 資料間關係
如果要在不向資料集之間建立關係，或是將不同的關鍵字集合聯絡起來， 那麼即使某些鍵值資料庫提供了"連結遍歷"等功能，它們也不是最佳選擇了。
2 含有多項操作的事務
如果在儲存多個鍵值對時，其中有一個關鍵字出錯，而你又需要復原或回攘其餘操作，那麼鍵值資料庫就不是最好的解決方案。
3 查詢資料
如果要根據鍵值對的某部分值來搜尋關鍵字，那麼鍵值資料庫就不是很理想了。
我們無法直接檢視鍵值資料庫中的值，除非使用某些類似Riak Search 的產品或是像Lucene、Solr這樣的"檢索引擎" ( indexing engine) 。
4 操作關鍵字集合
由於鍵值資料庫一次只能操作一個鍵，所以它無法同時操作多個關鍵字。假如需要操作多個關鍵字，那麼最好在客戶端處理此問題。


文件資料庫
適用案例
1 事件記錄
應用程式對事件記錄各有需求。在企業級解決方案中，許多不同的應用程式都需要記錄事件。文件資料庫可以把所有這些不同型別的事件都存起來， 並作為事件儲存的"中心資料庫" (central data store) 使用。如果事件捕獲的資料型別一直在變，那麼就更應該用文件資料庫了。可以按照觸發事件的應用程式名"分片飛也可以按照order processed 或customer_logged e 等事件型別"分片"。
2 內容管理系統及博窯平臺
由於文件資料庫沒有"預設模式" ( predefined schema) ， 而且通常支援JSON 文擋，所以它們很適合用在"內容管理系統" (content management system ) 及網站釋出程式上，也可以用來管理使用者評論、使用者註冊、使用者配景和麵向Web 文件( web document ) 。
3 網站分析與實時分析
文件資料庫可儲存實時分析資料。由於可以只更新部分文件內容，所以用它來儲存"頁面瀏覽量" ( page view ) 或" 獨立訪客數" (unique v isitor ) 會非常方便，而且無需改變模式即可新增度量標準。
4 電子商務應用程式
電子商務類應用程式通常需要較為靈活的模式，以儲存產品和訂單。同時，它們也需要在不做高戚本資料庫重構及資料遷移(參見1 2 .3 節)的前提下進化其資料模型。 不適用場合

某些場合文件資料庫井非最佳方案。
1 包含多項操作的複雜事務
文件資料庫也許不適合執行"跨文擋的原子操作" (atomic cross-document operation) ，然而像RavenDB 等文件資料庫其實也支援此類操作。
2 查詢持續變化的聚合結構
靈活的模式意味著資料庫對模式不施加任何限制。資料以"應用程式實體"(application entity) 的形式儲存。如果要即時查詢這些持續改變的實體，那麼所用的查詢命令也得不停變化( 用關係型資料庫的術語講，就是:用JOIN 語句將資料表按查詢標準連線起來時，待連線的表一直在變)。由於資料儲存在聚合中， 所以假如聚合的設計持續變動，那麼就需要以" 最低級別的粒度" ( lowest level of granularity ) 來儲存聚合了， 這實際上就等於要統一資料格式了。在這種情況下，文件資料庫也許不合適。

列族資料庫

適用案例
現在討論幾個適合用列族資料庫解決的問題。
1 事件記錄
由於列族資料庫可存放任意資料結構，所以它很適合用來儲存應用程式狀態或執行中遇到的錯誤等事件資訊。在企業級環境下，所有應用程式都可以把事件寫入Cassandra 資料庫。它們可以用appname: timestamp (應用程式名: 時間戳〉作為行鍵，並使用自己需要的列。由於Cassa ndra 的寫人能力可擴充套件，所以在事件記錄系統中使用它效果會很好(參見圖1 0 .2 )。
2 內容管理系統與博窯平臺
使用列族，可以把博文的"標籤" (tag) 、"類別" (catelog〉、"連結" ( link ) 和"mckback" 等屬性放在不同的列中。評論資訊既可以與上述內容放在同一行，也可以移到另一個"鍵空間"。同理，部落格使用者與實際博文亦可存於不同列族中。
3 計數器
在網路應用程式中，通常要統計某頁面的訪問人數並對其分類，以算出分析資料。
此時可使用CounterColum nType 來建立列族。
CREATE COLUMN FAMILY visit counter
WITH default_validation_class=CounterColumnType
AND key--va l Ida t lorIECla sszUTF8Type AND c。mpara t。r=UTF8Type J
建立好列族後，可以使用任意列記錄網路應用程式中每個使用者訪問每一頁面的次數。
INCR visit counter[ 'mfowler ' 1 [home) BY 1 ;
INCR visit counter[ 'mfow1er '] (products] BY 1 ;
I NCR visit counter['mfowler') (contactus) BY 1;
也可以用C QL 增加計數器的值:
UPDATE visi t counter SET home = home + 1 WHERE KEY= 'mfowler '
4 限期使用
我們可能需要向用戶提供試用版，或是在網站上將某個廣告條顯示一定時間。這
些功能可以通過" 帶過期時限的列" ( expiring column ) 來完成。這種列過了給定時限後，就會由Cassandra 自動刪除。這個時限叫做TTL (Time To Live ，生存時間)，以秒為單位。經過TTL 指定的時長後，這種列就被刪掉了。程式若檢測到此列不存在，則可收回使用者訪問許可權或移除廣告條。

SET Customer( ' mfowler ' ) ( ' demo access ' ) = ' allowed ' WITH ttl=2592000;

不適用場合
有些問題用列族資料庫來解決並不是最佳選擇，例如需要以" ACID 事務"執行寫人及讀取操作的系統。如果想讓資料庫根據查詢結果來聚合資料( 例如SUM (求和〉或AVG ( 求平均值) ) ， 那麼得把每一行資料都讀到客戶端， 並在此執行操作。在開發早期原型或剛開始試探某個技術方案時，不太適合用Cassandra. 開發初期無法確定查詢模式的變化情況，而查詢模式一旦改變，列族的設計也要隨之修改。這將阻礙產品創新團隊的工作並降低開發者的生產能力。在關係型資料庫中，資料模式的修改成本很高，而這卻降低了查詢模式的修改成本; Cassandra 則與之相反，改變其查詢模式要比改變其資料模式代價更高。

圖資料庫

適用案例
接下來講一些適合使用圖資料庫的用例。
1 互聯資料
部署並使用圖資料庫來處理社交網路非常高效。社交圖裡並不是只能有"朋友"這種關係，例如也可以用它們表示僱員、僱員的學識， 以及這些僱員與其他僱員在不同專案中的工作位置。任何富含連結關係的領域都很適合用圖資料庫表示。假如同一個數據庫含有不同領域(像社交領域、空間領域、商務領域等)的領域實體，而這些實體之間又有關係，那麼圖資料庫提供的跨領域遍歷功能，可以讓這些關係變得更有價值。
.2 安排運輸路線、分派貨物和基於位置的服務
投遞過程中的每個地點或地址都是一個節點， 可以把送貨員投遞貨物時所經全部節點建模為一張節點圖。節點間關係可帶有距離屬性，以便高效投遞貨物。距離與位置屬性也可用在名勝圖(graph of places of interest ) 中， 這樣應用程式就可向使用者推薦其附近的好餐館及娛樂場所了。還可將書店、餐館等銷售點( point of sales) 做成節點， 當用戶靠近時通知他們，以提供基於位置的服務。
3 推薦引擎

在系統中建立節點與關係時， 可以用它們為客戶推薦資訊，例如"您的朋友也買了這件產品"或"給這些貨品開發票時，通常也要為那些貨品一併開票"。還可以用它們向旅行者提議: 來巴塞羅那旅遊的人一般都會去看看安東尼· 高迪@ 所設計的建築。用圖資料庫推薦資訊時，有個副作用值得注意: 隨著資料量變多，推薦資訊所用的節點及關係數也激增。同一份資料可以挖掘出不同資訊。例如，既可以從中看出客戶總是將其與哪些產品一併購買，也可以查出與此產品一併開發票的其餘產品。若兩者不匹配，則可發出警示。因資料庫與其他" 推薦引擎" ( recommendation engine ) 一樣，也可以根據關係間的模式偵測交易欺詐( fraud in transaction ) 。

不適用場合
圖資料庫在某些情形下也許不適用。在更新全部或某子集內的實體時就是這樣。比如，在某個" 資料分析解決方案" (analytics solution ) 中， 只要一個屬性變了，全部實體就都得更新。此時圖資料庫的效果就不理想了，因為投有哪個簡單的操作能一次性改變所有節點中的某個屬性。即便資料模型適合問題領域， 某些圖資料庫可能也無法處理那麼大的資料盤， 尤其在執行"全域性圖操作" (global graph operation，涉及整張圖的操作)時更是如此。