OceanBase設(shè)計(jì)規(guī)范與數(shù)據(jù)架構(gòu)指南-v2(1)-3

OceanBase設(shè)計(jì)規(guī)范與數(shù)據(jù)架構(gòu)指南版本0.1文檔修訂歷史版本號作者備注修訂日期V0.1泓影初稿2017-06-29V0.2泓影修正細(xì)節(jié)2017-07-13OceanBase1.0簡介自從E.F.Codd于1970年首次提出關(guān)系數(shù)據(jù)庫模型后，關(guān)系數(shù)據(jù)庫便以其易于使用的接口、完善的功能和生態(tài)而成為了IT領(lǐng)域必需的基礎(chǔ)設(shè)施，廣泛應(yīng)用在各行各業(yè)，包括金融、電信、房地產(chǎn)、農(nóng)林牧漁、制造業(yè)等等。關(guān)系數(shù)據(jù)庫經(jīng)過了40多年的發(fā)展，涌現(xiàn)了Oracle、SQLServer、DB2等優(yōu)秀的商業(yè)數(shù)據(jù)庫產(chǎn)品，開源領(lǐng)域也不乏MySQL、PostgreSQL這樣的精品。但是，隨著互聯(lián)網(wǎng)行業(yè)和大數(shù)據(jù)的興起，數(shù)據(jù)量和并發(fā)訪問量呈現(xiàn)指數(shù)級的增長，囿于關(guān)系數(shù)據(jù)庫的架構(gòu)，原先運(yùn)行良好的關(guān)系數(shù)據(jù)庫遭遇了嚴(yán)峻的挑戰(zhàn)：極度高昂的總體擁有成本、捉襟見肘的擴(kuò)展能力、荏弱無力的大數(shù)據(jù)處理性能等等。于是NoSQL應(yīng)運(yùn)而生，Hbase、Cassandra等系統(tǒng)如雨后春筍般冒出，這些系統(tǒng)多采取分布式架構(gòu)，易于擴(kuò)展及容災(zāi)，結(jié)合大數(shù)據(jù)處理系統(tǒng)如Hadoop等，可以很容易處理量級非常大的數(shù)據(jù)，這一時(shí)讓NoSQL風(fēng)光無兩，大有取代SQL之勢，讓人看不清NoSQL系統(tǒng)的邊界。很多公司嘗試將核心系統(tǒng)遷移到新興的NoSQL系統(tǒng)上，比如Facebook就嘗試將部份核心系統(tǒng)遷移到Cassandra。在遷移過程中，人們發(fā)現(xiàn)NoSQL所獲得針對SQL的優(yōu)勢其實(shí)是以犧牲一些非常重要的功能來獲取的，如NoSQL一般不支持事務(wù)或只支持非常有限的事務(wù)，這極大的增加了業(yè)務(wù)系統(tǒng)的復(fù)雜度，在傳統(tǒng)的OLTP領(lǐng)域采取NoSQL系統(tǒng)基本上是不可以接受的。阿里巴巴/螞蟻金服的關(guān)系數(shù)據(jù)庫使用場景極其嚴(yán)苛，有著全球最大的并發(fā)量需求，在可靠性方面需要做到單機(jī)、機(jī)架、機(jī)房甚至是地區(qū)級別的容災(zāi)恢復(fù)能力。早期使用共享存儲、小型機(jī)等高端硬件也只能部分滿足我們在性能和可靠性上的需求，而且隨著業(yè)務(wù)的發(fā)展，這種IOE架構(gòu)很快就成為瓶頸。我們能不能結(jié)合新興分布式系統(tǒng)和傳統(tǒng)關(guān)系型數(shù)據(jù)庫的優(yōu)點(diǎn)，既擁有傳統(tǒng)關(guān)系型數(shù)據(jù)庫在功能上的優(yōu)勢，同時(shí)具備分布式系統(tǒng)的可擴(kuò)展性、高可靠性等特征？OceanBase即是以此為出發(fā)點(diǎn)，開始打造一個(gè)分布式關(guān)系型數(shù)據(jù)庫。OceanBase從2010年6月份立項(xiàng)開始到今天已經(jīng)發(fā)展了六年多的時(shí)間，構(gòu)建在普通服務(wù)器組成的分布式集群之上，具備可擴(kuò)展、高可用、高性能、低成本以及多租戶等核心技術(shù)優(yōu)勢。目前已經(jīng)成功應(yīng)用于螞蟻金服的會員、交易、支付、賬務(wù)、計(jì)費(fèi)等核心系統(tǒng)和網(wǎng)商銀行等業(yè)務(wù)系統(tǒng)。OceanBase經(jīng)歷了多年（2011-2016）雙十一的嚴(yán)格考驗(yàn)，特別是在剛剛過去的2016年雙十一，用戶每一筆支付訂單背后的數(shù)據(jù)和事務(wù)處理都由OceanBase完成，創(chuàng)造了每秒12萬筆支付峰值的世界記錄。OceanBase架構(gòu)及優(yōu)勢互聯(lián)網(wǎng)對傳統(tǒng)關(guān)系型數(shù)據(jù)庫的挑戰(zhàn)主要有兩個(gè)方面：一是可擴(kuò)展性。傳統(tǒng)關(guān)系型數(shù)據(jù)庫本質(zhì)上是單機(jī)系統(tǒng)，其擴(kuò)展方法一般為向上擴(kuò)展，即換性能更好的機(jī)器，阿里巴巴/螞蟻金服隨著業(yè)務(wù)的發(fā)展，也一路擴(kuò)容到小型機(jī)，但這種方式對于互聯(lián)網(wǎng)行業(yè)來說，其擴(kuò)容周期短，成本很高。另外一種方法為水平拆分，即分庫分表，這也是目前廣泛應(yīng)用的擴(kuò)展方式，這極大的增加了業(yè)務(wù)復(fù)雜度，相當(dāng)于將數(shù)據(jù)庫的一部份工作轉(zhuǎn)嫁到業(yè)務(wù)方，從各大公司都有自己的中間件來處理這一層業(yè)務(wù)即可見一斑。二是可靠性。傳統(tǒng)關(guān)系型數(shù)據(jù)庫一般采取主備形式來解決高可用的問題。主備之間數(shù)據(jù)同步主要有兩種方式，一是最大保護(hù)模式，需要主備均寫入成功后才算成功，這樣可以保證數(shù)據(jù)一致性，但一旦備機(jī)宕機(jī)或網(wǎng)絡(luò)抖動即可造成不可用。另外是最大性能/最大可用模式，這種模式下只要主寫入成功即可算成功，此時(shí)如果主機(jī)宕機(jī)，但有數(shù)據(jù)尚未同步到同機(jī)，即可造成數(shù)據(jù)不一致或丟失。解決這個(gè)問題的傳統(tǒng)方案是采取高端商用硬件如共享存儲，通過高可靠的硬件來解決軟件上的不可靠，但這樣也會存在一些問題，比如共享存儲無法解決或很難解決機(jī)房容災(zāi)問題。OceanBase的目標(biāo)是要解決這兩方面的問題，設(shè)計(jì)原則：使用普通PC服務(wù)器，不使用共享存儲、小型機(jī)等高端硬件。磁盤、服務(wù)器、網(wǎng)絡(luò)、機(jī)房甚至是某個(gè)地區(qū)的IT基礎(chǔ)設(shè)施并非持續(xù)可用。關(guān)系型數(shù)據(jù)庫，支持傳統(tǒng)關(guān)系型數(shù)據(jù)庫的功能，比如SQL、跨行跨表事務(wù)?？伤綌U(kuò)展，擴(kuò)展時(shí)對應(yīng)用透明。高可靠、數(shù)據(jù)強(qiáng)一致，單機(jī)、機(jī)房甚至地區(qū)故障時(shí)可自動恢復(fù)。高性能。根據(jù)目標(biāo)，OceanBase需要解決三個(gè)方面的問題：一是傳統(tǒng)關(guān)系型數(shù)據(jù)庫的功能。

