也有可能的是，我們可以設計一個服務，這個服務需要多種數據庫支撐。例如，我們可以創建一個使用鍵值存儲模式作為索引的酒店服務，在酒店名稱和ID之間實現映射，而存將關于酒店的描述性數據存儲在Cassandra中。

注意，名稱映射到ID可以在Cassandra中采用規范化的設計方法去實現，其中一個單獨表去維護名稱至ID的映射關系。這使用了更多的存儲空間，但降低了管理單獨鍵值存儲的操作復雜性。

這是我推薦的做法-?針對某個微服務，只要可行，就應該堅持使用單一數據模型（數據庫）。如果你發現一種情況，認為單個服務需要兩個不同數據庫支撐，那么請考慮該服務的粒度是否可能變得太大。你可能需要考慮將該服務拆分為較小的服務。

混合持久化局限性的權衡

混合持久化的主要缺點在于支持多種技術的成本，無論是在最初的開發階段和將來的運營方面。

主要的開發成本，是在需要培訓每個開發人員去掌握每個新的數據庫技術。這是非常重要的，尤其是在開發人員頻繁流動團隊中。

另一個成本是支持多個數據庫的操作成本。這會成為一個問題，尤其是當數據庫是集中管理，并且團隊必須在多種技術的掌握上維持高水平，但這在DevOps環境下，該問題并不會太突出，因為開發團隊需要支持他們在生產環境中選擇的數據庫。

多模型數據庫(Multi Model Databases)

作為另外的選擇方案或混合持久化模式的補充， 數據庫廠商已經開始建立和推廣多模型的數據庫。術語“模型”指的是數據存儲所提供的核心抽象，如表（關系和非關系）、列存儲、鍵值、文檔或圖。我們可以將一個多模型應用程序看作一個使用多個數據存儲類型的應用程序，而多模型數據庫是支持多個抽象模型的數據庫。

DataStax企業版（DSE）是多模型數據庫的典型例子，它核心支持Cassandra的分區行存儲（表格）模型，同時也支持基于在其之上的圖的抽象層（DSE圖）。DSE在核心模型之上構建對應的鍵值和文檔模型也是很簡單的，如下圖所示。這樣，我們可以修改上面的混合持久化的方法，從而利用一個基礎數據庫引擎為我們所有的服務提供對應的服務，而使用單獨的Cassandra keyspaces在不同服務擁有的數據間維護清晰的邊界。

下面是它能實現的功能：

表格：我們主要的應用服務A可以通過Cassandra的查詢語言（CQL）直接和DSE的數據庫打交道。

鍵值對：雖然Apache和Cassandra的分布式版本DataStax都沒有提供明確的鍵值對API，但是象服務B可以通過表設計去支持單個鍵值和列的方法，去訪問
Cassandra，例如：

CREATE TABLE hotel.hotels (key uuid PRIMARY KEY,value text); // 或者選擇blob類型

文檔型：Cassandra通過使用JSON文件支持文檔型風格的數據，這可以用在服務C中。注意因為Cassandra需要針對表定義schema模式，所以不能插入新增任意的JSON列，這是一個可能通常和文檔型數據庫有關的特性。

圖：對于象服務D那樣相關度很高的數據，DSE的圖是一個高度可擴展的圖形數據庫，它構建于DSE數據庫之上。DSE圖支持來自Apache tinkerpop項目中強大的功能和表現力的Gremlin API。

多模型數據庫的優點和限制

在考慮是否投資使用多模型數據庫（或你已經在使用的數據庫的多模型的特性）時，你要考慮我們前文討論的關于混合持久化中，同樣的開發和運營成本的問題。

使用多模型數據庫可以讓運營變得簡單。即使不同的開發團隊使用不同的API和不同的交互模式和后端數據庫平臺打交道，我們也只需要管理一個平臺而已，從而提高了效率。

在選擇多模型數據庫時要考慮的一個問題是如何支持各種模型。一種常見的方法，是基于單一的原生的基礎模型的數據庫引擎，而其他模型都是構建在其之上。分層數據模型更能展現底層基本模型的特性。

例如，ThoughtWorks技術雷達第16期中，討論了基于Cassandra構建的DSE圖數據庫的特性，并且也提到其中需要權衡的內容：

基于Cassandra 構建的DSE圖數據庫定位是大規模的數據集，相比之下我們長期喜愛的Neo4j開始表現出一定的局限性。這是需要取舍的；比如，你會失去了ACID的事務特性和Neo4j運行時的模式自由的特性，但卻可以訪問Cassandra的基礎表，以及針對分析工作負載和Spark的整合，還有強大的TinkerPop/Gremlin查詢語言可以使用，這的確是一個值得考慮的選擇。

如果考慮Web應用中的各種數據類型，你可能會發現不同的數據類型對一致性有不同的需求，而且實際需要立即一致性的數據類型數量相對較少。

上面引用的ThoughtWorks的觀點中，還提到了在考慮多模型數據庫中另一個重要的因素?-?在不同的模型和數據引擎間的整合和交互問題，以及為訪問數據的各種操作和分析的用例。DSE支持通過Spark(DSE分析)訪問圖數據以進行數據分析，并且DSE搜索引擎提供了針對DSE數據庫中的數據創建各種查詢索引的能力。

微服務數據模型操作的四個步驟

既然我們已經探討混合持久化和多模型兩種方式的優缺點，我們應該如何去決定哪些數據模型適用于大規?？蓴U展的微服務應用呢？可以按照以下步驟：

1、 識別你的應用程序中主要的數據類型，為其中每種類型創建一個服務，并讓每個服務掌控相應的持久層。在可能的情況下，為所有服務都使用多模型數據庫，允許服務在與數據交互的模型中是不相同的。

2 、用Tabular（例如DSE數據庫）作為網絡水平的可擴展性和可用性的主要模型，然后根據需要在此之上構建分層的鍵值對和文檔數據模型。請務必考慮在操作和分析用例中訪問數據的各種方法，以便提前計劃如何將搜索索引和復制等特性用于數據分析中心。

3、用圖的方法去表示（即DSE圖）高度關聯的數據，特別是在實體之間的關系有多個或多個屬性，并且數量比實體自己的屬性多的時候，或者需要在相同的實體之間捕捉多對多的關系的時候。

4、在不需要變更的情況下，保留關系數據庫技術中的遺留投資。例如，當你的案例是需要大規模、低延遲和高可用性的時候，那就使用傳統的關系型數據庫吧。

我希望本文為讀者提供了一個有用的框架，來考慮在應用程序中如何和怎么樣去支持多數據模型，以及何時考慮使用多模型數據庫。