《支持關系型數據庫及NoSQL的統一數據建模方案》要點:
本文介紹了支持關系型數據庫及NoSQL的統一數據建模方案,希望對您有用。如果有疑問,可以聯系我們。
現如今,NoSQL數據庫與關系型數據庫往往并存于企業的數據架構中.但是在NoSQL的數據管理方面,還缺乏像管理關系型數據那樣成熟的方法與工具.
當前流行的NoSQL數據庫在設計時更多地考慮了應用程序的性能,而較少考慮到高層業務模型、數據的集成以及數據的標準化.對于NoSQL數據庫來說,其數據建模與物理數據之間存在著一條明顯的鴻溝.
在本文中,我將介紹一種利用統一數據建模技術管理NoSQL與關系型數據庫的方案.統一數據建模支持多種特性,例如為NoSQL數據庫的模式生成文檔,以及對現有數據庫中的數據進行反向工程.它同時也支持對現有數據庫的可視化表現.
隨著數據在4個方面的增長(數據量、多樣性、速度以及值),數據的管理方式也發生了轉變,從縱向擴展變為橫向擴展,通過幾十萬臺小型的服務器創建分布式計算應用,以取代單一的強大機器.為了支持分布式計算的需求,數據也必須轉換為一種不同的模型.
當前的關系型數據庫都支持第3范式.對于ACID(原子性、一致性、隔離性與持久性)事務模型,如果一份數據在數據庫中只擁有一個拷貝,那么更適合使用關系型數據庫.這意味著任一時間內只有一份拷貝會更新.但對于來自多個不同應用的查詢,數據必須進行聚合.因此,為了滿足業務需求,數據必須進行分布式處理,而數據模式也必須進行反范式化.在設計模式時,必須允許進行分布式的查詢,這就需要處于不同數據節點上的每個數據集必須包含足夠的信息,能夠獨立地執行查詢.
基于以上特征可知,創建NoSQL數據庫時的基本要點在于通過邏輯模型描述業務需求,并通過反范式化的模式對應實際的數據模型.而不是在沒有數據建模的情況下直接從程序向NoSQL數據庫中寫入數據.
此外,由于數據的多樣性將進一步提高,因此在靈活性方面要能夠匹配數據的原生格式,使其能夠保存在文檔、圖形或鍵值數據庫中.在敏捷的業務場景中,數據的結構也將產生改變.但預定義的強模式將受到這種業務場景的限制.在關系型數據庫中,對現有數據列的更改或是新建數據列操作將造成數據表的重建,但對于NoSQL數據庫來說,添加新的屬性或組合對象操作都非常靈活.
另一方面,在NoSQL中寫入數據前也無需強制使用預定義的模式.而在讀取數據時,模式的應用表現為用戶以原始形態加載數據,在讀取后就可以按需求隨意變換.對于數據的讀取與理解來說,模式是必需的,但這對于使用Map Reduce程序,而又并非開發人員的使用者來說是一個不小的挑戰,因為模式在Map Reduce程序中是隱含的,因此大多數DBA與數據分析師無法訪問與理解這些模式.正因為如此,數據建模就成為了更好地理解企業數據的關鍵因素.
此外,與傳統的批量數據集相比,流數據的處理又提出了不同的要求(實時性,只增性等等).為了支持多個并發式數據處理系統的需求,數據本身或許還要進行某種形式的轉換.在數據分析過程中,數據模型能夠幫助用戶理解數據,并調整數據結構.根據數據模型的設計,數據集成系統能夠從原始的流數據中萃取出維度數據,并導入數據倉庫中.
因此,為了讓基于RDBMS與NoSQL數據庫的數據架構滿足業務上的需求,數據模型扮演了關鍵的角色.
RDBMS中的ACID(原子性、一致性、隔離性和持久性)特性是數據庫方面最重要的一種需求,這種重要性在今后也將繼續.而在未來,RDBMS與NoSQL的混合使用將成為企業架構中的一種典型場景.Unified Modelset(統一模型)將用于描述RDBMS與NoSQL數據庫的數據模式.
以下是RDBMS與NoSQL數據庫之間區別的簡單總結.
圖1,RDBMS與NoSQL數據庫的區別
要在不同的業務場景中管理關系型與NoSQL數據庫的區別,并充分利用他們的功能,這是一個極大的挑戰.因此,我們需要一種統一的方式以管理這些數據庫.
CA ERwin Unified Data Modeler支持對RDBMS與兩種主流的NoSQL數據類型(文檔數據庫及列族數據庫)進行數據建模.它還支持數據發現以及RDBMS與NoSQL數據庫之間的數據遷移.
通過Unified Modelset管理RDBMS與NoSQL數據的方法
Unified Modelset為業務需求及實際數據模式的文檔化提供了一個良好的方案,并且能夠管理RDBMS與NoSQL數據庫中的數據.
通過概念/邏輯模型描述業務需求的表示法
概念/邏輯模型的表示法包括:
實體(Entity)
屬性(Properties)
關系(Relationship)
標簽(Tags)
圖2,概念/邏輯模型的定義
邏輯、RDBMS與NoSQL數據模型基本概念的對照
概念 / 邏輯 | RDBMS | NoSQL |
---|---|---|
實體 | 表 | 集合或列族 |
實體的實例 | 行 | 文檔或行 |
屬性 | 列 | 鍵或列 |
某個實體實例的屬性 | 單元格的值 | 字段值 |
領域 | 數據類型 | 數據類型(某些NoSQL數據庫沒有定義數據類型,所有的值都是純文本.) |
關系 | 約束 | 引用、嵌入或附加表 / 跨多個行的列族. |
鍵 | 索引 | 索引、附加表或引用 |
唯一標識符 | 主鍵 | 行鍵 |
統一建模過程
業務概念與需求可以由邏輯模型進行描述,而后者又可以轉換為目標物理模型.轉換過程取決于在邏輯模型中描述的查詢模式和數據生成模式.轉換規則已預定義為模式轉換策略,具體會影響到哪種策略決定于描述查詢模式和數據生成模式的標簽.這些標簽與規則都可以由用戶進行修改和自定義.在該過程的最后,原始數據將按照所設計的物理模型進行格式化,并以正向工程的方式遷移至數據庫中.
使用Unified Modelset的業務場景:
對RDBMS與NoSQL的數據模式進行文檔化,并支持對現有數據庫的反向工程.
根據所設計的Unified Modelset,在不同的數據庫之間進行數據遷移(正向工程).并且支持基于Unified Modelset對現有的數據庫進行重構.
從頭開始創建Unified Modelset,生成新的物理模型并綁定到數據庫,并將模型封裝為UDBC數據源.管理UDBC的讀寫數據操作.
為生產環境中的數據庫創建數據倉庫,與場景2相類似.從現有的數據庫中進行反向工程,設計數據倉庫的物理模型,遷移數據以完成數據倉庫的構建.
以下是為某個電影資料庫所設計的數據庫示例,業務需求如下所示:
一部電影可以由多位演員出演,一部電影可以屬于多個不同的分類.
一位演員可以出演多部電影.
一個分類可以包括多部電影.
在概念/邏輯模型中,可以辨別出以下實體及關系:
實體 —— 角色(Actor)、分類(Category)和電影(Film)
關系 —— (角色 – 電影,多對多);(電影 – 分類,多對多)
圖3是一個由ER圖所描述的電影資料系統的邏輯模型圖,而圖4則是由ER圖所描述的物理RDBMS模型圖.
圖3,以傳統ER圖表現的邏輯模型
圖4,以傳統ER圖表現的RDBMS物理模型
不過,現有的ER圖并不足以對NoSQL數據進行描述.因此,我們創建了Unified Modelset,以支持對于RDBMS與NoSQL的數據建模工作.它能夠對業務模型、查詢模式與數據生成模式進行描述.該模型由一個邏輯模型及多個物理模型組成.
圖5,Unified Modelset定義
圖6是上文所述的電影資料庫這一示例的邏輯模型,在實體與屬性中還附加了一些標簽,以描述數據的查詢模式與生成模式.
圖6,使用Unified Modelset表示法表現的邏輯模型
文檔數據庫物理模型在Unified Modelset中的表示法
在MongoDB或Couchbase這種文檔型數據庫中,與數據庫對象相關的一切都被封裝為一個文檔對象.
集合對應著實體
嵌套文檔對應著實體
文檔的嵌套對應著嵌套文檔與父文檔之間的關系
數組對應著一對多的關系
引用對應著關系
圖7是文檔型數據庫的物理模型圖.它的表示法表現出了真實的數據結構(文檔與嵌套文檔).圖8展現了對應MongoDB所設計的模型中的真實數據,例如Actor和Category文檔就嵌套在Film文檔中.
圖7,基于文檔的物理模型
圖8,對應MongoDB所設計的模型中的實際數據
列族數據庫物理模型在Unified Modelset中的表示法
列族數據庫也是NoSQL數據庫中的一種,它以列的形式描述了相關的數據.可以理解為在一個元組(對)中包含了一個鍵值對,其中每個鍵都映射到一個值,而這個值是由列的集合所組成的.
典型的列族數據庫包括HBase和Cassandra
列族(CF)對應著實體
表對應著實體,它與父列族所對應的實體之間存在著關系
列修飾符(qualifier)對應著屬性或索引(標簽)
跨多個列族的一行對應著跨多個實體的關系
圖9是上文所述的電影資料庫這一示例的物理模型圖.
圖9,列族數據庫物理模型
Unified Modelset中的查詢模式
查詢模式對于NoSQL數據建模來說至關重要.如何將邏輯模型反范式化為物理模型取決于數據的查詢方式.因此必須在數據模型中描述查詢模式,而在數據模型中經常對多個實體一起進行查詢.這些實體需要在NoSQL物理數據存儲引擎中進行聚合.
聚合,聚合數據是指組合了多種度量了數據.當數據被聚合之后,所觀察到的數據組將按照觀察的方式被轉換為匯總統計結果.它能夠對實體進行描述.
一對一,這是一種描述關系的方式.數據庫表中的每一行將對應,并且僅對應另一張表中的一行.它表現了RDBMS中的外鍵(FK)約束.在文檔數據庫中,相關的行可以嵌套在對應表的文檔,或是同一張表的其他文檔中.
一對多,也是一種描述關系的方式.數據庫表中的每一行都可對應關聯表中的多個行.比方說,一位母親可以有多個孩子,但每個孩子只能有一位母親.它表現了RDBMS中的外鍵(FK)約束.它可以嵌入在對應表的文檔中.
多對多,描述關系的另一種方式.數據庫表中的一行或多行可以對應關聯表中的0行、1行或多行.比方說,一段視頻可以被多位客戶租用,而一位客戶也可以租用多段視頻.它表現了RDBMS中的附加表.在文檔數據庫中,這種關系可以表現為在對應文檔,或是在額外的文檔中所建立的引用.
頻繁的查詢,描述關系的另一種方式.在頻繁的查詢中,應盡可能將相關的實體聚合在一起,成為一個單一的組合實體.在物理數據庫中最好能夠為其創建索引.
Unified Modelset中的生產環境數據模式
生產數據模式是用于描述數據庫在生產環境中的物理特征的一種方式.
大數據量(Big Volume),用于描述實體,包括那些包含大量記錄的實體.因此,最好能夠設計一種聚合的實體.
強一致性與最終一致性,用于描述實體.可用于進行數據轉換的校驗.如果某個實體是“強一致性”的,那么應避免將其嵌入其他實體,并且避免分發.
只讀 / 附加 / 更新,用于描述實體.經常會更新的數據應避免將其嵌入其他實體,因為對分布式的實體進行更新可能會導致對大規模的數據加鎖.而“只讀”或“附加”實體可以任意選擇是否要嵌入其他實體.
Unified Modeler中的模式推斷
由于NoSQL數據庫不支持模式,因此數據模式必須從原始數據中進行推斷,而不是直接從RDBMS等數據庫中直接抽取出來.模式推斷的方法有以下幾種:
記錄統計的模式涵蓋,包含以下查詢的統計:
數據庫中的所有記錄
前N條記錄
全部記錄中的某個百分比
經過N層遞歸的記錄
機器學習、收集UI的反饋信息、分類的維度生成、以及對于模式推斷過程的準確度進行持續的改進.
圖10,在Unified Modeler中對MongoDB數據庫進行反向工程
Unified Modeler中的UDBC(統一數據庫連接)
我們現在已經可以用Unified Modelset描述企業數據架構,包括邏輯模型中的業務需求以及物理模型中的數據模式了,現在我們要進一步擴展其能力,基于數據模型實現數據發現.UDBC(統一數據庫連接)為我們提供了一種接口,以描述基于Unified Modeler的外部企業數據.
圖11,UDBC(統一數據庫連接)架構
關于作者
王崢(Allen Wang)是來自CA technologies公司ERwin研發團隊的總監,負責ERwin在全球范圍內的研發以及ERwin Unified Modeler產品的管理.他領導團隊成功地發布了自8.0開始的8個重要版本.他還是工業標準委員會OMG與DAMA的成員.他策劃和建立了CA與清華大學合作的大數據研究項目,致力于幫助產品進入新興市場,專注于企業中復雜的大數據環境,通過統一模型與數據挖掘等技術管理數據.他還提交了5個關于數據建模與NoSQL方面的專利.此外,他還是復旦大學的客座教授,開辦了大數據方面的碩士研究生課程.本文的順利發布還要感謝ERwin開發團隊的貢獻與Xiaoyuan Yuan的編輯.
查看英文原文:Unified Data Modeling for Relational and NoSQL Databases
數據分析網(www.afenxi.com),國內領先的大數據門戶,旨在幫助大數據從業人士、喜好者提供大數據新聞資訊、前沿技術、業界觀點的信息平臺.
《支持關系型數據庫及NoSQL的統一數據建模方案》是否對您有啟發,歡迎查看更多與《支持關系型數據庫及NoSQL的統一數據建模方案》相關教程,學精學透。維易PHP學院為您提供精彩教程。
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/9574.html