傳統(tǒng)關(guān)系數(shù)據(jù)庫經(jīng)過多年的發(fā)展，功能極其豐富，SQL的表達(dá)能力、事務(wù)支持等對應(yīng)用非常友好，并且形成了自己的生態(tài)。OceanBase需要從頭開始實(shí)現(xiàn)，一個(gè)可能的選擇是基于某個(gè)開源數(shù)據(jù)庫來實(shí)現(xiàn)，但經(jīng)過分析，基于控制力、架構(gòu)等原因，我們最終沒有選擇這條路，而是完全自主研發(fā)。二是分布式一致性問題。

分布式系統(tǒng)往往通過多個(gè)副本來實(shí)現(xiàn)數(shù)據(jù)高可靠以及高可用，如何保證多個(gè)副本之間的數(shù)據(jù)一致性是一個(gè)非常復(fù)雜的問題。最大保護(hù)模式的基礎(chǔ)是高可用的硬件及網(wǎng)絡(luò)鏈路，這些在OceanBase中都不存在。三是分布式事務(wù)的問題。

很多分布式系統(tǒng)都弱化了這個(gè)功能，只支持單行事務(wù)，這樣的選擇一方面是工程實(shí)現(xiàn)難度較高，另外一方面是對性能影響較大，OceanBase如何支持跨機(jī)分布式事務(wù)并保證性能是一個(gè)很大的問題。OceanBase解決這些問題也并非一蹴而就，而是著眼于業(yè)務(wù)需求，通過六年的發(fā)展，才逐步解決了這些問題，OceanBase總體架構(gòu)：如上圖所示，一個(gè)OceanBase集群由多臺分布在不同機(jī)房的ObServer組成，每臺ObServer都是對等關(guān)系，圖中分布在三個(gè)IDC，意味著存儲了三個(gè)副本，每個(gè)IDC是鏡像的關(guān)系，可抵御少數(shù)派IDC失敗。每個(gè)表可以以分區(qū)表(即createtable中的partitionby子句)的形式分成多個(gè)分區(qū)，圖中一個(gè)表被分成了P1~P88個(gè)分區(qū)，每個(gè)分區(qū)可以分布在不同的ObServer上，每個(gè)分區(qū)的三個(gè)副本分布在不同IDC的不同ObServer上，其中一個(gè)副本被選舉為Leader，如圖中P2,P3的Leader在IDC1的第一臺ObServer上。只有分區(qū)的Leader才可以對外提供查詢和更新服務(wù)。ObProxy是一個(gè)無狀態(tài)服務(wù)，它接收應(yīng)用的請求并根據(jù)應(yīng)用請求中的分區(qū)字段來判斷這個(gè)請求屬于哪個(gè)分區(qū)，然后將其路由到這個(gè)分區(qū)Leader所在的服務(wù)器。讓用戶無需關(guān)心數(shù)據(jù)分片的細(xì)節(jié)，數(shù)據(jù)所在的具體位置，對外的表現(xiàn)仍然是一個(gè)單機(jī)的數(shù)據(jù)庫。OceanBase兼容MySQL協(xié)議，通過ObProxy，用戶可以使用任意語言的MySQL客戶端來連接OceanBase。經(jīng)過六年多的發(fā)展，OceanBase初步實(shí)現(xiàn)了當(dāng)初定下的目標(biāo)，在架構(gòu)上具有諸多優(yōu)勢：高效的存儲引擎OceanBase采用的是share-nothing的分布式架構(gòu)，每個(gè)OBServer都是對等的，管理不同的數(shù)據(jù)分區(qū)。單機(jī)的存儲引擎采取讀寫分離的架構(gòu)，將當(dāng)前更新的動態(tài)數(shù)據(jù)存入內(nèi)存稱為MemTable，存量的基線數(shù)據(jù)存在磁盤，稱為SSTable。一個(gè)Partition的所有數(shù)據(jù)(基線數(shù)據(jù)+增量數(shù)據(jù)+事務(wù)日志)都放在一個(gè)OBServer中，因此針對一個(gè)Partition的讀寫操作不會有跨機(jī)的操作，數(shù)據(jù)的寫入也分布到多點(diǎn)并行執(zhí)行。讀寫分離的存儲結(jié)構(gòu)帶來很多好處，因?yàn)橛写罅康撵o態(tài)基線數(shù)據(jù)，可以很方便對其進(jìn)行壓縮，減少存儲成本；另外做行級緩存也不用擔(dān)心寫入帶來的緩存失效問題。缺點(diǎn)是讀的路徑變長，數(shù)據(jù)需要實(shí)時(shí)合并可能帶來性能問題，OceanBase采用了很多的優(yōu)化手段，比如bloomfiltercache對不存在的行做過濾(insertrow判斷行是否存在無需IO操作)，盡量優(yōu)先讀取更新的內(nèi)容(ActiveMemTable)，如果發(fā)現(xiàn)用戶讀取的列已經(jīng)讀取到，則無需進(jìn)一步讀取基線數(shù)據(jù)進(jìn)行合并。由于增量數(shù)據(jù)寫在內(nèi)存中，所以內(nèi)存寫到一定量后需要和基線數(shù)據(jù)合并而生成新的基線，這個(gè)過程我們稱之為合并，合并會造成一些額外的壓力，可能對客戶的請求有影響，所以我們采取一種稱之為輪轉(zhuǎn)合并的策略，即將OceanBase的多個(gè)IDC中的其中一個(gè)IDC的流量切走，進(jìn)行合并，待合并完成后再將流量切到已合并的IDC上，這樣可以避免對業(yè)務(wù)的影響，同時(shí)這種策略也可以用在升級維護(hù)中，當(dāng)需要進(jìn)行版本升級的時(shí)候，可以將其中一臺ObServer的流量切走進(jìn)行升級，升級完成后逐步灰度切流，一旦出現(xiàn)問題即可快速無損回滾。可擴(kuò)展性分布式系統(tǒng)通過數(shù)據(jù)分區(qū)來實(shí)現(xiàn)可擴(kuò)展性，主流數(shù)據(jù)分區(qū)方法有兩種：哈希分區(qū)和范圍分區(qū)。分布式Key-Value系統(tǒng)、數(shù)據(jù)庫分庫分表本質(zhì)上都是哈希分區(qū)；而主流的分布式表格系統(tǒng)，如Bigtable、開源的HBase往往采用范圍分區(qū)。范圍分布很容易出現(xiàn)分區(qū)不均勻的情況，因此，需要支持分區(qū)動態(tài)分裂與合并。關(guān)系數(shù)據(jù)庫的數(shù)據(jù)分布方法則更為靈活，以O(shè)racle分區(qū)表為例，除了支持簡單的哈希分區(qū)、范圍分區(qū)，還支持list分區(qū)、Interval分區(qū)，以及二級組合分區(qū)。另外，關(guān)系數(shù)據(jù)庫還支持單個(gè)分區(qū)的操作，例如刪除某個(gè)分區(qū)，構(gòu)建針對單個(gè)分區(qū)的局部索引、設(shè)置壓縮方法，等等。OceanBase引入了傳統(tǒng)關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)分區(qū)表的方法，語法上也兼容傳統(tǒng)數(shù)據(jù)庫創(chuàng)建分區(qū)表的方法，這種設(shè)計(jì)兼具分布式系統(tǒng)的擴(kuò)展性和關(guān)系數(shù)據(jù)庫的易用性和靈活性，符合DBA的使用習(xí)慣。OceanBase支持在線線性擴(kuò)展，當(dāng)集群存儲容量或是處理能力不足時(shí)，可以隨時(shí)加入新的OBServer，系統(tǒng)會自動進(jìn)行數(shù)據(jù)遷移，根據(jù)機(jī)器的處理能力，將合適的數(shù)據(jù)分區(qū)遷移到新加入的機(jī)器上；同樣在系統(tǒng)容量充足和處理能力富余時(shí)，也可以將機(jī)器下線，降低成本；在類似于雙11大促之類的活動中，可以提供良好的彈性伸縮能力。對一個(gè)數(shù)據(jù)分區(qū)所有讀寫操作都在其所在的OBServer完成，涉及多個(gè)數(shù)據(jù)分區(qū)的事務(wù)，會采用兩階段提交的方式在多個(gè)OBServer上執(zhí)行。在OceanBase中，事務(wù)分為幾種類型：單分區(qū)事務(wù)。和傳統(tǒng)的關(guān)系數(shù)據(jù)庫一樣，屬于單機(jī)事務(wù)，不需要走兩階段提交協(xié)議。單機(jī)多分區(qū)事務(wù)。需要走兩階段提交協(xié)議，且針對單機(jī)做了專門的優(yōu)化。多機(jī)多分區(qū)事務(wù)。需要走完整的兩階段提交協(xié)議。分布式事務(wù)會增加事務(wù)的延時(shí)，OceanBase采取了很多措施來盡量避免分布式事務(wù)，比如支持表格組（tablegroup）來盡可能地減少分布式事務(wù)。表格組用于聚集經(jīng)常一起訪問的多張表格。例如，有用戶基本信息表（user）和用戶商品表（user_item），這兩張表格都按照用戶編號哈希分布，只需要將二者設(shè)置為相同的表格組，系統(tǒng)后臺就會自動將同一個(gè)用戶所在的user表分區(qū)和user_item表分區(qū)調(diào)度到同一臺服務(wù)器。這樣，即使操作某個(gè)用戶的多張表格，也不會產(chǎn)生跨機(jī)事務(wù)。高可靠OceanBase系統(tǒng)中的每個(gè)分區(qū)都維護(hù)了多個(gè)副本，一般為三個(gè)，且部署到三個(gè)不同的數(shù)據(jù)中心（Zone）。整個(gè)系統(tǒng)中有成百上千萬個(gè)分區(qū)，這些分區(qū)的多個(gè)副本之間通過Paxos協(xié)議進(jìn)行日志同步。每個(gè)分區(qū)和它的副本構(gòu)成一個(gè)獨(dú)立的Paxos復(fù)制組（PaxosReplicationGroup），其中一個(gè)副本為主（Leader），其它副本為備（Follower）。每臺ObServer服務(wù)的一部分分區(qū)為Leader，一部分分區(qū)為Follower。當(dāng)ObServer出現(xiàn)故障時(shí)，F(xiàn)ollower分區(qū)不受影響，Leader分區(qū)的寫服務(wù)短時(shí)間內(nèi)會受到影響，直到通過Paxos協(xié)議將該分區(qū)的某個(gè)Follower選為新的Leader為止，整個(gè)過程大約持續(xù)30秒左右。通過引入Paxos協(xié)議，可以保證在數(shù)據(jù)強(qiáng)一致的情況下，具有極高的可用性及性能。多租戶OceanBase1.0系統(tǒng)作為一個(gè)擴(kuò)展性很強(qiáng)的集群系統(tǒng)，設(shè)計(jì)的目標(biāo)就包括使用一個(gè)集群支持多個(gè)業(yè)務(wù)系統(tǒng)，也就是通常所說的多租戶特性。數(shù)據(jù)庫多租戶概念，Oracle是從12C版本開始支持的，在Oracle里面，最重要的兩個(gè)概念是CDB（ContainerDB）和PDB（PluggableDB）。對于OceanBase1.0來說，多租戶同樣是一個(gè)非常重要的特性，是數(shù)據(jù)庫對象管理和資源管理的基礎(chǔ)；對于系統(tǒng)運(yùn)維，尤其是對于將來的云數(shù)據(jù)庫的運(yùn)維也有著重要的影響。OceanBase1.0的多租戶特性，主要包含如下幾點(diǎn)：將多個(gè)數(shù)據(jù)庫實(shí)例管理和運(yùn)維的成本和復(fù)雜性降低到和一個(gè)數(shù)據(jù)庫實(shí)例相當(dāng)。1.0的其中一個(gè)優(yōu)勢就是大集群的規(guī)模優(yōu)勢，取得這個(gè)優(yōu)勢的一個(gè)重要原因就是原先的多個(gè)數(shù)據(jù)庫實(shí)例，在1.0版本中管理的成本相當(dāng)于一個(gè)實(shí)例。充分利用系統(tǒng)資源，使得同樣的資源可以服務(wù)更多的業(yè)務(wù)。通過將波峰、波谷期不同的業(yè)務(wù)系統(tǒng)部署到一個(gè)集群，以實(shí)現(xiàn)對系統(tǒng)資源最大限度的使用。租戶之間的隔離性：在數(shù)據(jù)安全方面，不允許跨租戶的數(shù)據(jù)訪問，確保用戶的數(shù)據(jù)資產(chǎn)沒有泄露的風(fēng)險(xiǎn)；在資源使用方面表現(xiàn)為租戶“獨(dú)占”其資源配額，該租戶對應(yīng)的前端應(yīng)用，無論是響應(yīng)時(shí)間還是TPS/QPS都比較平穩(wěn)，不會受到其他租戶負(fù)載輕重的影響。OceanBase所采取的隔離方式，既能充分利用資源，又可以獲取非常高的資源整合度。多租戶的特性使得OceanBase非常適合云計(jì)算。MySQL兼容關(guān)系數(shù)據(jù)庫經(jīng)過多年的發(fā)展，其周邊生態(tài)十分重要，大量的現(xiàn)有業(yè)務(wù)都構(gòu)建在現(xiàn)有的關(guān)系型數(shù)據(jù)庫上，OceanBase采取和MySQL兼容的方式來讓基于MySQL的應(yīng)用程序可以不經(jīng)修改就能運(yùn)行在OceanBase之上。OceanBase在兼容性方面做了大量的工作：接口層面：主流的數(shù)據(jù)庫產(chǎn)品都支持標(biāo)準(zhǔn)的接口如JDBC、ODBC、.netProvider。OceanBase廣泛使用的接口主要是JDBC和ODBC。通過不斷增強(qiáng)在前后臺協(xié)議上和MySQL的兼容性，目前，使用MySQL的驅(qū)動就可以無障礙地訪問OceanBase。數(shù)據(jù)模式層面：完整地支持了數(shù)據(jù)庫（database）、表（table）、視圖（view）、自增列（autoincrement）等SQL標(biāo)準(zhǔn)的以及MySQL專有的數(shù)據(jù)模式，并且在數(shù)據(jù)庫系統(tǒng)中實(shí)現(xiàn)了多租戶（multi-tenant）。原先基于不同MySQL實(shí)例的業(yè)務(wù)可以無縫地遷移到一個(gè)OceanBase集群。語句層面：目前的主流產(chǎn)品在SQL語句層面大多遵守ISO/IEC9075標(biāo)準(zhǔn)定義的一系列規(guī)范，最新的版本是SQL2011。對比之前的版本，1.0版本大幅度增加了對標(biāo)準(zhǔn)SQL語句的支持，同時(shí)擴(kuò)展了支持了MySQL中有但非標(biāo)準(zhǔn)的語句。數(shù)據(jù)類型層面：數(shù)據(jù)類型是基礎(chǔ)設(shè)施，對兼容性的影響非常大，涉及的細(xì)節(jié)非常多。在1.0版本的開發(fā)過程中，為了使得表達(dá)式計(jì)算的表現(xiàn)和MySQL一致，我們在數(shù)據(jù)類型的兼容性方面投入了大量的人力，也幫助MySQL產(chǎn)品糾正了不少錯(cuò)誤的表現(xiàn)。事務(wù)層面：系統(tǒng)支持的事務(wù)隔離級別以及并發(fā)控制方面的表現(xiàn)。OceanBase采用的是多版本的并發(fā)控制協(xié)議，讀寫不等待，支持ReadCommitted隔離級別。OceanBase1.0開發(fā)設(shè)計(jì)規(guī)約數(shù)據(jù)庫開發(fā)設(shè)計(jì)規(guī)約在新系統(tǒng)上線初期啟到了舉足輕重的作用。正猶如制訂交通法規(guī)表面上是要限制行車權(quán)，實(shí)際上是保障公眾的人身安全。試想如果沒有限速，沒有紅綠燈，沒有靠右行駛條款，誰還敢上路。OB的開發(fā)規(guī)約的目標(biāo)：防患未然，降低故障率和維護(hù)成本。標(biāo)準(zhǔn)統(tǒng)一，提升協(xié)作效率。追求卓越的工匠精神，打磨精品代碼。建表規(guī)約【強(qiáng)制】表達(dá)是與否概念的字段，數(shù)據(jù)類型是unsignedtinyint（1表示是，0表示否），值的內(nèi)容要統(tǒng)一，所有應(yīng)用值要統(tǒng)一。

