建站
咨詢
售后
建站咨詢
新聞中心
?早期，數(shù)據(jù)庫寫入通常與一筆商業(yè)交易（commercial transaction）相對(duì)應(yīng)：如銷售、訂單等。雖然隨數(shù)據(jù)庫發(fā)展到不涉及金錢交易的領(lǐng)域，術(shù)語 交易/事務(wù)（transaction） 仍保留下來，指一組讀寫操作構(gòu)成的一個(gè)邏輯單元。
成都創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比邕寧網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式邕寧網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋邕寧地區(qū)。費(fèi)用合理售后完善，10多年實(shí)體公司更值得信賴。
事務(wù)不一定具備ACID。事務(wù)處理只是意味著允許客戶端進(jìn)行低延遲讀取和寫入，而不是只能周期運(yùn)行（如每天一次）的批量處理作業(yè)。
即使數(shù)據(jù)庫開始被用于許多不同類型的數(shù)據(jù)，如博客評(píng)論，游戲的動(dòng)作，通訊錄的聯(lián)系人等，但基本訪問模式仍類似處理商業(yè)交易。應(yīng)用程序通常使用索引通過某K查找少量記錄。根據(jù)用戶輸入新增或更新記錄。由于這些應(yīng)用程序是交互式的，這種訪問模式被稱為 在線事務(wù)處理（OLTP, OnLine Transaction Processing） 。
但數(shù)據(jù)庫也越來越多用于數(shù)據(jù)分析，它們有著很不同的訪問模式。通常，分析查詢需掃描大量記錄，每個(gè)記錄只讀取幾列，并計(jì)算匯總統(tǒng)計(jì)信息（如計(jì)數(shù)，總和或平均值），而非將原始數(shù)據(jù)返給用戶。例如，若數(shù)據(jù)是個(gè)銷售交易表，則分析查詢可能包含：
- 一月份每個(gè)商店的總收入？
- 在最近的推廣活動(dòng)中多賣了多少香蕉？
- 哪個(gè)牌子的嬰兒食品最常與X品牌的尿布同時(shí)購買？
這些查詢通常由業(yè)務(wù)分析師編寫，并提供給幫助公司管理層做出更好決策（商業(yè)智能）的報(bào)告。為將這種使用數(shù)據(jù)庫的模式和事務(wù)處理區(qū)分，被稱為在線分析處理（OLAP, OnLine Analytice Processing）。
表1：事務(wù)處理 V.S 分析系統(tǒng)
起初，相同數(shù)據(jù)庫可同時(shí)用于事務(wù)處理和分析查詢。SQL在這方面證明是非常靈活：可同時(shí)勝任OLTP及OLAP類型查詢。但1980s末和1990s初期，公司放棄使用OLTP系統(tǒng)用于分析，而是在單獨(dú)數(shù)據(jù)庫上運(yùn)行分析：數(shù)據(jù)倉庫。
數(shù)據(jù)倉庫（data warehouse）
企業(yè)可能有幾十個(gè)不同交易處理系統(tǒng)：面向終端客戶的網(wǎng)站，控制實(shí)體店的收銀系統(tǒng)，跟蹤倉庫庫存，規(guī)劃車輛路線，供應(yīng)鏈管理，員工管理等。這些系統(tǒng)中每個(gè)都很復(fù)雜，需專人維護(hù)，所以系統(tǒng)最終都是彼此獨(dú)立運(yùn)行。
這些OLTP系統(tǒng)往往對(duì)業(yè)務(wù)運(yùn)作至關(guān)重要，因而通常要求高可用 與處理事務(wù)時(shí) 低延遲。所以DBA會(huì)密切關(guān)注他們的OLTP數(shù)據(jù)庫，DBA一般不愿意讓業(yè)務(wù)分析人員在OLTP數(shù)據(jù)庫上運(yùn)行臨時(shí)分析查詢，因?yàn)檫@些查詢通常開銷巨大，會(huì)掃描大量數(shù)據(jù)集，這會(huì)損害并發(fā)執(zhí)行事務(wù)的性能。
相比之下，數(shù)據(jù)倉庫是個(gè)獨(dú)立數(shù)據(jù)庫，分析人員可查詢他們想要的內(nèi)容而不影響OLTP操作。數(shù)據(jù)倉庫包含公司各種OLTP系統(tǒng)的只讀副本。從OLTP數(shù)據(jù)庫（使用周期數(shù)據(jù)轉(zhuǎn)儲(chǔ)或連續(xù)更新流）中提取數(shù)據(jù)，轉(zhuǎn)換成適合分析的模式，清理并加載到數(shù)據(jù)倉庫中。將數(shù)據(jù)存入倉庫的過程稱為“提取-轉(zhuǎn)換-加載（Extract-Transform-Load，ETL）”：
圖8：數(shù)據(jù)倉庫和簡(jiǎn)化的ETL過程
大廠幾乎都有數(shù)倉，但小廠卻少聞。可能是因?yàn)樾S沒那么多不同OLTP系統(tǒng)，一般只有少量數(shù)據(jù)，完全可以在傳統(tǒng)SQL數(shù)據(jù)庫中直接查詢分析，甚至可以在Excel分析。而在大廠，做一些在小廠很簡(jiǎn)單的事，往往需大量繁重工作。
使用單獨(dú)的數(shù)倉，而非直接查詢OLTP系統(tǒng)進(jìn)行分析，一大優(yōu)勢(shì)是數(shù)倉能針對(duì)分析訪問模式進(jìn)行優(yōu)化。之前討論的索引算法對(duì)OLTP工作效果很好，但不擅長(zhǎng)應(yīng)對(duì)分析查詢。
OLTP數(shù)據(jù)庫 V.S 數(shù)據(jù)倉庫
數(shù)倉的數(shù)據(jù)模型通常是關(guān)系型，因?yàn)镾QL通常很適合分析查詢。有許多GUI數(shù)據(jù)分析工具可生成SQL查詢，可視化結(jié)果，并允許分析人員探索數(shù)據(jù)（通過下鉆，切片和切塊等操作）。
表面上，數(shù)倉和關(guān)系OLTP數(shù)據(jù)庫相似，因?yàn)樗鼈兌加蠸QL查詢接口。但系統(tǒng)內(nèi)部很不同，它們針對(duì)迥然不同的查詢模式，各自進(jìn)行了優(yōu)化。許多數(shù)據(jù)庫供應(yīng)商都專注支持事務(wù)處理或分析工作負(fù)載，而不是同時(shí)支持。
一些數(shù)據(jù)庫（如Microsoft SQL Server和SAP HANA）支持在同一產(chǎn)品中支持事務(wù)處理和數(shù)倉。但它們正在日益成為兩個(gè)獨(dú)立的存儲(chǔ)和查詢引擎，這些引擎恰好能通過一個(gè)通用SQL接口進(jìn)行訪問。
最近，大量開源的基于Hadoop的SQL項(xiàng)目出現(xiàn)，雖然還很年輕，但在與商業(yè)數(shù)倉系統(tǒng)競(jìng)爭(zhēng)。入Apache Hive，Spark SQL，Cloudera Impala，F(xiàn)acebook Presto。
星型和雪花型的分析模式
根據(jù)應(yīng)用程序需要，在事務(wù)處理領(lǐng)域使用了多種不同數(shù)據(jù)模型。分析型業(yè)務(wù)的數(shù)據(jù)模型則少得多。許多數(shù)倉都以相當(dāng)公式化的方式使用，稱為星型模式（也稱為維度建模）。
圖9中的模式顯示了可能在食品零售商處找到的數(shù)倉。模式的中心是個(gè)事實(shí)表（該案例中稱為fact_sales）。事實(shí)表的每行表示在特定時(shí)間發(fā)生的事件（這里的每行代表客戶購買的產(chǎn)品）。若分析網(wǎng)站流量而非零售量，則每行可能代表一個(gè)用戶的頁面瀏覽量或點(diǎn)擊量：
圖9：用于數(shù)據(jù)倉庫的星型模式的示例**
一般事實(shí)被捕獲為單獨(dú)事件，因?yàn)檫@樣之后的分析中獲得最大的靈活性。但是，這意味著事實(shí)表可能很大。像蘋果這樣巨頭在數(shù)倉可能有幾十PB交易歷史，其中大部分保存在事實(shí)表。
事實(shí)表中的列是屬性，如產(chǎn)品銷售的價(jià)格和從供應(yīng)商處購買的成本（可計(jì)算出利潤率），其它列是對(duì)其他表（稱為維度表）的外鍵引用。由于事實(shí)表中的每一行都表示一個(gè)事件，因此這些維度代表事件的發(fā)生地點(diǎn)，時(shí)間，方式和原因。
如圖9中，其中一個(gè)維度是銷售的產(chǎn)品。 dim_product? 表中的每行代表一種出售產(chǎn)品，包括庫存單位（SKU），說明，品牌名稱，類別，脂肪含量，包裝尺寸等。fact_sales 表中的每行都使用外鍵表示在特定交易中銷售了哪些產(chǎn)品。（為簡(jiǎn)單起見，如果客戶一次購買幾種不同產(chǎn)品，則它們?cè)谑聦?shí)表中被表示為單獨(dú)行）。
日期和時(shí)間通常使用維度表來表示，因?yàn)檫@允許對(duì)日期的附加信息（如公共假期）進(jìn)行編碼，從而允許查詢區(qū)分假期和非假期的銷售。
“星型模式”名字來源：當(dāng)表關(guān)系可視化時(shí)，事實(shí)表在中間，被一系列維度表包圍；與這些表的連接就像星星的光芒。
該模板的變體為雪花模式，其中維度被進(jìn)一步分解為子維度。如品牌和產(chǎn)品類別可能有單獨(dú)表格，且dim_product? 表格中的每行都能再次將品牌和類別作為外鍵，而不是將它們作為字符串直接存儲(chǔ)在 dim_product 表。雪花模式比星形模式更規(guī)范化，但星形模式是首選，因?yàn)閷?duì)于分析師，它更簡(jiǎn)單。
典型數(shù)倉中，表格通常很寬：
- 事實(shí)表格通常超過100列，有時(shí)甚至數(shù)百列；
- 維度表也可能很寬，因?yàn)樗鼈儼赡芘c分析相關(guān)的所有元數(shù)據(jù)。如dim_store 表可能包括在每個(gè)商店提供哪些服務(wù)的細(xì)節(jié)，是否具有店內(nèi)面包房，店面面積，商店開張日期，最后一次裝修時(shí)間，距離最近的高速公路有多遠(yuǎn)等。
網(wǎng)站欄目：系統(tǒng)設(shè)計(jì)之事務(wù)處理型Or分析處理型？
本文URL：http://fisionsoft.com.cn/article/cospdhg.html
