資料庫設計架構

① 資料庫表結構設計重要嗎

資料庫表結構設計重要。
當在決定開發一個資料庫管理項目時，最先著手的工作就應是資料庫表結構的設計。資料庫表結構的設計是開發資料庫管理項目的基石，一個糟糕的表結構設計，可能會嚴重延誤項目開發周期，使大量的勞動時間為此付之東流。表結構設計是資料庫邏輯設計的重要組成部分，會直接影響到資料庫的性能。
設計資料庫表的注意事項：不應該針對整個系統進行資料庫設計，而應該根據系統架構中的組件劃分，針對每個組件所處理的業務進行組件單元的資料庫設計；不同組件間所對應的資料庫表之間的關聯應盡可能減少，如果不同組件間的表需要外鍵關聯也盡量不要創建外鍵關聯，而只是記錄關聯表的一個主鍵，確保組件對應的表之間的獨立性，為系統或表結構的重構提供可能性。

② 資料庫架構選型與落地，看這篇就夠了

隨著時間和業務的發展，資料庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的 磁碟 、 IO 、 系統開銷 ，甚至 性能 上的瓶頸，而單台伺服器的 資源終究是有限 的。

因此在面對業務擴張過程中，應用程序對資料庫系統的 健壯性 ， 安全性 ， 擴展性 提出了更高的要求。

以下，我從資料庫架構、選型與落地來讓大家入門。

資料庫會面臨什麼樣的挑戰呢？

業務剛開始我們只用單機資料庫就夠了，但隨著業務增長，數據規模和用戶規模上升，這個時候資料庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。

為了解決上述的各種問題，資料庫衍生了出不同的架構來解決不同的場景需求。

將資料庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用於面對讀請求的增加。

這個模式也就是常說的讀寫分離，針對的是小規模數據，而且存在大量讀操作的場景。

因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以 切換為主庫提供寫入 ，所以這個架構也可以提高資料庫系統的 安全性 和 可用性 ；

優點：

缺點：

在資料庫遇到 IO瓶頸 過程中，如果IO集中在某一塊的業務中，這個時候可以考慮的就是垂直分庫，將熱點業務拆分出去，避免由 熱點業務 的 密集IO請求 影響了其他正常業務，所以垂直分庫也叫 業務分庫 。

優點：

缺點：

在資料庫遇到存儲瓶頸的時候，由於數據量過大造成索引性能下降。

這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規則，切分到多張表裡面去。

但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸（單個伺服器的IO有上限）。

所以水平分表主要還是針對 數據量較大 ，整體業務 請求量較低 的場景。

優點：

缺點：

四、分庫分表

在資料庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規模的業務請求，這個時候單庫的IO上限會限制處理效率。

所以需要將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。

分庫分表能夠有效地緩解單機和單庫的 性能瓶頸和壓力 ，突破IO、連接數、硬體資源等的瓶頸。

優點：

缺點：

註：分庫還是分表核心關鍵是有沒有IO瓶頸 。

分片方式都有什麼呢？

RANGE（范圍分片）

將業務表中的某個 關鍵欄位排序 後，按照順序從0到10000一個表，10001到20000一個表。最常見的就是 按照時間切分 （月表、年表）。

比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是採用這種方式。

優點：

缺點：

HASH（哈希分片）

將訂單作為主表，然後將其相關的業務表作為附表，取用戶id然後 hash取模 ，分配到不同的數據表或者資料庫上。

優點：

缺點：

講到這里，我們已經知道資料庫有哪些架構，解決的是哪些問題，因此， 我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構 。

那麼，我們應該如何選擇資料庫架構呢？

雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的資料庫系統，但是架構選擇合適才是最重要的。

混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰，你以為的完美架構，背後其實有著更多的坑。

1、對事務支持

分庫分表後（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。

2、多庫結果集合並 （group by，order by）

由於數據分布於不同的資料庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果集合並的查詢業務都需要採用數據清洗、同步等其他手段處理（TIDB、KUDU等）。