正例：表達(dá)邏輯刪除的字段名is_deleted，1表示刪除，0表示未刪除?！緩?qiáng)制】表名、字段名必須使用小寫字母或數(shù)字。禁止出現(xiàn)數(shù)字開頭，禁止兩個(gè)下劃線中間只出現(xiàn)數(shù)字。數(shù)據(jù)庫字段名的修改代價(jià)很大，所以字段名稱需要慎重考慮。

說明：MySQL在Windows下不區(qū)分大小寫，但在Linux下默認(rèn)是區(qū)分大小寫。因此，數(shù)據(jù)庫名、表名、字段名，都不允許出現(xiàn)任何大寫字母，避免節(jié)外生枝。

正例：getter_admin，task_config，level3_name

反例：GetterAdmin，taskConfig，level_3_name【強(qiáng)制】表名不使用復(fù)數(shù)名詞。

說明：表名應(yīng)該僅僅表示表里面的實(shí)體內(nèi)容，不應(yīng)該表示實(shí)體數(shù)量【強(qiáng)制】禁用保留字，如desc、range、match、delayed等，OB1.0的保留字見【強(qiáng)制】唯一索引名為uk_字段名；普通索引名則為idx_字段名。

說明：uk_即uniquekey；idx_即index的簡稱。【強(qiáng)制】小數(shù)類型為decimal，禁止使用float和double。

