建站
咨詢
售后
建站咨詢
新聞中心
數據庫架構：詳解設計組成及其功能
成都創(chuàng)新互聯"三網合一"的企業(yè)建站思路。企業(yè)可建設擁有電腦版、微信版、手機版的企業(yè)網站。實現跨屏營銷，產品發(fā)布一步更新，電腦網絡+移動網絡一網打盡，滿足企業(yè)的營銷需求！成都創(chuàng)新互聯具備承接各種類型的成都做網站、成都網站建設項目的能力。經過十余年的努力的開拓，為不同行業(yè)的企事業(yè)單位提供了優(yōu)質的服務，并獲得了客戶的一致好評。
隨著互聯網技術的不斷發(fā)展，數據庫建設已經成為了現代企業(yè)信息化建設的重要組成部分。而數據庫架構是數據庫建設中不可或缺的一環(huán)，不僅關系到數據庫的性能、安全、可靠性等方面，還涉及到企業(yè)的核心業(yè)務流程以及信息資源的管理。本文將從以下幾個方面詳解數據庫架構的設計組成及其功能。
一、數據庫架構的基本組成
1. 數據庫管理系統 (DBMS)
數據庫管理系統 (DBMS) 是數據庫架構的基礎組成部分，是指通過軟件或硬件的方式，對大量數據進行組織、管理、存儲和檢索的系統。
常見的 DBMS 有 Oracle、MySQL、SQLServer、PostgreSQL 等，它們都可以通過 SQL 語言來操作數據庫。
2. 數據庫模型
數據庫模型是指對數據進行建模，描述了數據庫中實體、屬性、關系及其對應的操作。
常見的數據庫模型有層次模型、網狀模型、關系模型、對象模型等，其中關系模型是應用最廣泛的數據庫模型。
3. 數據庫實例
數據庫實例是指一個數據庫系統運行時的內存實例，包括了操作系統進程、共享內存區(qū)、數據緩存區(qū)和臨時文件等。它以數據庫管理系統為基礎，實現了數據庫的增刪改查等常用操作。
4. 數據庫對象
數據庫對象是指在數據庫中創(chuàng)建的數據結構，如表、視圖、存儲過程、觸發(fā)器等。數據庫對象的設計直接影響到數據庫的可擴展性、可靠性和性能。
5. 數據庫連接
數據庫連接是指在應用程序和數據庫之間建立的通信鏈路。在數據庫架構中，數據庫連接管理是一項重要的工作，對于提高數據庫性能、穩(wěn)定性具有關鍵作用。
二、數據庫架構的功能及實現
1. 數據庫存儲管理
數據庫存儲管理是指對數據庫中數據進行儲存和管理的過程，包括表空間管理、數據文件管理、數據塊管理、段管理等。通過對存儲管理的優(yōu)化，可以提高數據庫的性能和可靠性，減少數據丟失和損壞的風險。
2. 數據庫備份與恢復
數據庫備份與恢復是指在數據庫運行過程中，將數據庫中的數據和日志文件進行備份，以便于在出現災難性故障時進行恢復。通過備份與恢復的方式，可以有效地減少數據丟失的風險，保障企業(yè)的核心業(yè)務不受影響。
3. 數據庫安全性管理
數據庫安全性管理是指對數據庫中的數據進行安全保護的過程，包括用戶管理、權限管理、數據加密等。通過有效的安全性管理，可以保障企業(yè)的數據安全，避免數據泄露、丟失等問題。
4. 數據庫性能優(yōu)化
數據庫性能優(yōu)化是指通過對數據庫結構、索引、查詢語句等方面的優(yōu)化，提高數據庫的響應速度、并發(fā)處理能力等性能指標。通過性能優(yōu)化，可以加速數據訪問和數據處理，提高企業(yè)的工作效率。
5. 數據庫監(jiān)控與調優(yōu)
數據庫監(jiān)控與調優(yōu)是指對數據庫運行時的性能和狀態(tài)進行監(jiān)控和統計，并進行調優(yōu)操作，提高數據庫的性能和可靠性。通過監(jiān)控和調優(yōu)，可以開發(fā)出更佳的數據庫架構方案，提高數據庫的整體質量。
三、數據庫架構設計的注意事項
盡管數據庫架構的設計組成十分重要，但在設計過程中也有一些需要特別注意的事項，包括：
1. 合理規(guī)劃數據模型，避免數據冗余，確保數據的完整性。
2. 合理安排表空間和磁盤空間，避免空間碎片和存儲性能下降。
3. 合理統計數據，并制定相應的性能優(yōu)化方案。
4. 增強數據庫安全性，為企業(yè)數據提供更好的保障。
5. 良好的數據庫連接管理和數據庫監(jiān)控實踐，實時掌握數據庫運行情況，及時發(fā)現和解決問題。
數據庫架構的設計組成及其功能是十分重要的，也是優(yōu)化數據庫性能和提高數據庫安全性的根本。通過合理的架構設計和優(yōu)化方案，可以更大限度地提高數據庫的性能、安全性和可靠性，為企業(yè)信息化建設提供堅實的保障。
成都網站建設公司-創(chuàng)新互聯,建站經驗豐富以策略為先導10多年以來專注數字化網站建設,提供企業(yè)網站建設,高端網站設計,響應式網站制作,設計師量身打造品牌風格,熱線:028-86922220數據庫系統中的幾種架構及處理方式
來具體說說數據庫集群吧
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( HighCluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)
1、高可用集群(HighCluster)
常見的就是2個節(jié)點做成的HA集群，有很多通俗的不科學的名稱，比如”雙機熱備”, “雙機互備”, “雙機”。高可用集群解決的是保障用戶的應用程序持續(xù)對外提侍正供服務的能力。 (請注意高可用集群既不是用來保護業(yè)務數據的，保護的是用戶的業(yè)務程序對外不間斷提供服務，把因軟件/硬件/人為造成的故障對業(yè)務的影響降低到最小程度)。
2、負載均衡集群(Load Balance Cluster)
負載均衡系統：集群中所有的節(jié)點都處于活動狀態(tài)，它們分攤系統的工作負載。一般Web服務器集群、數據庫集群和應用服務器集群都屬于這種類型。
負載均衡集群一般用于相應網絡請求的網頁服務器，數據庫服務器。這種集群可以在接到請求時老世悔，檢查接受請求較少，不繁忙的服務器，并把請求轉到這些服務器上。從檢查其他服務器狀態(tài)這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。
3、科學計算集群(High Performance Computing Cluster)
高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力于提供單個計算機所不能提供的強大的計算能力。
高性能計算分類：
3.1、高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以并行的子任務，而且各個子任務彼此間沒有什么關聯。象在家搜尋外星人（ SETI@HOME _ Search forat Home ）就是這一類型應用。
這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的服務器將一組數據和數據模式發(fā)給Internet上參加SETI的計算節(jié)點，計算節(jié)點在給定的數據上用給定的模式進行搜索，然后將搜索的結果發(fā)給服務器。服務器負責將從各個計算節(jié)點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特征是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。
所謂的Internet計算都屬于這一類。按照 Flynn的分類，高吞吐計算屬于返頌SIMD（Single Instruction/Multiple Data）的范疇。
3.2、分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干并行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬于MIMD（Multiple Instruction/Multiple Data）的范疇。
下面說說這幾種集群的應用場景：
高可用集群這里不多作說明。
想Dubbo是比較偏向于負載均衡集群，用過的猿友應該知道（不知道的可以自行了解一下），Dubbo同一個服務是可以有多個提供者的，當一個消費者過來，它要消費那個提供者，這里是有負載均衡機制在里面的。
搜索引擎比較偏向于科學計算集群的分布計算。
而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。
我們以Dubbo為例：
集群容錯（bbo.io/UserGuide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）
Dubbo提供了這些容錯策略：
集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展
Failover Cluster
失敗自動切換，當出現失敗，重試其它服務器。(缺省)
通常用于讀操作，但重試會帶來更長延遲。
可通過retries=”2″來設置重試次數(不含之一次)。
Failfast Cluster
快速失敗，只發(fā)起一次調用，失敗立即報錯。
通常用于非冪等性的寫操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。
通常用于寫入審計日志等操作。
Failback Cluster
失敗自動恢復，后臺記錄失敗請求，定時重發(fā)。
通常用于消息通知操作。
Forking Cluster
并行調用多個服務器，只要一個成功即返回。
通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks=”2″來設置更大并行數。
Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)
通常用于通知所有提供者更新緩存或日志等本地資源信息。
負載均衡（bbo.io/UserGuide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）
Dubbo提供了這些負載均衡策略：
Random LoadBalance
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重后也比較均勻，有利于動態(tài)調整提供者權重。
RoundRobin LoadBalance
輪循，按公約后的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前后計數差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數差會越大。
LoadBalance
一致性Hash，相同參數的請求總是發(fā)到同一提供者。
當某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點，平攤到其它提供者，不會引起劇烈變動。
算法參見：en..org/wiki/Consistent_hashing。
缺省只對之一個參數Hash，如果要修改，請配置
缺省用160份虛擬節(jié)點，如果要修改，請配置
數據庫架構選型與落地，看這篇就夠了
隨著時間和業(yè)務的發(fā)展，數據庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的
磁盤
、
IO
、
系統開銷
，甚至
性能
上的瓶頸，而單臺服務器的
資源終究是有限
的。
因此在面對業(yè)務擴張過程中，應用程序對數據庫系統的
健壯性
，
安全性
，
擴展性
提出了更高的要求。
以下，我從數據庫架構、選型與落地來讓大家入門。
數據庫會面臨什么樣的挑戰(zhàn)呢？
業(yè)務剛開始我們只用單機數據庫就夠了，但隨著業(yè)務增長，數據規(guī)模和用戶規(guī)模上升，這個時候數據庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。
為了解決上述的各種問題，數據庫衍生了出不同的架構來解決不同的場景需求。
將數據庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用于面對讀請求的增加。
這個模式也就是常說的讀寫分離，針對的是小規(guī)模數據，而且存在大量讀操作的場景。
因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以
切換為主庫提供寫入
，所以這個架構也可以提高數據庫系統的
安全性
和
可用性
；
優(yōu)點：
缺點：
在數據庫遇到
IO瓶頸
過程中，如果IO集中在某一塊的業(yè)務中，這個時候可以考慮的就是垂直分庫，將熱點業(yè)務拆分出去，避免由
熱點業(yè)務
的
密集IO請求
影響了其他正常業(yè)務，所以垂直分庫也叫
業(yè)務分庫
。
優(yōu)點：
缺點：
在數據庫遇到存儲瓶頸的時候，由于數據量過大造成索引性能下降。
這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規(guī)則，切分到多張表里面去。
但是這些表還是在同一個庫中，所以庫級別的數據庫操作還是有IO瓶頸（單個服務器的IO有上限）。
所以水平分表主要還是針對
數據量較大
，整體業(yè)務
請求量較低
的場景。
優(yōu)點：
缺點：
四、分庫分表
在數據庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規(guī)模的業(yè)務請求，這個時候單庫的IO上限會限制處理效率。
所以需要將單張表的數據切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數據不同。
分庫分表能夠有效地緩解單機和單庫的
性能瓶頸和壓力
，突破IO、連接數、硬件資源等的瓶頸。
優(yōu)點：
缺點：
注：分庫還是分表核心關鍵是有沒有IO瓶頸
。
分片方式都有什么呢？
RANGE（范圍分片）
將業(yè)務表中的某個
關鍵字段排序
后，按照順序從0到10000一個表，10001到20230一個表。最常見的就是
按照時間切分
（月表、年表）。
比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是采用這種方式。
優(yōu)點：
缺點：
HASH（哈希分片）
將訂單作為主表，然后將其相關的業(yè)務表作為附表，取用戶id然后
hash取模
，分配到不同的數據表或者數據庫上。
優(yōu)點：
缺點：
講到這里，我們已經知道數據庫有哪些架構，解決的是哪些問題，因此，
我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構
。
那么，我們應該如何選擇數據庫架構呢？
雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的數據庫系統，但是架構選擇合適才是最重要的。
混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰(zhàn)，你以為的完美架構，背后其實有著更多的坑。
1、對事務支持
分庫分表后（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴數據庫本身的分布式事務管理功能去執(zhí)行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。
2、多庫結果并
（group by，order by）
由于數據分布于不同的數據庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果并的查詢業(yè)務都需要采用數據清洗、同步等其他手段處理（TIDB、KUDU等）。
3、數據延遲
主從架構下的多副本機制和水平分庫后的聚合庫都會存在主數據和副本數據之間的延遲問題。
4、跨庫join
分庫分表后表之間的關聯操作將受到限制，我們無法join位于不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業(yè)務，可能需要多次查詢才能完成。
5、分片擴容
水平分片之后，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。
6、ID生成
分庫分表后由于數據庫獨立，原有的基于數據庫自增ID將無法再使用，這個時候需要采用其他外部的ID生成方案。
一、應用層依賴類（JDBC）
這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的
sharding-jdbc
、蘑菇街的TSharding等。
此類中間件的基本思路就是重新實現JDBC的API，通過重新實現
DataSource
、
PrepareStatement
等操作數據庫的接口，讓應用層在
基本
不改變業(yè)務代碼的情況下透明地實現分庫分表的能力。
中間件給上層應用提供熟悉的JDBC API，內部通過
sql解析
、
sql重寫
、
sql路由
等一系列的準備工作獲取真正可執(zhí)行的sql，然后底層再按照傳統的方法（比如數據庫連接池）獲取物理連接來執(zhí)行sql，最后把數據
結果合并
處理成ResultSet返回給應用層。
優(yōu)點
缺點
二、中間層代理類（Proxy）
這類分庫分表中間件的核心原理是在應用和數據庫的連接之間搭起一個
代理層
，上層應用以
標準的MySQL協議
來連接代理層，然后代理層負責
轉發(fā)請求
到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。
所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式數據庫，自然也天然
支持所有的編程語言
。
在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講數據庫代理層轉發(fā)的就是MySQL協議請求，就像Nginx轉發(fā)的是Http協議請求。
比較有代表性的產品有開創(chuàng)性質的Amoeba、阿里開源的Cobar、社區(qū)發(fā)展比較好的
Mycat
（基于Cobar開發(fā)）等。
優(yōu)點
缺點
JDBC方案
：無中心化架構，兼容市面上大多數關系型數據庫，適用于開發(fā)高性能的輕量級 OLTP 應用（面向前臺）。
Proxy方案
：提供靜態(tài)入口以及異構語言的支持，適用于 OLAP 應用（面向后臺）以及對分片數據庫進行管理和運維的場景。
混合方案
：在大型復雜系統中存在面向C端用戶的前臺應用，也有面向企業(yè)分析的后臺應用，這個時候就可以采用混合模式。
JDBC 采用無中心化架構，適用于 Java 開發(fā)的高性能的輕量級 OLTP 應用；Proxy 提供靜態(tài)入口以及異構語言的支持，適用于 OLAP 應用以及對分片數據庫進行管理和運維的場景。
ShardingSphere是一套開源的分布式數據庫中間件解決方案組成的生態(tài)圈，它由
Sharding-JDBC
、
Sharding-Proxy
和
Sharding-Sidecar
（計劃中）這3款相互獨立的產品組成，他們均提供標準化的數據分片、分布式事務和數據庫治理功能，可適用于如Java同構、異構語言、容器、云原生等各種多樣化的應用場景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位為透明化的
數據庫代理端
，提供封裝了
數據庫二進制協議的服務端版本
，用于完成對
異構語言的支持
。
目前已提供MySQL版本，它可以使用
任何兼容MySQL協議的訪問客戶端
(如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。
向
應用程序完全透明
，可直接當做MySQL使用。
適用于任何兼容MySQL協議的客戶端。
Sharding-JDBC
定位為
輕量級Java框架
，在Java的JDBC層提供的額外服務。 它使用客戶端直連數據庫，以jar包形式提供服務，無需額外部署和依賴，可理解為
增強版的JDBC驅動，完全兼容JDBC和各種ORM框架
。
以電商SaaS系統為例，前臺應用采用Sharding-JDBC，根據業(yè)務場景的差異主要分為三種方案。
分庫（用戶）
問題解析：頭部企業(yè)日活高并發(fā)高，單獨分庫避免干擾其他企業(yè)用戶，用戶數據的增長緩慢可以不分表。
拆分維度：企業(yè)ID分庫
拆分策略：頭部企業(yè)單獨庫、非頭部企業(yè)一個庫
分庫分表（訂單）
問題解析：訂單數據增長速度較快，在分庫之余需要分表。
拆分維度：企業(yè)ID分庫、用戶ID分表
拆分策略：頭部企業(yè)單獨庫、非頭部企業(yè)一個庫，分庫之后用戶ID取模拆分表
單庫分表（附件）
問題解析：附件數據特點是并發(fā)量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。
拆分維度：用戶ID分表
拆分策略：用戶ID取模分表
問題一：分布式事務
分布式事務過于復雜也是分布式系統最難處理的問題，由于篇幅有限，后續(xù)會開篇專講這一塊內容。
問題二：分布式ID
問題三：跨片查詢
舉個例子，以用戶id分片之后，需要根據企業(yè)id查詢企業(yè)所有用戶信息。
sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是采用同時查詢多個分片的數據，然后聚合結果返回，這個方式對資源耗費比較大，特別是對數據庫連接資源的消耗。
假設分4個數據庫，8個表，則sharding會同時發(fā)出32個SQL去查詢。一下子消耗掉了32個連接；
特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節(jié)點，這個時候兩個節(jié)點同時查詢的話，就會遇到數據庫連接數上限問題（mysql默認100連接數）
問題四：分片擴容
隨著數據增長，每個片區(qū)的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由于增加了片區(qū)，原先的hash規(guī)則也跟著變化，造成了需要將舊數據做遷移。
假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想象的。
問題五：一致性哈希
首先，求出每個
服務器的hash值
，將其配置到一個
0~2^n 的圓環(huán)上
（n通常取32）
其次，用同樣的方法求出待
存儲對象的主鍵 hash值
，也將其配置到這個圓環(huán)上。
然后，從數據映射到的位置開始順時針查找，將數據分布到找到的之一個服務器節(jié)點上。
一致性hash的優(yōu)點在于加入和刪除節(jié)點時只會影響到在哈希環(huán)中相鄰的節(jié)點，而對其他節(jié)點沒有影響。
所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。
好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是數據庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。
老規(guī)矩，一鍵三連，日入兩千，點贊在看，年薪百萬！
本文作者：Jensen
7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。
曾涉獵航空、電信、IoT、垂直電商產品研發(fā)，現就職于某知名電商企業(yè)。
技術公眾號
【架構師修行錄】
號主，專注于分享日常架構、技術、職場干貨，Java Goals：架構師。
交個朋友，一起成長！
如何描述數據庫的架構的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于如何描述數據庫的架構,數據庫架構：詳解設計組成及其功能。,數據庫系統中的幾種架構及處理方式,數據庫架構選型與落地，看這篇就夠了的信息別忘了在本站進行查找喔。
成都創(chuàng)新互聯科技有限公司，經過多年的不懈努力，公司現已經成為一家專業(yè)從事IT產品開發(fā)和營銷公司。廣泛應用于計算機網絡、設計、SEO優(yōu)化、關鍵詞排名等多種行業(yè)！
文章題目：數據庫架構：詳解設計組成及其功能。(如何描述數據庫的架構)
本文鏈接：http://m.5511xx.com/article/dpsshsc.html