3、數據延遲

主從架構下的多副本機制和水平分庫後的聚合庫都會存在主數據和副本數據之間的延遲問題。

4、跨庫join

分庫分表後表之間的關聯操作將受到限制，我們無法join位於不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。

5、分片擴容

水平分片之後，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。

6、ID生成

分庫分表後由於資料庫獨立，原有的基於資料庫自增ID將無法再使用，這個時候需要採用其他外部的ID生成方案。

一、應用層依賴類（JDBC）

這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以java為例），比如知名的TDDL、當當開源的 sharding-jdbc 、蘑菇街的TSharding等。

此類中間件的基本思路就是重新實現JDBC的API，通過重新實現 DataSource 、 PrepareStatement 等操作資料庫的介面，讓應用層在 基本 不改變業務代碼的情況下透明地實現分庫分表的能力。

中間件給上層應用提供熟悉的JDBC API，內部通過 sql解析 、 sql重寫 、 sql路由 等一系列的准備工作獲取真正可執行的sql，然後底層再按照傳統的方法（比如資料庫連接池）獲取物理連接來執行sql，最後把數據 結果合並 處理成ResultSet返回給應用層。

優點

缺點

二、中間層代理類（Proxy）

這類分庫分表中間件的核心原理是在應用和資料庫的連接之間搭起一個 代理層 ，上層應用以 標準的MySQL協議 來連接代理層，然後代理層負責 轉發請求 到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。

所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式資料庫，自然也天然 支持所有的編程語言 。

在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講資料庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。

比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的 Mycat （基於Cobar開發）等。

優點

缺點

JDBC方案 ：無中心化架構，兼容市面上大多數關系型資料庫，適用於開發高性能的輕量級 OLTP 應用（面向前台）。

Proxy方案 ：提供靜態入口以及異構語言的支持，適用於 OLAP 應用（面向後台）以及對分片資料庫進行管理和運維的場景。

混合方案 ：在大型復雜系統中存在面向C端用戶的前台應用，也有面向企業分析的後台應用，這個時候就可以採用混合模式。

JDBC 採用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片資料庫進行管理和運維的場景。

ShardingSphere是一套開源的分布式資料庫中間件解決方案組成的生態圈，它由 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，根據業務場景的差異主要分為三種方案。

分庫（用戶）

問題解析：頭部企業日活高並發高，單獨分庫避免干擾其他企業用戶，用戶數據的增長緩慢可以不分表。

拆分維度：企業ID分庫

拆分策略：頭部企業單獨庫、非頭部企業一個庫

分庫分表（訂單）

問題解析：訂單數據增長速度較快，在分庫之餘需要分表。

拆分維度：企業ID分庫、用戶ID分表

拆分策略：頭部企業單獨庫、非頭部企業一個庫，分庫之後用戶ID取模拆分表

單庫分表（附件）

問題解析：附件數據特點是並發量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。

拆分維度：用戶ID分表

拆分策略：用戶ID取模分表

問題一：分布式事務

分布式事務過於復雜也是分布式系統最難處理的問題，由於篇幅有限，後續會開篇專講這一塊內容。

問題二：分布式ID

問題三：跨片查詢

舉個例子，以用戶id分片之後，需要根據企業id查詢企業所有用戶信息。

sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是採用同時查詢多個分片的數據，然後聚合結果返回，這個方式對資源耗費比較大，特別是對資料庫連接資源的消耗。

假設分4個資料庫，8個表，則sharding會同時發出32個SQL去查詢。一下子消耗掉了32個連接；

特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節點，這個時候兩個節點同時查詢的話，就會遇到資料庫連接數上限問題（mysql默認100連接數）

問題四：分片擴容

隨著數據增長，每個片區的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由於增加了片區，原先的hash規則也跟著變化，造成了需要將舊數據做遷移。

假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想像的。

問題五：一致性哈希

首先，求出每個 伺服器的hash值 ，將其配置到一個 0~2^n 的圓環上 （n通常取32）