說明：float和double在存儲的時(shí)候，存在精度損失的問題，很可能在值的比較時(shí)，得到不正確的結(jié)果。【強(qiáng)制】varchar是可變長字符串，不預(yù)先分配存儲空間，長度不要超過256K，如果存儲長度大于此值，目前OB1.0暫不支持。需要考慮字段的拆分方案。一張表的列總長度（rowsize）不能超過512K【強(qiáng)制】表必備兩字段：gmt_create,gmt_modified。

說明：gmt_create,gmt_modified的類型均為datetime(6)類型。（最佳實(shí)踐記到微秒）【強(qiáng)制】表的命名最好是加上“業(yè)務(wù)名稱_表的作用”。

正例：tiger_task/tiger_reader/mpp_config【推薦】庫名與應(yīng)用名稱盡量一致?！就扑]】如果修改字段含義或?qū)ψ侄伪硎镜臓顟B(tài)追加時(shí)，需要及時(shí)更新字段注釋?！就扑]】字段允許適當(dāng)冗余，以提高性能，但是必須考慮數(shù)據(jù)同步的情況。冗余字段應(yīng)遵循：

?1）不是頻繁修改的字段。

?2）不是varchar超長字段。

【強(qiáng)制】單分表行數(shù)可能超過10億行或者單分表容量超過2000GB，才推薦進(jìn)行分區(qū)表。

