㈠ 如何用SQL Server建立分布式資料庫
很多組織機構慢慢的在不同的伺服器和地點部署SQL Server資料庫——為各種應用和目的——開始考慮通過SQL Server集群的方式來合並。
將SQL Server實例和資料庫合並到一個中心的地點可以減低成本,尤其是維護和軟硬體許可證。此外,在合並之後,可以減低所需機器的數量,這些機器就可以用於備用。
當尋找一個備用,比如高可用性的環境,企業常常決定部署Microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)SQL Server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後,我讓你們自己做決定。
什麼是Microsoft集群伺服器
MSCS是一個Windows Server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」,來獲得更高的可用性和對數據和應用更簡便的管理。MSCS可以自動的檢查到伺服器或者應用的失效,並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。
這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中,它會自動將資源(比如磁碟和IP地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性,比如站點全面失效的情況下。
MSCS不要求在客戶計算機上安裝任何特殊軟體,因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的,因為MSCS在相同的IP地址上重啟應用、文件共享等等。進一步,為了災難恢復,集群的節點可以處於分離的、遙遠的地點。
在集群伺服器上的SQL Server
SQL Server 2000可以配置為最多4個節點的集群,而SQL Server 2005可以配置為最多8個節點的集群。當一個SQL Server實例被配置為集群之後,它的磁碟資源、IP地址和服務就形成了集群組來實現災難恢復。
SQL Server 2000允許在一個集群上安裝16個實例。根據在線幫助,「SQL Server 2005在一個伺服器或者處理器上可以支持最多50個SQL Server實例,」但是,「只能使用25個硬碟驅動器符,因此如果你需要更多的實例,那麼需要預先規劃。」
注意SQL Server實例的災難恢復階段是指SQL Server服務開始所需要的時間,這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性,考慮使用其他的方法,比如log shipping和資料庫鏡像。
單個的大的SQL Server集群還是小的集群
下面是大的、由更多的節點組成的集群的優點:
◆更高的可用新(更多的節點來災難恢復)。
◆更多的負載均衡選擇(更多的節點)。
◆更低廉的維護成本。
◆增長的敏捷性。多達4個或者8個節點,依賴於SQL版本。
◆增強的管理性和簡化環境(需要管理的少了)。
◆更少的停機時間(災難恢復更多的選擇)。
◆災難恢復性能不受集群中的節點數目影響。
下面是單個大的集群的缺點:
◆集群節點數目有限(如果需要第9個節點怎麼辦)。
◆在集群中SQL實例數目有限。
◆沒有對失效的防護——如果磁碟陣列失效了,就不會發生災難恢復。
◆使用災難恢復集群,無法在資料庫級別或者資料庫對象級別,比如表,創建災難恢復集群。
虛擬化和集群
虛擬機也可以參與到集群中,虛擬和物理機器可以集群在一起,不會發生問題。SQL Server實例可以在虛擬機上,但是性能可能會受用影響,這依賴於實例所消耗的資源。在虛擬機上安裝SQL Server實例之前,你需要進行壓力測試來驗證它是否可以承受必要的負載。
在這種靈活的架構中,如果虛擬機和物理機器集群在一起,你可以在虛擬機和物理機器之間對SQL Server進行負載均衡。比如,使用虛擬機上的SQL Server實例開發應用。然後在你需要對開發實例進行壓力測試的時候,將它災難恢復到集群中更強的物理機器上。
集群伺服器可以用於SQL Server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境,為了負載均衡和維護,實例可以從一個節點移動到另外的節點。
㈡ 這種分布式資料庫應用,有沒有現成的解決方案
很多公司都在開發自己的分布式資料庫架構,且不少公司都可能使用上了,也有很多人在講分布式資料庫架構,這些是真正意義上的分布式資料庫嗎?
若要我加一個詞的話, 我一般說偽分布式或者說所謂的分布式資料庫架構,是跟陳國慶分享的NoSQL一樣,只是起一個簡單且好聽點的名字,之所以談這個話題,就是想與大家分享一下個人對偽分布式資料庫架構的理解及所實踐的。
PPT主要的內容主要有幾點:什麼是分布式資料庫;什麼是偽分布式資料庫;分布式和偽分布式資料庫架構的優缺點;偽分布式資料庫架構適用的場景;二種偽分布式資料庫架構的設計思路,一類適用於電子商務等領域,另外一類適合於SNS游戲等領域。
首先申明二個要點:第一點不支持分布式事務的,肯定不是分布式資料庫;第二點分布式強調的是可用性、可靠性和數據一致性,其中數據一致性又分鬆散一致性和嚴密一致性,因為分布式資料庫有不同的實現演算法,為此數據一致性都有各種差異。
接下來,我們看一下分布式資料庫的定義:由一組存儲在網路中不同伺服器上的數據組成,網路中每個節點具有獨立執行局部應用的能力,也可以通過網路通信系統執行全局應用的能力。
為什麼需要偽分布式資料庫產品?是因為集中式資料庫,當數據量越來越大,數據的讀寫量也越來越大,且無法通過垂直增加或升級硬體設備而滿足的,以及越來越成為業務增長的瓶頸,那麼我們就不得不考慮革新,採用一種更加有效、可行的方案解決。
偽分布式資料庫的應用場景,稍微羅列了下:電子商務平台(C2C、B2B、B2C) 、SNS平台、IM即時通信軟體、電子郵件系統、日誌分析系統、SNS游戲、其他平台型網站。
大致總結了下,使用偽分布式資料庫架構場景的三要素:
大數據容量,且垂直升級擴展受限的;
高並發事務型的;
數據更新量遠大於數據讀取,且數據更新量非常大;
接下來我們看一下分布式資料庫一個最獨特的架構圖,但是看之前,先了解下分布式資料庫的四個是核心模塊。我們把四個名詞解釋一下:
什麼是局部資料庫管理系統?
什麼是全局資料庫管理系統?
什麼是全局數據字典?
什麼是通信管理?
LDBMS
建立和管理局部資料庫,提供場地自治能力,執行局部應用及全局查詢的子查詢;
GDBMS
提供分布透明性,協調全局事務執行,協調各局部DBMS完成全局應用,保證資料庫全局一致性、執行並發控制、實現更新同步和提供全局恢復等功能;
全局數據字典
存放全局概念模式、分片模式、分布模式的定義以及各模式之間映像的定義,存放有關用戶存取許可權的定義,保證全局用 戶的許可權和資料庫的安全,存放數據完整性約束條件定義;
通信管理
實現分布式資料庫各場地之間消息和數據傳遞;
㈢ 目前主流的分布式資料庫系統實現方案有哪些
(1)方案一(資料庫保存所有伺服器索引信息)
全對稱結構,沒有中央伺服器
web方案:
只從本地資料庫檢索符合條件的記錄,給出結果
每次檢索都要從本地伺服器的海量數據中進行
資料庫方案:
資料庫保存所有伺服器的索引內容
緩存命中率高的記錄,減少檢索時間
伺服器負載分析:
伺服器負載假設:
一百個結點,每結點一百人同時使用,每個結點一萬條記錄
web伺服器:同時一百線程在本地資料庫伺服器檢索
資料庫伺服器:每次接收一百個查詢請求;每個請求要從一百萬條索引中檢索(最壞的情況);緩沖機制可以稍微減輕負擔
數據更新操作:
同時更新所有資料庫/只更新本地,伺服器間相互同步
方案二(資料庫保存本地索引及少量緩沖)
每高校作為一個結點
所有結點全對稱結構,網路中沒有一個中央伺服器
web方案:
接收到請求時同時多線程向其它伺服器同時搜索(伺服器壓力問題?)
資料庫方案:
資料庫保存本地數據
資料庫保存一定量緩沖數據,
伺服器負載分析:
伺服器負載假設:
一百個結點,每結點一百人同時使用
則每個web伺服器同時發起一萬個線程向其它數據伺服器搜索(oops!)
每個資料庫伺服器會同時接收到一萬個查詢請求(oops!)
採用學習過程只能少量減少查詢請求和web伺服器搜索線程
數據更新操作:
只更新本地
方案三(中央伺服器方案一)
每高校一個結點
每結點結構相同,連接到同一個中央伺服器
web方案
每個查詢向中央伺服器進行,由中央伺服器實行檢索,中央伺服器返回檢索結果
資料庫方案
中央資料庫保存所有索引信息
每結點可以只用小型資料庫保存本地用戶和其它信息即可
伺服器負載分析:
伺服器負載假設:
一百個結點,每結點一百人同時使用,每結點資料記錄一萬條
web伺服器:同時發起一百個進程向中央資料庫查詢
資料庫伺服器(中央):同時接收一萬條查詢請求並返回大容量結果
資料庫伺服器(結點):少量工作
數據更新操作:
只更新中央伺服器
方案四(中央伺服器方案二)
每高校一個結點
每結點結構相同,連接到同一中央伺服器
web方案:
每個查詢向中央伺服器進行,由中央伺服器根據查詢內容進行轉發到結點資料庫,再由結點資料庫返回結果
資料庫方案:
中央伺服器保存各結點分類信息,根據頁面請求的分類轉發查詢到相應伺服器
伺服器負載分析:
伺服器負載假設:
一百個結點,每結點一百人同時使用,每結點資料記錄一萬條,每結點一百個類別
web伺服器:同時一百個進程向中央資料庫查詢
資料庫伺服器(中央):同時接收一萬條請求並轉發
資料庫伺服器(結點):從中央伺服器接收查詢請求,最壞情況下每結點接收到一萬條查詢請求
數據更新操作:
只更新本地伺服器
分類變化時更新中央伺服器
㈣ 什麼叫分布式資料庫,有什麼優點和缺點
1.分布式資料庫是資料庫的一種,是資料庫技術和網路技術的結合產物。
2.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種。
是的,分布式數據文件便於資料庫的管理維護。
㈤ 資料庫具體應用的實例有哪些
資料庫的應用領域
1、多媒體資料庫: 這類資料庫主要存儲與多媒體相關的數據,如聲音、圖像和視頻等數據。多媒體數據最大的特點是數據連續,而且數據量比較大,存儲需要的空間較大。
2、移動資料庫: 該類資料庫是在移動計算機系統上發展起來的,如筆記本電腦、掌上計算機等。該資料庫最大的特點是通過無線數字通信網路傳輸的。移動資料庫可以隨時隨地地獲取和訪問數據,為一些商務應用和一些緊急情況帶來了很大的便利。
3、空間資料庫: 這類資料庫目前發展比較迅速。它主要包括地理信息資料庫(又稱為地理信息系統,即GIS)和計算機輔助設計(CAD)資料庫。其中地理信息資料庫一般存儲與地圖相關的信息數據;計算機輔助設計資料庫一般存儲設計信息的空間資料庫,如機械、集成電路以及電子設備設計圖等。
4、信息檢索系統: 信息檢索就是根據用戶輸入的信息,從資料庫中查找相關的文檔或信息,並把查找的信息反饋給用戶。信息檢索領域和資料庫是同步發展的,它是一種典型的聯機文檔管理系統或者聯機圖書目錄。
5、分布式信息檢索: 這類資料庫是隨著Internet的發展而產生的資料庫。它一般用於網際網路及遠距離計算機網路系統中。特別是隨著電子商務的發展,這類資料庫發展更加迅猛。
許多網路用戶(如個人、公司或企業等)在自己的計算機中存儲信息,同時希望通過網路使用發送電子郵件、文件傳輸、遠程登錄方式和別人共享這些信息。分布式信息檢索滿足了這一要求。
6、專家決策系統: 專家決策系統也是資料庫應用的一部分。由於越來越多的數據可以聯機獲取,特別是企業通過這些數據可以對企業的發展作出更好的決策,以使企業更好地運行。由於人工智慧的發展,使得專家決策系統的應用更加廣泛。
(5)分布式資料庫設計案例擴展閱讀
對資料庫系統的基本要求是:
①能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度,節省開發費用。
②冗餘數據少,數據共享程度高。
③系統的用戶介面簡單,用戶容易掌握,使用方便。
④能夠確保系統運行可靠,出現故障時能迅速排除;能夠保護數據不受非受權者訪問或破壞;能夠防止錯誤數據的產生,一旦產生也能及時發現。
⑤有重新組織數據的能力,能改變數據的存儲結構或數據存儲位置,以適應用戶操作特性的變化,改善由於頻繁插入、刪除操作造成的數據組織零亂和時空性能變壞的狀況。
⑥具有可修改性和可擴充性。
⑦能夠充分描述數據間的內在聯系。
㈥ 阿里雲分布式資料庫服務DRDS誰使用過 簡單講講!
淘寶開源的TDDL和cobar的結合,放到了阿里雲上就是DRDS,是商品,服務,可以購買使用的。可以在阿里雲官網上注冊免費試用。
=====================================================
隨著互聯網時代的到來,計算機要管理的數據量呈指數級別地飛速上漲,而我們卻完全無法對用戶數做出准確預估。我們的系統所需要支持的用戶數,很可能在短短的一個月內突然爆發式地增長幾千倍,數據也很可能快速地從原來的幾百GB飛速上漲到了幾百個TB。如果在這爆發的關鍵時刻,系統不穩定或無法訪問,那麼對於業務將會是毀滅性的打擊。
伴隨著這種對於系統性能、成本以及擴展性的新需要,以HBase、MongoDB為代表的NoSQL資料庫和以阿里DRDS、VoltDB、ScaleBase為代表的分布式NewSQL資料庫如雨後春筍般不斷涌現出來。
本文將會介紹阿里DRDS的技術理念、發展歷程、技術特性等內容。
DRDS設計理念
從20世紀70年代關系資料庫創立開始,其實大家在資料庫上的追求就從未發生過變化:更快的存取數據,可以按需擴縮以承載更大的訪問量和更大的數據量,開發容易,硬體成本低,我們可以把這叫做資料庫領域的聖杯。
為了支撐更大的訪問量和數據量,我們必然需要分布式資料庫系統,然而分布式系統又必然會面對強一致性所帶來的延遲提高的問題,因為網路通信本身比單機內通信代價高很多,這種通信的代價就會直接增加系統單次提交的延遲。延遲提高會導致資料庫鎖持有時間變長,使得高沖突條件下分布式事務的性能不升反降(這個具體可以了解一下Amdahl定律),甚至性能距離單機資料庫都還有明顯的差距。
從上面的說明,我們可以發現,問題的關鍵並不是分布式事務做不出來,而是做出來了卻因為性能太差而沒有什麼卵用。資料庫領域的高手們努力了40年,但至今仍然沒有人能夠很好地解決這個問題,Google Spanner的開發負責人就經常在他的Blog上談論延遲的問題,相信也是飽受這個問題的困擾。
面對這個難題,傳統的關系資料庫選擇了放棄分布式的方案,因為在20世紀70~80年代,我們的資料庫主要被用來處理企業內的各類數據,面對的用戶不過幾千人,而數據量最多也就是TB級別。用單台機器來處理事務,用個磁碟陣列處理一下磁碟容量不夠的問題,基本上就能解決一切問題了。
然而,信息化和互聯網的浪潮改變了這一切,我們突然發現,我們服務的對象發生了根本性變化,從原來的幾千人,變成了現在的幾億人,數據量也從TB級別到了PB級別甚至更多。存在單點的單機系統無論如何努力,都會面對系統處理能力的天花板。原來的這條路,看起來是走不下去了,我們必須想辦法換一條路來走。
可是,分布式資料庫所面對的強一致性難題卻像一座高山,人們努力了無數個日日夜夜,但能翻越這座山的日子看來仍然遙遙無期。
於是,有一群人認為,強一致性這件事看來不怎麼靠譜,那徹底繞開這個問題是不是個更好的選擇?他們發現確實有那麼一些場景是不需要強一致事務的,甚至連SQL都可以不要,最典型的就是日誌流水的記錄與分析這類場景。而去掉了事務和SQL,介面簡單了,性能就更容易得到提升,擴展性也更容易實現,這就是NoSQL系統的起源。
雖然NoSQL解決了性能和擴展性問題,但這種繞開問題的方法給用戶帶來了很多困擾,系統的開發成本也大大提升。這時候就有另外一群人,他們覺得用戶需要SQL,覺得用戶也需要事務,問題的關鍵在於我們要努力地往聖杯的方向不斷前進。在保持系統的擴展性和性能的前提下,付出盡可能小的代價來滿足業務對資料庫的需要。這就是NewSQL這個理念的由來。
DRDS也是一個NewSQL的系統,它與ScaleBase、VoltDB等系統類似,都希望能夠找到一條既能保持系統的高擴展性和高性能,又能盡可能保持傳統資料庫的ACID事務和SQL特性的分布式資料庫系統。
DRDS發展歷程
在一開始,TDDL的主要功能就是做資料庫切分,一個或一組SQL請求提交到TDDL,TDDL進行規則運算後得知SQL應該被分發到哪個機器,直接將SQL轉發到對應機器即可(如圖1)。
圖1 TDDL資料庫切分
開始的時候,這種簡單的路由策略能夠滿足用戶的需要,我們開始的那些應用,就是通過這樣非常簡單的方式完成了他所有的應用請求。我們也認為,這種方案簡單可靠,已經足夠好用了。
然而,當我們服務的應用從十幾個增長到幾百個的時候,大量的中小應用加入,大家紛紛表示,原來的方案限制太大,很多應用其實只是希望做個讀寫分離,希望能有更好的SQL兼容性。
於是,我們做了第一次重大升級,在這次升級里,我們提出了一個重要的概念就是三層架構,Matrix對應資料庫切分場景,對SQL有一定限制,Group對應讀寫分離和高可用場景,對SQL幾乎沒有限制。如圖2所示。
圖2 資料庫升級為三層架構
這種做法立刻得到了大家的認可,TDDL所提供的讀寫分離、分庫分表等核心功能,也成為了阿里集團內資料庫領域的標配組件,在阿里的幾乎所有應用上都有應用。最為難得的是,這些功能從上線後,到現在已經經歷了多年雙11的嚴酷考驗,從未出現過嚴重故障(p0、p1級別故障屬於嚴重故障)。資料庫體系作為整個應用系統的重中之重,能做到這件事,真是非常不容易。
隨著核心功能的穩定,自2010年開始,我們集中全部精力開始關注TDDL後端運維系統的完善與改進性工作。在DBA團隊的給力配合下,圍繞著TDDL,我們成功做到了在線數據動態擴縮、非同步索引等關鍵特徵,同時也比較成功地構建了一整套分布式資料庫服務管控體系,用戶基本上可以完全自助地完成整套資料庫環境的搭建與初始化工作。
大概是2012年,我們在阿里雲團隊的支持下,開始嘗試將TDDL這套體系輸出到阿里雲上,也有了個新的名字:阿里分布式資料庫服務(DRDS),希望能夠用我們的技術服務好更多的人。
不過當我們滿懷自信地把自己的軟體拿到雲上的時候,卻發現我們的軟體距離用戶的要求差距很大。在內部因為有DBA的同學們幫助進行SQL review,所以SQL的復雜度都是可控的。然而到了雲上,看了各種渠道提過來的兼容性需求,我們經常是不自覺地發出這樣的感嘆:「啊?原來這種語法MySQL也是可以支持的?」
於是,我們又進行了架構升級,這次是以兼容性為核心目標的系統升級工作,希望能夠在分布式場景下支持各類復雜的SQL,同時也將阿里這么多年來在分布式事務上的積累都帶到了DRDS裡面。
這次架構升級,我們的投入史無前例,用了三年多才將整個系統落地完成。我們先在內部以我們自己的業務作為首批用戶上線,經過了內部幾百個應用的嚴酷考驗以後,我們才敢拿到雲上,給到我們的最終用戶使用。
目前,我們正在將TDDL中更多的積累輸出到雲上,同時也努力優化我們的用戶界面。PS:其實用戶界面優化對我們這種專注於高性能後端技術的團隊來說,才是最大的技術挑戰,連我也去學了AngularJS,參與了用戶UI編。
DRDS主要功能介紹
發展歷史看完了,下面就由我來介紹一下目前我們已經輸出到雲上的主要功能。
【分布式SQL執行引擎】
分布式SQL引擎主要的目的,就是實現與單機資料庫SQL引擎的完全兼容。目前我們的SQL引擎能夠做到與MySQL的SQL引擎全兼容,包括各類join和各類復雜函數等。他主要包含SQL解析、優化、執行和合並四個流程,如圖3中綠色部分。
圖3 SQL引擎實現的主要流程
雖然SQL是兼容的,但是分布式SQL執行演算法與單機SQL的執行演算法卻完全不同,原因也很簡單,網路通信的延遲比單機內通信的延遲大得多。舉個例子說明一下,我們有份文件要從一張紙A上謄寫到另外一張紙B上,單機系統就好比兩張紙都在同一個辦公室里,而分布式資料庫則就像是一張紙在北京,一張紙在杭州。
自然地,如果兩張紙在同一個辦公室,因為傳輸距離近,逐行謄寫的效率是可以接受的。而如果距離是北京到杭州,用逐行謄寫的方式,就立刻顯得代價太高了,我們總不能看一行,就打個「飛的」去杭州寫下來吧。在這種情況下,還是把紙A上的信息拍個照片,【一整批的】帶到杭州去處理,明顯更簡單一些。這就是分布式資料庫特別強調吞吐調優的原因,只要是涉及到跨機的所有查詢,都必須盡可能的積攢一批後一起發送,以減少系統延遲提高帶來的不良影響。
【按需資料庫集群平滑擴縮】
DRDS允許應用按需將新的單機存儲加入或移出集群,DRDS則能夠保證應用在遷移流程中實現不停機擴容縮容。
圖4 DRDS按需進行平滑擴縮
在內部的資料庫使用實踐中,這個功能的一個最重要應用場景就是雙11了。在雙11之前,我們會將大批的機器加入到我們的資料庫集群中,抗過了雙11,這批機器就會下線。
當DRDS來到雲上,我們發現雙11其實不僅僅隻影響阿里內部的系統。在下游的各類電商輔助性系統其實也面對巨大壓力。在雙11前5天,網聚寶的熊總就找到我說,擔心撐不過雙11的流量,怕系統掛。於是我們就給他介紹了這個自動擴容的功能怎麼用,他買了一個月的資料庫,掛接在DRDS上。資料庫能力立刻翻倍,輕松抗過了雙11,也算是我印象比較深刻的一個案例了。
因為我們完全無法預測在什麼時間點系統會有爆發性的增長,而如果在這時候系統因為技術原因不能使用,就會給整個業務帶來毀滅性的影響,風口一旦錯過,就追悔莫及了。我想這就是雲計算特別強調可擴展能力的原因吧。
【小表廣播】
小表廣播也是我們在分布式資料庫領域內最常用的工具之一,他的核心目的其實都是一個——盡可能讓查詢只發生在單機。
讓我們用一個例子來說明,小表廣播的一般使用場景。
圖5 小表廣播場景
圖5中,如果我想知道買家id等於0的用戶在商城裡面買了哪些商品,我們一般會先將這兩個表join起來,然後再用where平台名=」商城」 and buyerID = 0找到符合要求的數據。然而這種join的方式,會導致大量的針對左表的網路I/O。如果要取出的數據量比較大,系統延遲會明顯上升。
這時候,為了提升性能,我們就必須要減少跨機join的網路代價。我們比較推薦應用做如下處理,將左表復制到右表的每一個庫上。這樣,join操作就由分布式join一下變回到本地join,系統的性能就有很大的提升了,如圖6所示。
圖6
【分布式事務套件】
在阿里巴巴的業務體系中存在非常多需要事務類的場景,下單減庫存,賬務,都是事務場景最集中的部分。
而我們處理事務的方法卻和傳統應用處理事務的方案不大一樣,我們非常強調事務的最終一致性和非同步化。利用這種方式,能夠極大地降低分布式系統中鎖持有的時間,從而極大地提升系統性能。
圖7 DRDS分布式事務解決套件
這種處理機制,是我們分布式事務能夠以極低成本大量運行的最核心法門。在DRDS平台內,我們將這些方案產品化,為了DRDS的分布式事務解決套件。
利用他們,能夠讓你以比較低的成本,實現低延遲,高吞吐的分布式事務場景。
DRDS的未來
阿里分布式資料庫服務DRDS上線至今,大家對這款產品的熱情超出了我們的預期,短短半年內已經有幾千個申請。
盡管還在公測期,但是大家就已經把關繫到身家性命的寶貴在線數據業務放到了DRDS上,我能夠感受到這份沉甸甸的信賴,也不想辜負這份信賴。
經過阿里內部幾千個應用的不斷歷練,DRDS已經積累出一套強大的分布式SQL執行引擎和和一整套分布式事務套件。
我也相信,這些積累能夠讓用戶在基本保持單機資料庫的使用習慣的前提下,享受到分布式資料庫高性能可擴展的好處。
在平時的DRDS支持過程中,我面對最多的問題就是,DRDS能不能夠在不改變任何原有業務邏輯和代碼的前提下,實現可自由伸縮和擴展呢?十分可惜的是,關系資料庫發展至今,還沒有找到既能保留傳統資料庫一切特性,又能實現高性能可擴展資料庫的方法。
然而,雖不能至,吾心嚮往之!我們會以「可擴展,高性能」為產品核心,堅定地走在追尋聖杯的路上,並堅信最終我們一定能夠找尋到它神聖的所在。
作者簡介:王晶昱,花名沈詢,阿里巴巴資深技術專家。目前主要負責阿里的分布式資料庫DRDS(TDDL)和阿里的分布式消息服務ONS(RocketMQ/Notify)兩個系統。
㈦ 簡述分布式資料庫的模式結構
分布式資料庫系統是在集中式資料庫系統的基礎上發展來的。是資料庫技術與網路技術結合的產物。什麼是分布式資料庫: 分布式資料庫系統是在集中式資料庫系統的基礎上發展來的。是資料庫技術與網路技術結合的產物。分布式資料庫系統有兩種:一種是物理上分布的,但邏輯上卻是集中的。這種分布式資料庫只適宜用途比較單一的、不大的單位或部門。另一種分布式資料庫系統在物理上和邏輯上都是分布的,也就是所謂聯邦式分布資料庫系統。由於組成聯邦的各個子資料庫系統是相對「自治」的,這種系統可以容納多種不同用途的、差異較大的資料庫,比較適宜於大范圍內資料庫的集成。分布式資料庫系統(DDBS)包含分布式資料庫管理系統(DDBMS)和分布式資料庫(DDB)。在分布式資料庫系統中,一個應用程序可以對資料庫進行透明操作,資料庫中的數據分別在不同的局部資料庫中存儲、由不同的DBMS進行管理、在不同的機器上運行、由不同的操作系統支持、被不同的通信網路連接在一起。一個分布式資料庫在邏輯上是一個統一的整體:即在用戶面前為單個邏輯資料庫,在物理上則是分別存儲在不同的物理節點上。一個應用程序通過網路的連接可以訪問分布在不同地理位置的資料庫。它的分布性表現在資料庫中的數據不是存儲在同一場地。更確切地講,不存儲在同一計算機的存儲設備上。 這就是與集中式資料庫的區別。從用戶的角度看,一個分布式資料庫系統在邏輯上和集中式資料庫系統一樣,用戶可以在任何一個場地執行全局應用。就好那些數據是存儲在同一台計算機上,有單個資料庫管理系統(DBMS)管理一樣,用戶並沒有什麼感覺不一樣。分布式資料庫中每一個資料庫伺服器合作地維護全局資料庫的一致性。分布式資料庫系統是一個客戶/伺服器體系結構。
㈧ 誰能給我一個數據倉庫和數據挖掘案例的詳細設計文檔
最好可以問你們老師,或者去相應的網站上去查找。如果你離畢業還早的話,可以去考資料庫系統工程師。相應的教材和資料都可以買到,而且是國家承認的。不過這只是個證書而已,關鍵的以後還是要實踐。通過准備考試,可以打下扎實的基礎,為以後做准備。
另外,資料庫其實也比較枯燥,如果你有決心的話,還是不錯的工作。關鍵的在學校還是要先打好基礎。
有很多這樣的網站,你可以上網去搜索。如果有相應的輔導班,也可以考慮。
資料庫系統工程師級考試大綱
一、考試說明
1.考試要求
(1)掌握計算機體系結構以及各主要部件的性能和基本工作原理;
(2)掌握操作系統、程序設計語言的基礎知識,了解編譯程序的基本知識;
(3)熟練掌握常用數據結構和常用演算法;
(4)熟悉軟體工程和軟體開發項目管理的基礎知識;
(5)熟悉計算機網路的原理和技術;
(6)掌握資料庫原理及基本理論;
(7)掌握常用的大型資料庫管理系統的應用技術;
(8)掌握資料庫應用系統的設計方法和開發過程;
(9)熟悉資料庫系統的管理和維護方法,了解相關的安全技術;
(10)了解資料庫發展趨勢與新技術;
(11)掌握常用信息技術標准、安全性,以及有關法律、法規的基本知識;
(12)了解信息化、計算機應用的基礎知識;
(13)正確閱讀和理解計算機領域的英文資料。
2. 通過本考試的合格人員能參與應用信息系統的規劃、設計、構建、運行和管理,能按照用戶需求,設計、建立、運行、維護高質量的資料庫和數據倉庫;作為數據管理員管理信息系統中的數據資源,作為資料庫管理員建立和維護核心資料庫;擔任資料庫系統有關的技術支持,同時具備一定的網路結構設計及組網能力;具有工程師的實際工作能力和業務水平,能指導計算機技術與軟體專業助理工程師(或技術員)工作。
3. 本考試設置的科目包括
(1)信息系統知識,考試時間為150分鍾,筆試;
(2)資料庫系統設計與管理,考試時間為150分鍾,筆試。
二、考試范圍
考試科目1:信息系統知識
1. 計算機系統知識
1.1 硬體知識
1.1.1 計算機體系結構和主要部件的基本工作原理
·CPU和存儲器的組成、性能、基本工作原理
·常用I/O設備、通信設備的性能,以及基本工作原理
·I/O介面的功能、類型和特點
·CISC/RISC,流水線操作,多處理機,並行處理
1.1.2 存儲系統
·虛擬存儲器基本工作原理,多級存儲體系
·RAID類型和特性
1.1.3 安全性、可靠性與系統性能評測基礎知識
·診斷與容錯
·系統可靠性分析評價
· 計算機系統性能評測方法
1.2 數據結構與演算法
1.2.1 常用數據結構
·數組(靜態數組、動態數組)
·線性表、鏈表(單向鏈表、雙向鏈表、循環鏈表)
·棧和隊列
·樹(二叉樹、查找樹、平衡樹、遍歷樹、堆)、圖、集合的定義、存儲和操作
·Hash(存儲位置計算、碰撞處理)
1.2.2 常用演算法
·排序演算法、查找演算法、數值計算、字元串處理、數據壓縮演算法、遞歸演算法、圖的相關演算法
·演算法與數據結構的關系,演算法效率,演算法設計,演算法描述(流程圖、偽代碼、決策表),演算法的復雜性
1.3 軟體知識
1.3.1 操作系統知識
·操作系統的類型、特徵、地位、內核(中斷控制)、進程、線程概念
·處理機管理(狀態轉換、同步與互斥、信號燈、分時輪轉、搶占、死鎖)
·存儲管理(主存保護、動態連接分配、分段、分頁、虛存)
·設備管理(I/O控制、假離線、磁碟調度)
·文件管理(文件目錄、文件的結構和組織、存取方法、存取控制、恢復處理、共享和安全)
·作業管理(作業調度、作業控制語言(JCL)、多道程序設計)
·漢字處理,多媒體處理,人機界面
·網路操作系統和嵌入式操作系統基礎知識
·操作系統的配置
1.3.2 程序設計語言和語言處理程序的知識
· 匯編、編譯、解釋系統的基礎知識和基本工作原理
· 程序設計語言的基本成分:數據、運算、控制和傳輸,程序調用的實現機制
· 各類程序設計語言的主要特點和適用情況
1.4 計算機網路知識
·網路體系結構(網路拓撲、OSI/RM、基本的網路協議)
·傳輸介質,傳輸技術,傳輸方法,傳輸控制
·常用網路設備和各類通信設備
·Client/Server結構、Browser/Server結構、Browser/Web/Datebase結構
·LAN拓撲,存取控制,LAN的組網,LAN間連接,LAN-WAN連接
·網際網路基礎知識及應用
·網路軟體
·網路管理
·網路性能分析
·網路有關的法律、法規
2. 資料庫技術
2.1 資料庫技術基礎
2.1.1 資料庫模型
·資料庫系統的三級模式(概念模式、外模式、內模式),兩級映像(概念模式/外模式、外模式/內模式)
·資料庫模型:數據模型的組成要素,概念數據模型ER圖(實體、屬性、關系),邏輯數據模型(關系模型、層次模型、網路模型)
2.1.2 資料庫管理系統的功能和特徵
·主要功能(資料庫定義、資料庫操作、資料庫控制、事務管理、用戶視圖)
·特徵(確保數據獨立性、資料庫存取、同時執行過程、排它控制、故障恢復、安全性、完整性)
·RDB(關系資料庫),OODB(面向對象資料庫),ORDB(對象關系資料庫),NDB(網狀資料庫)
·幾種常用Web資料庫的特點
2.1.3 資料庫系統體系結構
· 集中式資料庫系統
· Client/Server資料庫系統
· 並行資料庫系統
· 分布式資料庫系統
· 對象關系資料庫系統
2.2 數據操作
2.2.1 關系運算
·關系代數運算(並、交、差、笛卡兒積、選擇、投影、連接、除)
·元組演算
·完整性約束
2.2.2 關系資料庫標准語言(SQL)
·SQL的功能與特點
·用SQL進行數據定義(表、視圖、索引、約束)
·用SQL進行數據操作(數據檢索、數據插入/刪除/更新、觸發控制)
·安全性和授權
·程序中的API,嵌入SQL
2.3 資料庫的控制功能
·資料庫事務管理(ACID屬性)
·資料庫備份與恢復技術(UNDO、REDO)
·並發控制
2.4 資料庫設計基礎理論
2.4.1 關系資料庫設計
·函數依賴
·規范化(第一範式、第二範式、第三範式、BC範式、第四範式、第五範式)
·模式分解及分解應遵循的原則
2.4.2 對象關系資料庫設計
·嵌套關系、 復雜類型,繼承與引用類型
·與復雜類型有關的查詢
·SQL中的函數與過程
·對象關系
2.5 數據挖掘和數據倉庫基礎知識
·數據挖掘應用和分類
·關聯規則、聚類
·數據倉庫的成分
·數據倉庫的模式
2.6 多媒體基本知識
2.6.1 多媒體技術基本概念
·多媒體系統基礎知識
·常用多媒體文件格式
2.6.2 多媒體壓縮編碼技術
·多媒體壓縮編碼技術
·統計編碼
·預測編碼
·編碼的國際標准
2.6.3多媒體技術應用
·簡單圖形的繪制,圖像文件的處理方法
·音頻和視頻信息的應用
·多媒體應用開發過程
2.7 系統性能知識
·性能計算(響應時間、吞吐量、周轉時間)
·性能指標和性能設計
·性能測試和性能評估
2.8 計算機應用基礎知識
·信息管理、數據處理、輔助設計、科學計算,人工智慧等基礎知識
·遠程通信服務及相關通信協議基礎知識
3. 系統開發和運行維護知識
3.1 軟體工程、軟體過程改進和軟體開發項目管理知識
·軟體工程知識
·軟體開發生命周期階段目標和任務
·軟體開發項目基礎知識(時間管理、成本管理、質量管理、人力資源管理、風險管理等)及其常用管理工具
·主要的軟體開發方法(生命周期法、原型法、面向對象法、CASE)
·軟體開發工具與環境知識
·軟體質量管理基礎知識
·軟體過程改進基礎知識
·軟體開發過程評估、軟體能力成熟度評估的基礎知識
3.2 系統分析基礎知識
·系統分析的目的和任務
·結構化分析方法(數據流圖(DFD)和數據字典(DD),實體關系圖(ERD),描述加工處理的結構化語言)
·統一建模語言(UML)
·系統規格說明書
3.3 系統設計知識
·系統設計的目的和任務
·結構化設計方法和工具(系統流程圖、HIPO圖、控制流程圖)
·系統總體結構設計(總體布局,設計原則,模塊結構設計,數據存取設計,系統配置方案)
·系統詳細設計(代碼設計、資料庫設計、用戶界面設計、處理過程設計)
·系統設計說明書
3.4 系統實施知識
·系統實施的主要任務
·結構化程序設計、面向對象程序設計、可視化程序設計
·程序設計語言的選擇、程序設計風格
·系統測試的目的、類型,系統測試方法(黑盒測試、白盒測試、灰盒測試)
·測試設計和管理(錯誤曲線、錯誤排除、收斂、注入故障、測試試用例設計、系統測試報告)
·系統轉換基礎知識
3.5 系統運行和維護知識
·系統運行管理知識
·系統維護知識
·系統評價知識
4. 安全性知識
·安全性基本概念(網路安全、操作系統安全、資料庫安全)
·計算機病毒的防治,計算機犯罪的防範,容災
·訪問控制、防闖入、安全管理措施
·加密與解密機制
·風險分析、風險類型、抗風險措施和內部控制
5.標准化知識
·標准化意識,標准化的發展,標准出台過程
·國際標准、國家標准、行業標准、企業標准基本知識
·代碼標准、文件格式標准、安全標准軟體開發規范和文檔標准
·標准化機構
6.信息化基礎知識
·信息化意識
·全球信息化趨勢、國家信息化戰略、企業信息化戰略和策略
·有關的法律、法規
·遠程教育、電子商務、電子政務等基礎知識
·企業信息資源管理基礎知識
7.計算機專業英語
·掌握計算機技術的基本詞彙
·能正確閱讀和理解計算機領域的英文資料
考試科目2:資料庫系統設計與管理
1.資料庫設計
1.1理解系統需求說明
·了解用戶需求、確定系統范圍
·確定應用系統資料庫的各種關系
·現有環境與新系統環境的關系
·新系統中的數據項、數據字典、數據流
1.2 系統開發的准備
·選擇開發方法,准備開發環境,制訂開發計劃
1.3 設計系統功能
·選擇系統機構,設計各子系統的功能和介面,設計安全性策略、需求和實現方法,制定詳細的工作流和數據流
1.4 資料庫設計
1.4.1 設計數據模型
·概念結構設計(設計ER模型)
·邏輯結構設計(轉換成DBMS所能接收的數據模型)
·評審設計
1.4.2 物理結構設計
·設計方法與內容
·存取方法的選擇
·評審設計與性能預測
1.4.3 資料庫實施與維護
·數據載入與應用程序調試
·資料庫試運行
·資料庫運行與維護
1.4.4 資料庫的保護
·資料庫的備份與恢復
·資料庫的安全性
·資料庫的完整性
·資料庫的並發控制
1.5 編寫外部設計文檔
·編寫系統說明書(系統配置圖、各子系統關系圖、系統流程圖,系統功能說明、輸入輸出規格說明、數據規格說明、用戶手冊框架)
·設計系統測試要求
1.6 設計評審
2. 資料庫應用系統設計
2.1 設計資料庫應用系統結構
·信息系統的架構(如Client/Server)與DBMS
·多用戶資料庫環境(文件伺服器體系結構、Client/Server體系結構)
·大規模資料庫和並行計算機體系結構(SMP、MPP)
·中間件角色和相關工具
·按構件分解,確定構件功能規格以及構件之間的介面
2.2 設計輸入輸出
·屏幕界面設計,設計輸入輸出檢查方法和檢查信息
·資料庫交互與連接(掌握C程序設計語言,以及Java、Visual Basic、Visual C++、PowerBuilder、Delphi中任一種開發工具與資料庫互連的方法(如何與資料庫伺服器溝通))
2.3 設計物理數據
·分析事務在資料庫上運行的頻率和性能要求,確定邏輯數據組織方式、存儲介質,設計索引結構和處理方式
·將邏輯數據結構變換成物理數據結構,計算容量(空間代價),確定存取方法(時間效率)、系統配置(維護代價)並進行優化
2.4 設計安全體系
·明確安全等級
·資料庫的登錄方式
·資料庫訪問
·許可(對象許可、命令許可、授權許可的方法)
2.5 應用程序開發
2.5.1 應用程序開發
·選擇應用程序開發平台
·系統實施順序
·框架開發
·基礎小組的程序開發
·源代碼控制
·版本控制
2.5.2 模塊劃分(原則、方法、標准)
2.5.3 編寫程序設計文檔
·模塊規格說明書(功能和介面說明、程序處理邏輯的描述、輸入輸出數據格式的描述)
·測試要求說明書(測試類型和目標,測試用例,測試方法)
2.5.4 程序設計評審
2.6 編寫應用系統設計文檔
·系統配置說明、構件劃分圖、構件間的介面、構件處理說明、屏幕設計文檔、報表設計文檔、程序設計文檔、文件設計文檔、資料庫設計文檔
2.7 設計評審
3. 資料庫應用系統實施
3.1 整個系統的配置與管理
3.2 常用資料庫管理系統的應用(SQL Server、Oracle、Sybase、DB2、Access或Visual Foxpro)
·創建資料庫
·創建表、創建索引、創建視圖、創建約束、創建UDDT(用戶自定義類型)
·創建和管理觸發器
·建立安全體系
3.3 資料庫應用系統安裝
·擬定系統安裝計劃(考慮費用、客戶關系、雇員關系、後勤關系和風險等因素)
·擬定人力資源使用計劃(組織機構安排的合理性)
·直接安裝(安裝新系統並使系統快速進入運行狀態)
·並行安裝(新舊系統並行運行一段時間)
·階段安裝(經過一系列的步驟和階段使新系統各部分逐步投入運行)
3.4 資料庫應用系統測試
·擬定測試目標、計劃、方法與步驟
·數據載入,准備測試數據
·指導應用程序員進行模塊測試進行驗收
·准備系統集成測試環境測試工具
·寫出資料庫運行測試報告
3.5 培訓與用戶支持
4.資料庫系統的運行和管理
4.1 資料庫系統的運行計劃
·運行策略的確定
·確定資料庫系統報警對象和報警方式
·資料庫系統的管理計劃(執行,故障/恢復,安全性,完整性,用戶培訓和維護)
4.2 資料庫系統的運行和維護
·新舊系統的轉換
·收集和分析報警數據(執行報警、故障報警、安全報警)
·連續穩定的運行
·資料庫維護(資料庫重構、安全視圖的評價和驗證、文檔維護)
·資料庫系統的運行統計(收集、分析、提出改進措施)
·關於運行標准和標准改進一致性的建議
·資料庫系統的審計
4.3 資料庫管理
·數據字典和數據倉庫的管理
·數據完整性維護和管理(實體完整性、參照完整性)
·資料庫物理結構的管理(保證數據不推遲訪問)
·資料庫空間及碎片管理
·備份和恢復(順序、日誌(審計痕跡)、檢查點)
·死鎖管理(集中式、分布式)
·並發控制(可串列性、鎖機制、時間戳、優化)
·數據安全性管理(加密、安全、訪問控制、視圖、有效性確認規則)
·資料庫管理員(DBA)職責
4.4 性能調整
·SQL語句的編碼檢驗
·表設計的評價
·索引的改進
·物理分配的改進
·設備增強
·資料庫性能優化
4.5 用戶支持
·用戶培訓
·售後服務
5. SQL
5.1 資料庫語言
·資料庫語言的要素
·資料庫語言的使用方式(互動式和嵌入式)
5.2 SQL概述
·SQL語句的特徵
·SQL語句的基本成分
5.3 資料庫定義
·創建資料庫(Create Datebase)、創建表(Create Table)
·定義數據完整性
·修改表(Alter Table)、刪除表(Drop Table)
·定義索引(Create Index)、刪除索引(Drop Index)
·定義視圖(Create View)、刪除視圖(Drop View)、更新視圖
5.4 數據操作
·Select語句的基本機構
·簡單查詢
·SQL中的選擇、投影
·字元串比較,涉及空值的比較
·日期時間,布爾值,輸出排序
·多表查詢
·避免屬性歧義
·SQL中的連接、並、交、差
·SQL中的元組變數
·子查詢
5.5 完整性控制與安全機制
·主鍵(Primary Key)約束
·外鍵(Foreign Key)約束
·屬性值上的約束(Null、Check、Create Domain)
·全局約束(Create Assertions)
·許可權、授權(Grant)、銷權(Revoke)
5.6 創建觸發器(Create Trigger)
5.7 SQL使用方式
·互動式SQL
·嵌入式SQL
·SQL與宿主語言介面(Declare、共享變數、游標、卷游標)
·動態SQL
·API
5.8 SQL 標准化
6. 網路環境下的資料庫
6.1 分布式資料庫
6.1.1 分布式資料庫的概念
·分布式資料庫的特點與目標
6.1.2 分布式資料庫的體系結構
·分布式資料庫的模式結構
·數據分布的策略(數據分片、分布透明性)
·分布式資料庫管理系統
6.1.3 分布式查詢處理和優化
6.1.4 分布式事務管理
·分布式資料庫的恢復(故障、恢復、2段提交、3段提交)
·分布式資料庫的透明性(局部、分裂、復制、處理、並發、執行)
6.1.5 分布式資料庫系統的應用
6.2 網路環境下資料庫系統的設計與實施
·數據的分布設計
·負載均衡設計
·資料庫互連技術
6.3 面向Web的DBMS技術
·三層體系結構
·動態Web網頁
·ASP、JSP、XML的應用
7.資料庫的安全性
7.1 安全性策略的理解
·資料庫視圖的安全性策略
·數據的安全級別(最重要的、重要的、注意、選擇)
7.2 資料庫安全測量
·用戶訪問控制(採用口令等)
·程序訪問控制(包含在程序中的SQL命令限制)
·表的訪問控制(視圖機制)
·控制訪問的函數和操作
·外部存儲數據的加密與解密
8. 資料庫發展趨勢與新技術
8.1 面向對象資料庫(OODBMS)
8.1.1 OODBMS的特徵
8.1.2 面向對象數據模型
·對象結構、對象類、繼承與多重繼承、對象標識、對象包含、對象嵌套
8.1.3 面向對象資料庫語言
8.1.4 對象關系資料庫系統(ORDBMS)
·嵌套關系
·復雜類型
·繼承、引用類型
·與復雜類型有關的查詢
·函數與過程
·面向對象與對象關系
·ORDBMS應用領域
8.2 企業資源計劃(ERP)和資料庫
8.2.1 ERP概述
·基本MRP(製造資源計劃)、閉環MRP、ERP
·基本原理、發展趨勢
·ERP設計的總體思路(一個中心、兩類業務、三條干線)
8.2.2 ERP與資料庫
·運行資料庫與ERP數據模型之間的關系
·運行資料庫與ERP資料庫之間的關系
8.2.3 案例分析
8.3 決策支持系統的建立
·決策支持系統的概念
·數據倉庫設計
·數據轉移技術
·聯機分析處理(OLAP)技術
·企業決策支持解決方案
·聯機事務處理(OLTP)
㈨ 什麼叫分布式資料庫
1.分布式資料庫是資料庫的一種,是資料庫技術和網路技術的結合產物。
2.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種。
是的,分布式數據文件便於資料庫的管理維護。