其次，用同樣的方法求出待 存儲對象的主鍵 hash值 ，也將其配置到這個圓環上。

然後，從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。

一致性hash的優點在於加入和刪除節點時只會影響到在哈希環中相鄰的節點，而對其他節點沒有影響。

所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。

好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是資料庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。

老規矩，一鍵三連，日入兩千，點贊在看，年薪百萬！

本文作者：Jensen

7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。

曾涉獵航空、電信、IoT、垂直電商產品研發，現就職於某知名電商企業。

技術公眾號 【架構師修行錄】 號主，專注於分享日常架構、技術、職場干貨，Java Goals：架構師。

交個朋友，一起成長！

③ 資料庫架構是什麼

問題一：sql server中的架構是什麼意思? 通俗點說就是一個組，裡面可以存放表、視圖、存儲過程等
主要是用於許可權控制安全控制的

問題二：什麼是架構，SQL中的架構有哪些 架構(Schema)是形成單個命名空間的資料庫實體的 *** 。
命名空間是一個 *** ，其中每個元素的名稱都是唯一的。
可以將架構看成一個存放資料庫中對象的一個容器。
架構實際上在sqlserver2000中就已經存在，當我們使用查詢分析器去查詢一個表的時候，一個完整的表的名稱應該包括伺服器名.資料庫名.用戶名.對象名，而在sqlserver2005中一個表的完全限定名稱應該為伺服器名.資料庫名.架構名.對象名
在2000中，假如有一個賬戶tt在test資料庫中創建了一張表table1的時候，在伺服器上對查詢的語句應為select * from test.tt.table1,也就是說，在sqlserver 2000中一張表所屬的架構默認就是表的創建者的登錄名稱，用戶可以和修改他所創建的所有資料庫對象。

問題三：資料庫架構是什麼 參考有一個聲音再也不能的在耳邊響起，有一雙手再也握不住那手心的溫度與舒適。

問題四：數據架構是什麼 數據架構即資料庫架構

資料庫是相關數據的 *** ，一個資料庫含有各種成分，包括表、記錄、欄位、索引等。
1．資料庫(Database)
Visual Basic中使用的資料庫是關系型資料庫(Relational Database)。一個資料庫由一個或一組數據表組成。每個資料庫都以文件的形式存放在磁碟上，即對應於一個物理文件。不同的資料庫，與物理文件對應的方式也不一樣。對於dBASE,FoxPro和Paradox格式的資料庫來說，一個數據表就是一個單獨的資料庫文件，而對於Microsoft Access、Btrieve格式的資料庫來說，一個資料庫文件可以含有多個數據表。
2．數據表(Table)
簡稱表，由一組數據記錄組成，資料庫中的數據是以表為單位進行組織的。一個表是一組相關的按行排列的數據；每個表中都含有相同類型的信息。表實際上是一個二維表格，例如，一個班所有學生的考試成績，可以存放在一個表中，表中的每一行對應一個學生，這一行包括學生的學號，姓名及各門課程成績。
3．記錄(Record)
表中的每一行稱為一個記消蘆錄，它由若干個欄位組成。
4．欄位(Field)
也稱域。表中的每一列稱為一個欄位。每個欄位都有相應的描述信息，如數據類型、數據寬度等。
5．索引(Index)
為了提高訪問資料庫的效率，可以對資料庫使用索引。當資料庫較大時，為了查找指定的記錄，則使用索引和不使用索引的效困鬥率有很大差別。索引實際上是一種特殊類型的表，其中含有關鍵欄位的值(由用戶定義)和指向實際記錄位置的指針，這些值和指針按照特定的順序(也由用戶定義)存儲，從而可以以較快的速度查找到所需要的數據記錄。
6．查詢(Query)
一條SQL(結構化查詢語言)命令，用來從一個或多個表中獲取一組指定的記錄，或者對某個表執行指定的操作。當從資料庫中讀取數據時，往往希望讀出的數據符合某些條件，並且能按某個欄位排序。使用SQL，可以使這一操作容易實現而且更加有效。SQL是非過程化語言(有人稱為第四代語言)，在用它查找指定的記錄時，只需指出做什麼，不必說明汪橋磨如何做。每個語句可以看作是一個查詢(query)，根據這個查詢，可以得到需要的查詢結果。
7．過濾器(Filter)
過濾器是資料庫的一個組成部分，它把索引和排序結合起來，用來設置條件，然後根據給定的條件輸出所需要的數據。
8.視圖(view)
數據的視圖指的是查找到(或者處理)的記錄數和顯示(或者進行處理)這些記錄的順序。在一般情況下，視圖由過濾器和索引控制