說明：如果預(yù)計(jì)三年后的數(shù)據(jù)量根本達(dá)不到這個(gè)級別，請不要在創(chuàng)建表時(shí)使用分區(qū)表。

反例：某業(yè)務(wù)三年總數(shù)據(jù)量才2萬行，卻在上線初期就規(guī)劃使用分區(qū)表，由于業(yè)務(wù)模型的改變，很可能面臨需要調(diào)整分區(qū)鍵的問題，這個(gè)需要等業(yè)務(wù)穩(wěn)定成熟后考慮分區(qū)表的模式。后續(xù)OB也會支持非分區(qū)表轉(zhuǎn)換成分區(qū)表的功能?！緟⒖肌亢线m的字符存儲長度，不但節(jié)約數(shù)據(jù)庫表空間、節(jié)約索引存儲，更重要的是提升檢索速度。

正例：無符號值可以避免誤存負(fù)數(shù)，且擴(kuò)大了表示范圍：對象年齡區(qū)間類型表示范圍人150歲之內(nèi)unsignedtinyint無符號值：0到255龜數(shù)百歲unsignedsmallint無符號值：0到65535恐龍化石約數(shù)千萬年unsignedint無符號值：0到約43億太陽約50億年unsignedbigint無符號值：0到約10的19次方索引規(guī)約SQL開發(fā)完成后，需要匯集所有語句提交給DBA進(jìn)行sqlreview【強(qiáng)制】業(yè)務(wù)上具有唯一特性的字段，即使是組合字段，也必須建成唯一索引。

說明：不要以為唯一索引影響了insert速度，這個(gè)速度損耗可以忽略，但提高查找速度是明顯的；另外，即使在應(yīng)用層做了非常完善的校驗(yàn)和控制，只要沒有唯一索引，根據(jù)墨菲定律，必然有臟數(shù)據(jù)產(chǎn)生。【強(qiáng)制】超過三個(gè)表禁止join。需要join的字段，數(shù)據(jù)類型保持絕對一致；多表關(guān)聯(lián)查詢時(shí)，保證被關(guān)聯(lián)的字段需要有索引。

說明：即使雙表join也要注意表索引、SQL性能?！緩?qiáng)制】頁面搜索嚴(yán)禁左模糊或者全模糊，如果需要請走搜索引擎來解決。

說明：索引文件具有B-Tree的最左前綴匹配特性，如果左邊的值未確定，那么無法使用此索引?！就扑]】如果有orderby的場景，請注意利用索引的有序性。orderby最后的字段是組合索引的一部分，并且放在索引組合順序的最后，避免出現(xiàn)file_sort的情況，影響查詢性能。

正例：wherea=?andb=?orderbyc;索引：a_b_c

反例：索引中有范圍查找，那么索引有序性無法利用，如：WHEREa>10ORDERBYb;索引a_b無法排序?！緩?qiáng)制】利用覆蓋索引來進(jìn)行查詢操作，來避免回表操作。

說明：如果一本書需要知道第11章是什么標(biāo)題，會翻開第11章對應(yīng)的那一頁嗎？目錄瀏覽一下就好，這個(gè)目錄就是起到覆蓋索引的作用?！緩?qiáng)制】利用延遲關(guān)聯(lián)或者子查詢優(yōu)化超多分頁場景。

說明：OB1.0并不是跳過offset行，而是取offset+N行，然后返回放棄前offset行，返回N行，那當(dāng)offset特別大的時(shí)候，效率就非常的低下，要么控制返回的總頁數(shù)，要么對超過特定閾值的頁數(shù)進(jìn)行SQL改寫。

正例：先快速定位需要獲取的id段，然后再關(guān)聯(lián)：

SELECTa.*FROM表1a,(selectidfrom表1where條件LIMIT100000,20)bwherea.id=b.id

反例：“服務(wù)市場”某交易分頁超過1000頁，用戶點(diǎn)擊最后一頁時(shí)，數(shù)據(jù)庫基本處于半癱瘓狀態(tài)?！就扑]】建組合索引的時(shí)候，區(qū)分度最高的在最左邊。

正例：如果wherea=?andb=?，a列的幾乎接近于唯一值，那么只需要單建idx_a索引即可。

說明：存在非等號和等號混合判斷條件時(shí)，在建索引時(shí)，請把等號條件的列前置。如：wherea>?andb=?那么即使a的區(qū)分度更高，也必須把b放在索引的最前列?！緟⒖肌縿?chuàng)建索引時(shí)避免有如下極端誤解：

?1）

索引寧濫勿缺

誤認(rèn)為一個(gè)查詢就需要建一個(gè)索引。

?2）

吝嗇索引的創(chuàng)建

誤認(rèn)為索引會消耗空間、嚴(yán)重拖慢更新和新增速度。

?3）

抵制唯一索引

誤認(rèn)為唯一索引一律需要在應(yīng)用層通過“先查后插”方式解決。SQL規(guī)約【強(qiáng)制】不要使用count(列名)或count(常量)來替代count(*)，count(*)就是SQL92定義的標(biāo)準(zhǔn)統(tǒng)計(jì)行數(shù)的語法，跟數(shù)據(jù)庫無關(guān)，跟NULL和非NULL無關(guān)。