問題五：資料庫中的文件組和架構有什麼不同？兩者之間的關系是什麼？ 文件組 是 管理 物理文件的. 多個物理文件, 放在一個組裡面
架構 不知道你指的是不是 Schema.
如果是的話。

架構 是 邏輯上面的, 一個資料庫， 可以劃分為多個 架構， 每個 架構 存儲其獨有的業務數據。
SQL Server 默認使用一個 名為 dbo 的 構架。

問題六：資料庫-架構和資料庫-管理指的是什麼 資料庫架構：
下面是基於SQLserver資料庫來談的。貳
SQLServer經過這些年的發展，其實已經有很多很好的技術可以使用，如Replication、SSB、Cluster、Mirroring等（可以參考我在SQLServer DBA 三十問和SQLServer 高可用、高性能和高保護延伸 中的一些技術方面的知識），而且這些技術在可靠性方面已經通過了市場的認可，有很多公司在為提高其程序的可靠性、安全性和高效性等方面或多或少的採用了其中的某些技術，以下就我接觸過的這些技術方面的應用，主要針對網站這種流量很大，讀多寫少的應用，就資料庫架構方面做些探討，希望對各位有所幫助，如有不對的地方，歡迎大家指正和交流。

資料庫架構需要考慮的問題：
數據可靠和一致性；
數據容災；
當數據量和訪問壓力變大時，方便擴充；
高度可用，出問題時能及時恢復，無單點故障；
不應因為某一台機器出現問題，導致整網性能的急劇下降；
方便維護。
資料庫管理：
資料庫管理(Database Manager)是有關建立、存儲、修改和存取資料庫中信息的技術，是指為保證資料庫系統的正常運行和服務質量，有關人員須進行的技術管理工作。負責這些技術管理工作的個人或集體稱為資料庫管理員(DBA)。資料庫管理的主要內容有：資料庫的調優、資料庫的重組、資料庫的重構、資料庫的安全管控、報錯問題的分析和匯總和處理、資料庫數據的日常備份. 資料庫的建立：資料庫的設計只是提供了數據的類型、邏輯結構、聯系、約束和存儲結構等有關數據的描述。這些描述稱為數據模式。

問題七：oracle資料庫的結構是什麼？ Oracle資料庫的體系結構包括四個方面：資料庫的物理結構、邏輯結構、內存結構及進程。

1. 物理結構

物理資料庫結構是由構成資料庫的操作系統文件所決定，Oracle資料庫文件包括：

數據文件（Data File）
數據文件用來存儲資料庫中的全部數據，例如資料庫表中的數據和索引數據.通常以為*.dbf格式，例如:userCIMS.dbf 。

日誌文件（Redo Log File）
日誌文件用於記錄資料庫所做的全部變更（如增加、刪除、修改）、以便在系統發生故障時，用它對資料庫進行恢復。名字通常為Log*.dbf格式，如：Log1CIMS.dbf,Log2CIMS.dbf 。

控制文件（Control File）
每個Oracle資料庫都有相應的控制文件，它們是較小的二進制文件，用於記錄資料庫的物理結構，如：資料庫名、資料庫的數據文件和日誌文件的名字和位置等信息。用於打開、存取資料庫。名字通常為Ctrl*ctl 格式，如Ctrl1CIMS.ctl。