說明：count(*)會統(tǒng)計(jì)值為NULL的行，而count(列名)不會統(tǒng)計(jì)此列為NULL值的行?！緩?qiáng)制】不得使用外鍵與級聯(lián)，一切外鍵概念必須在應(yīng)用層解決。

說明：（概念解釋）學(xué)生表中的student_id是主鍵，那么成績表中的student_id則為外鍵。如果更新學(xué)生表中的student_id，同時(shí)觸發(fā)成績表中的student_id更新，則為級聯(lián)更新。外鍵與級聯(lián)更新適用于單機(jī)低并發(fā)，不適合分布式、高并發(fā)集群；級聯(lián)更新是強(qiáng)阻塞，存在數(shù)據(jù)庫更新風(fēng)暴的風(fēng)險(xiǎn)；外鍵影響數(shù)據(jù)庫的插入速度。【強(qiáng)制】OB1.0目前不支持存儲過程【推薦】in操作能避免則避免，若實(shí)在避免不了，需要仔細(xì)評估in后邊的集合元素?cái)?shù)量，控制在1000個(gè)之內(nèi)?！緟⒖肌克械淖址鎯εc表示，均以utf-8mb4編碼，【推薦】在業(yè)務(wù)cache表場景中，比如頻繁insert/delete，數(shù)據(jù)生命周期較短的場景，需要添加HINT指定查詢。說明：OB對于這種場景做了rowpurge的優(yōu)化，可以回收delete節(jié)點(diǎn)，提升查詢性能；考慮業(yè)務(wù)場景多樣性，為防止存在rowpurge無法回收的場景導(dǎo)致性能下降，因此推薦業(yè)務(wù)方指定HINT查詢?！就扑]】有時(shí)間精度要求的業(yè)務(wù)，可以使用datetime(6);對精度沒要求的，設(shè)置為datetime即可。ORM規(guī)約【強(qiáng)制】在表查詢中，一律不要使用*作為查詢的字段列表，需要哪些字段必須明確寫明。