配置文件
配置文件記錄Oracle資料庫運行時的一些重要參數，如：數據塊的大小，內存結構的配置等。名字通常為init*.ora 格式，如：initCIMS.ora 。

2 邏輯結構

Oracle資料庫的邏輯結構描述了資料庫從邏輯上如何來存儲資料庫中的數據。邏輯結構包括表空間、段、區、數據塊和模式對象。資料庫的邏輯結構將支配一個資料庫如何使用系統的物理空間.模式對象及其之間的聯系則描述了關系資料庫之間的設計.

一個資料庫從邏輯上說是由一個或多個表空間所組成，表空間是資料庫中物理編組的數據倉庫，每一個表空間是由段(segment)組成，一個段是由一組區(extent)所組成，一個區是由一組連續的資料庫塊(database block)組成，而一個資料庫塊對應硬碟上的一個或多個物理塊。一個表空間存放一個或多個資料庫的物理文件（即數據文件）.一個資料庫中的數據被邏輯地存儲在表空間上。

表空間（tablespace）
Oracle資料庫被劃分為一個或多個稱為表空間的邏輯結構，它包括兩類表空間，System表空間和非System表空間，其中，System表空間是安裝資料庫時自動建立的，它包含資料庫的全部數據字典，存儲過程、包、函數和觸發器的定義以及系統回滾段。除此之外，還能包含用戶數據。。

一個表空間包含許多段，每個段有一些可以不連續的區組成，每個區由一組連續的數據塊組成，數據塊是資料庫進行操作的最小單位。

每個表空間對應一個或多個數據文件，每個數據文件只能屬於一個表空間。

資料庫塊（database block）
資料庫塊也稱邏輯塊或ORACLE塊，它對應磁碟上一個或多個物理塊，它的大小由初始化參數db-block-size（在文件init.ora中）決定，典型的大小是2k。Pckfree 和pctused 兩個參數用來優化數據塊空間的使用。

區（extent）
區是由一組連續的數據塊所組成的資料庫存儲空間分配的邏輯單位。

段（segment）
段是一個或多個不連續的區的 *** ，它包括一個表空間內特定邏輯結構的所有數據，段不能跨表空間存放。Oracle資料庫包括數據段、索引段、臨時段、回滾段等。

模式對象（schema object）
Oracle資料庫的模式對象包括表、視圖、序列、同意詞、索引、觸發器、存......>>