說明：1）增加查詢分析器解析成本。2）增減字段容易與resultMap配置不一致。【強(qiáng)制】更新數(shù)據(jù)表記錄時(shí)，必須同時(shí)更新記錄對應(yīng)的gmt_modified字段值為當(dāng)前時(shí)間?！就扑]】不要寫一個(gè)大而全的數(shù)據(jù)更新接口，傳入為POJO類，不管是不是自己的目標(biāo)更新字段，都進(jìn)行updatetablesetc1=value1,c2=value2,c3=value3;這是不對的。執(zhí)行SQL時(shí)，不要更新無改動的字段，一是易出錯(cuò)；二是效率低；三是binlog增加存儲。OceanBase1.0高可用方案集群物理部署高可用對于金融核心業(yè)務(wù)系統(tǒng)，需要保證可以隨著業(yè)務(wù)量的發(fā)展，進(jìn)行水平擴(kuò)展，并且沒有系統(tǒng)單點(diǎn)，不會因?yàn)槟骋慌_機(jī)器或某一個(gè)服務(wù)不可用，而造成整個(gè)系統(tǒng)服務(wù)能力的癱瘓。應(yīng)用服務(wù)器是很容易支持水平擴(kuò)展和負(fù)載均衡的，而往往數(shù)據(jù)庫都是單點(diǎn)。傳統(tǒng)的Mysql/Oracle數(shù)據(jù)庫通過主備鏡像方案進(jìn)行容災(zāi)MYSQLHA：Mysql的主備之間，數(shù)據(jù)同步有秒級的延遲，因?yàn)橛忻爰壍难舆t，當(dāng)主庫宕機(jī)自動切到備庫后，這部分延遲的數(shù)據(jù)在備庫是缺失的。RPO>0OracleDataGuard:OracleDataGuard包含三種同步模式：最大保護(hù)模式：事務(wù)在主庫執(zhí)行成功并且強(qiáng)同步到備庫后才能應(yīng)答客戶端最大性能模式：事務(wù)在主庫執(zhí)行成功后就應(yīng)答客戶端，由后臺線程異步復(fù)制到備庫；最大可用模式：當(dāng)主、備庫數(shù)據(jù)同步鏈路正常時(shí)，采用最大保護(hù)模式；否則，退化為最大性能模式；無論采用OracleGuard/Mysql，傳統(tǒng)關(guān)系數(shù)據(jù)庫要么選擇強(qiáng)一致，要么選擇高可用，二者不可兼得。OceanBase1.0采用分布式投票，即Paxos算法來解決這個(gè)問題。Paxos算法至少要求三個(gè)副本，一個(gè)為主副本，另外兩個(gè)為備副本，事務(wù)要求在主庫執(zhí)行成功并且至少同步到一個(gè)副本才可以構(gòu)成多數(shù)派，從而應(yīng)答客戶端。當(dāng)某個(gè)副本出現(xiàn)故障時(shí)，分為兩種情況。如果是備副本，對系統(tǒng)沒有影響；如果是主副本，Paxos協(xié)議會自動從兩個(gè)備副本中選擇一個(gè)作為新的主副本繼續(xù)提供服務(wù)，并通過協(xié)商來確保完全不丟失數(shù)據(jù)。如果將Paxos需要的三個(gè)副本都部署到一個(gè)機(jī)房，可以容忍單臺服務(wù)器故障；如果想要容忍機(jī)房整體故障，至少需要將副本部署到三個(gè)機(jī)房。為什么呢？假設(shè)只將服務(wù)部署到兩個(gè)機(jī)房，一個(gè)為主，一個(gè)為備，無論如何也無法擺脫傳統(tǒng)關(guān)系數(shù)據(jù)庫的困境。如果每次事務(wù)都強(qiáng)同步到備機(jī)房，那么，備機(jī)房故障將無法提供服務(wù)；如果事務(wù)只在主庫執(zhí)行成功就應(yīng)答客戶端，那么，當(dāng)主機(jī)房出現(xiàn)故障而將服務(wù)切到備機(jī)房時(shí)，將丟失數(shù)據(jù)。這就意味著，要么選擇強(qiáng)一致，要么選擇高可用。在OceanBase1.0版本，我們提出了一系列的部署模式，包括：兩地三中心五副本兩個(gè)城市，一個(gè)城市為主城市，另外一個(gè)城市為備城市。主城市包含兩個(gè)機(jī)房，每個(gè)機(jī)房兩個(gè)副本；備城市只包含一個(gè)機(jī)房，這個(gè)機(jī)房只有一個(gè)副本主副本在主城市的數(shù)據(jù)中心1。如果數(shù)據(jù)中心2整體故障，那么，Paxos協(xié)議會將數(shù)據(jù)中心2中的兩個(gè)副本從成員列表中剔除，成員組由5個(gè)副本降級為3個(gè)副本，以后只需要強(qiáng)同步3個(gè)副本中的2個(gè)即可。大部分情況下，強(qiáng)同步操作可以在數(shù)據(jù)中心1內(nèi)完成，避免跨城市同步。類似地，如果數(shù)據(jù)中心1整體故障，那么，Paxos協(xié)議需要首先將主副本切到數(shù)據(jù)中心2，接著再將成員組由5個(gè)副本降級為3個(gè)副本，以后強(qiáng)同步操作可以在數(shù)據(jù)中心2內(nèi)完成，避免跨城市同步。三地三中心五副本與三地五中心五副本兩地三中心部署方案的問題在于不支持異地容災(zāi)。為了支持地區(qū)級無損容災(zāi)，通過Paxos協(xié)議的原理可以證明，至少需要3個(gè)地區(qū)。OceanBase采用的是兩地三中心的變種方案：三地三中心五副本。該方案包含三個(gè)城市，每個(gè)城市一個(gè)機(jī)房，前兩個(gè)城市的機(jī)房各有兩個(gè)副本，第三個(gè)城市的機(jī)房只有一個(gè)副本。和兩地三中心的不同點(diǎn)在于，每次執(zhí)行事務(wù)至少需要同步到兩個(gè)城市，需要業(yè)務(wù)容忍異地復(fù)制的延時(shí)。如果僅限于杭州和上海這兩個(gè)地區(qū)之間的強(qiáng)同步，那么，需要容忍大約8毫秒左右延時(shí)；如果涉及到長傳鏈路，例如上海和深圳，那么，需要容忍30毫秒左右延時(shí)。三地五中心和三地三中心五副本類似，不同點(diǎn)在于，會把每個(gè)副本部署到不同的機(jī)房，進(jìn)一步強(qiáng)化機(jī)房容災(zāi)能力。上圖為網(wǎng)商銀行OB1.0的物理部署拓?fù)鋵?shí)例，整個(gè)OB大集群部署在三個(gè)城市的5個(gè)機(jī)房內(nèi)，同時(shí)具備了server級別，機(jī)房級別，城市級別的故障無損自動容災(zāi)能力。應(yīng)用高可用-Sharding技術(shù)分庫分表當(dāng)業(yè)務(wù)量低時(shí)，我們的DB設(shè)計(jì)往往是單庫，甚至于多個(gè)業(yè)務(wù)共同使用一個(gè)數(shù)據(jù)庫，它方便快捷，帶來的運(yùn)維成本低。但同時(shí)，當(dāng)單個(gè)數(shù)據(jù)庫故障時(shí)，影響面廣。舉個(gè)例子，早期支付寶的所有系統(tǒng)，只有一臺Oracle數(shù)據(jù)庫，承載著交易、支付、賬務(wù)、會員等等的所有系統(tǒng)，而當(dāng)DB故障，100%服務(wù)不可用。于是將每個(gè)業(yè)務(wù)單獨(dú)拆分，單獨(dú)數(shù)據(jù)庫。再后來，trade單獨(dú)拆分一臺DB，而當(dāng)tradeDB異常，一樣100%不可用。淘寶的TDDL，支付寶的zdal這類中間件的問世，徹底改變了這個(gè)現(xiàn)狀，將數(shù)據(jù)基于一定的規(guī)則進(jìn)行拆分，將單庫單表拆分為了多庫多表，分片之間數(shù)據(jù)互不影響。例如trade拆分100份，將這些數(shù)據(jù)均勻分布在50臺機(jī)器，則單個(gè)實(shí)例故障只影響2%的業(yè)務(wù)，降低業(yè)務(wù)影響。Sharding的作用，在于將單點(diǎn)拆分為多個(gè)分片1、

降低了單個(gè)實(shí)例故障的影響面2、

提升了單機(jī)容量

但sharding并沒有解決業(yè)務(wù)的快速恢復(fù)問題，單個(gè)實(shí)例故障還是影響了部分業(yè)務(wù)，這部分業(yè)務(wù)也只能在DB得以恢復(fù)后才能恢復(fù)業(yè)務(wù)。已網(wǎng)商銀行的業(yè)務(wù)流水號為例：如果分為100表，路由規(guī)則采用ipid（對應(yīng)支付寶cid）或者iprole