問題八：sql server中架構是什麼意思 架構（Schema）是一組資料庫對象的 *** ，它被單個負責人（可以是用戶或角色）所擁有並構成唯一命名空間。你可以將架構看成是對象的容器。
在 SQL Server 2000 中，用戶（User）和架構是隱含關聯的，即每個用戶擁有與其同名的架構。因此要刪除一個用戶，必須先刪除或修改這個用戶所擁有的所有資料庫對象。
在 SQL Server 2005 中，架構和創建它的資料庫用戶不再關聯，完全限定名（fully-qualified name）現在包含4個部分：server.database.schema.object
1. 體系結構（Architecture）
體系結構亦可稱為架構，所謂軟體架構，根據Perry 和Wolfe之定義：Software Architecture = {Elements,Forms, Rationale / Constraint }，也就是軟體主架構 = {組件元素，元素互助合作之模式，基礎要求與限制}。Philippe Kruchten採用上面的定義，並說明主架構之設計就是：將各組件元素以某些理想的合作模式組織起來，以達成系統的基本功能和限制。體系結構又分為多種樣式，如Pipes and Filters等。
2. 框架(Framework)
框架亦可稱為應用架構，框架的一般定義就是：在特定領域基於體系結構的可重用的設計。也可以認為框架是體系結構在特定領域下的應用。框架比較出名的例子就是MVC。
3. 庫(Library)
庫應該是可重用的、相互協作的資源的 *** ，供開發人員進行重復調用。它與框架的主要區別在於運行時與程序的調用關系。庫是被程序調用，而框架則調用程序。比較好的庫有JDK。
4. 設計模式（Design Pattern）
設計模式大家應該很熟悉，尤其四人幫所寫的書更是家喻戶曉。「四人幫」將模式描述為「在一定的環境中解決某一問題的方案」。這三個事物 ― 問題、解決方案和環境 ― 是模式的基本要素。給模式一個名稱，考慮使用模式將產生的結果和提供一個或多個示例，對於說明模式也都是有用的。
5. 平台（PlatForm）
由多種系統構成，其中也可以包含硬體部分。
對於以上的概念有一個比較清楚的認識之後，就可以在軟體的開發過程中進行應用。理論和實踐是缺一不可的，相輔相成的。沒有理論的指導，實踐就缺乏基礎；沒有實踐的證明，理論就缺乏依據，因此我一直認為：對於當代的程序員，在有一定的實踐基礎後，必須學習更深的理論知識。無論你是從那方面先開始學習的。
在軟體的開發過浮中，從許多過程實踐和方法中，大致可以提煉出五大步驟：需求、分析、設計、編碼、測試。而體系結構是軟體的骨架，是最重要的基礎。體系結構是涉及到每一步驟中。一般在獲取需要的同時，就應該開始分析軟體的體系結構。體系結構現在一般是各個大的功能模塊組合成，然後描述各個部分的關系。
我一般認為框架是體系結構中每個模塊中更細小的結構。如需要表示web技術，就會用到MVC框架，而web功能只是整個軟體體系中的一個功能模塊。每個框架可以有許多個實例，如用java實現的MVC框架structs。
而在框架之下就是設計模式，設計模式一般是應用中框架之中的，也可以說是對框架的補充。因為框架只是提供了一個環境，需要我們我裡面填入更多的東西。無論是否應用了設計模式，你都可以實現軟體的功能，而正確應用了設計模式，是我們對前人軟體的設計或實現方法的一種繼承，從而讓你的軟體更軟。
體系結構是可以從不同視角來進......>>

問題九：oracle資料庫的架構是什麼？ oracle 資料庫架構本質上是C/S結構的。 伺服器與客戶端是分開的，即時伺服器和客戶端是在同一機器上，他們也是按照客戶端/伺服器模式運行的，他們之間的進程是分開的。 希望能幫助你。

問題十：資料庫中擁有的架構與成員身份有什麼區別？ 不同許可權組合或單獨就構成常角色。
不同用戶創建的資料庫對象不可能放在放在一起，因此就出現了容器就是所謂的架構，架構就是單個命名空間的數據實體的 ***

④ 資料庫軟體架構設計的要點

資料庫軟體架構設計，要關注哪些要點？
方法/步驟
在IT系統架構設計中，資料庫的設計，占據著很重要的地位。那麼主要面臨哪些問題，需要考慮哪些因素呢？
面對數據量過大的問題，通常需要通過分片技術來解決，目前應用較多的是哈希分片。
因為通過范圍簡單分片，可能造成各庫的壓力不均；而統一路由，會增加訪問前查詢的壓力。
通過主從復制的分組備笑，既可以解決可用性的問題，還可以實現一定的性能提升。
資料庫的軟體架構設計，要關注可用性、性能、一致性和擴展性四個方面。
解決可用性的主要思路就是冗餘——站點冗餘、服務冗餘、數據冗餘……
冗餘帶來的可用性問題，就是數據一致性的問題，要保證數據一致性，可以考慮雙寫同步。
擴展性能仿漏含一般有三種方式——增加索引、增加從庫和增加緩存，要結合實際情況分析應用。
架構的設計是一個動態優化的過程，要綜合考慮幾搜配個方面的因素，尋找合適的平衡點。

⑤ 什麼叫做資料庫的「三層架構

三層架構可以說是一種設置模式，他的作用只是讓我們更加有效的利用資源，有利於以後的修改和查看，依次分為視圖層，邏輯層，數據層；

試圖層顧名思義就是我們所看到的，他的原代碼並沒有關於處理和連庫等代碼，只是簡單的跳轉頁面，我們沒有辦法看到真正的代碼；

邏輯層就是我們從頁面層發回的問題等請求，從字面意思來看，你可以將他視為一個過渡層，只是連接是圖層和數據層；進行一些連庫，刪除數據等操作了；從試圖層跳轉過來的問題在這里進行處理，並提交給數據層，再返回頁面層共讀者查看；

數據層就不用說了吧！這里存放著所有的數據也就是一個工程的大本營一樣芹帆扒；

三層架構已經不僅僅屬於.net了，他是一種設計形式，從某種意義上來說，所有的轎旁開發設計幾乎都已經以三層架構為基礎，三層架構及有效嫌昌的處理問題，將數據和試圖也有效的分開，這樣防止耦合度過高，有利於處理和修改，（你不會是想將代碼全部寫在視圖頁面上，這樣有一個小小的變動，我們就要翻看幾十萬句代碼，從中找出，那我要替你的眼睛抱不平了）當你將程序做好後，從這台機子移動到另一台機子時，大大減少了出錯的問題；

通俗一點就是，這樣看上去很有層次感，我們查看時，可以減少時間的浪費，也不用在代碼堆里翻來覆去找不到北

⑥ 大數據量的系統的資料庫結構如何設計

1、把你表中經常查詢的和不常用的分開幾個表，也就是橫向切分
2、把不同類型的分成幾個表，縱向切分
3、常用聯接的建索引
4、伺服器放幾個硬碟，把數據、日誌、索引分盤存放，這樣可以提高IO吞吐率
5、用優化器，優化你的查詢
6、考慮冗餘，這樣可以減少連接
7、可以考慮建立統計表，就是實時生成總計表，這樣可以避免每次查詢都統計一次
mrzxc 等說的好，考慮你的系統，注意負載平衡，查詢優化，25 萬並不大，可以建一個表，然後按mrzxc 的3 4 5 7 優化。 速度，影響它的因數太多了，且數據量越大越明顯。
1、存儲 將硬碟分成NTFS格式，NTFS比FAT32快，並看你的數據文件大小，1G以上你可以採用多資料庫文件，這樣可以將存取負載分散到多個物理硬碟或磁碟陣列上。
2、tempdb tempdb也應該被單獨的物理硬碟或磁碟陣列上,建議放在RAID 0上，這樣它的性能最高,不要對它設置最大值讓它自動增長
3、日誌文件 日誌文件也應該和數據文件分開在不同的理硬碟或磁碟陣列上，這樣也可以提高硬碟I/O性能。
4、分區視圖 就是將你的數據水平分割在集群伺服器上，它適合大規模OLTP,SQL群集上，如果你資料庫不是訪問特別大不建議使用。
5、簇索引 你的表一定有個簇索引，在使用簇索引查詢的時候，區塊查詢是最快的，如用between，應為他是物理連續的，你應該盡量減少對它的updaet,應為這可以使它物理不連續。
6、非簇索引 非簇索引與物理順序無關，設計它時必須有高度的可選擇性，可以提高查詢速度，但對表update的時候這些非簇索引會影響速度，且佔用空間大，如果你願意用空間和修改時間換取速度可以考慮。
7、索引視圖 如果在視圖上建立索引,那視圖的結果集就會被存儲起來，對與特定的查詢性能可以提高很多，但同樣對update語句時它也會嚴重減低性能，一般用在數據相對穩定的數據倉庫中。
8、維護索引 你在將索引建好後，定期維護是很重要的，用dbcc showcontig來觀察頁密度、掃描密度等等，及時用dbcc indexdefrag來整理表或視圖的索引,在必要的時候用dbcc dbreindex來重建索引可以受到良好的效果。 不論你是用幾個表1、2、3點都可以提高一定的性能，5、6、8點你是必須做的，至於4、7點看你的需求，我個人是不建議的。打了半個多小時想是在寫論文，希望對你有幫助。

⑦ 微服務開發中的數據架構應該怎樣設計

前言

微服務是當前非常流行的技術框架，通過服務的小型化、原子化以及分布式架構的彈性伸縮和高可用性，可以實現業務之間的松耦合、業務的靈活調整組合以及系統的高可用性。為業務創新和業務持續提供了一個良好的基礎平台。本文分享在這種技術架構下的數據架構的設計思想以及設計要點，本文包括下面若干內容。

• 微服務技術框架中的多層數據架構設計

• 數據架構設計中的要點
  

• 要點1：數據易用性

• 要點2：主、副數據及數據解耦

• 要點3：分庫分表

• 要點4：多源數據適配

• 要點5：多源數據緩存

• 要點6：數據集市

為了容易理解，本文用一個簡化的銷售模型來闡述，如下圖。圖1顯示了客戶、賣家、商品、定價、訂單的關系（這里省略支付、物流等其他元素）。

圖1 銷售模型

在這個銷售模型中，賣家提供商品、制定價格，客戶選擇產品購買、形成銷售訂單。根據微服務的理念設計，可以劃分為客戶服務、賣家服務、商品服務、定價服務、訂單服務，以及公共服務（比如認證、許可權、通知等），如圖2所示。



圖9 數據緩存

要點6：數據集市

數據集市是一個很大的話題。當現有的數據不能簡單地通過幾個表數據關聯以及簡單加工後就可以供業務使用的時候，就需要考慮構建數據集市。數據集市以數據運用的觀點來分析加工數據，通過多源數據的導入、清洗、加工、視圖做成等一系列的數據操作後，為業務提供可用的、穩定的數據源。例如，對銷售分析中、什麼樣的客戶喜歡什麼樣的商品、價格對銷售金額的影響、銷售金額跟地區日期的關聯關系等多維度分析，就要用數據集市的概念，如圖10所示。

圖10 數據集市

數據承載著信息，好的數據架構設計會使業務系統變得更加流暢、更加容易理解和維護。本文只是總結一些在實際工程中的體會，供大家分享。如果有不足之處、也請大家補充、賜教。

（此文轉載至GitChat技術雜談）

⑧ 數據表關系比較多的資料庫三層架構應該怎麼設計

實體類，也就是把資料庫表的欄位映射為碼野你的對象的遲物喊各個屬性如你A表有，id,name,password三個屬性你Model裡面新建Aclass給他ID,Name,Password三個屬性然後做和數據表欄位映射LINQTOSQL的時候就會自動讀取映射的欄位並螞畝轉換為實體類的屬性值

⑨ 資料庫設計和資料庫架構一樣嗎

不一樣，資料庫設計和資料庫架構是不一樣的，可以先設計出資料庫的架構，然後再深化完善設計。

⑩ 怎樣的架構設計才是真正的數據倉庫架構

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：

• 整合公司所有業務數據，建立統一的數據中心；

• 提供各種報表，有給高層的，有給各個業務的；

• 為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；

• 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；

• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

• 開發數據產品，直接或間接為公司盈利；

• 建設開放數據平台，開放公司數據；

• 。。。。。。



• 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；


• 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；


• 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。


• 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：


• 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。


• 我們從下往上看：


• 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。



• 數據源的種類比較多：



• 網站日誌：



• 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，


• 一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；



• 業務資料庫：



• 業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。


• 當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。



• 來自於Ftp/Http的數據源：



• 有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；



• 其他數據源：



• 比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；



• 數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。



• 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；


• 當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》


• 實時計算部分，後面單獨說。


• 數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；



• 前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。


• 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。



• 數據應用

• 業務產品
  



• 業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；



• 報表



• 同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；



• 即席查詢



• 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；


• 這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。


• 即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。


• 當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。



• OLAP



• 目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；


• 這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；


• 比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。



• 其它數據介面
  



• 這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。



• 實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。


• 我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。


• 做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。


• 任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；



• 這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。


• 前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。


• 總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。