① 國內做分布式資料庫開發的現狀如何
應該說，現在是國產分布式資料庫發展的利好時期。在討論發展前景前，首先要先看看分布式資料庫的發展方向。
大家把傳統關系型資料庫稱作oldsql，給人感覺要被淘汰似的。但其實數據量不是很大或者事務處理的場景夏，關系型資料庫的還是占優的。
關系型資料庫的主要問題在於：
性能瓶頸，
單一模型（關系模型），只適合OLTP
應對業務的靈活性不夠，
彈性擴充能力不夠，
兩地三中心和雙活等問題上不足。
隨著互聯網和手機的飛速發展，無論從用戶規模、使用頻率、還是場景多樣性都使得這些問題浮出水面。其實Oracle在92年就開始嘗試轉向分布式，還當時引起了業界的巨大爭論，最後失敗。更何況過去CPU、內存、存儲、帶寬的高成本導致分布式資料庫的性價比並不高，只能停留在學術階段，限制了分布式的發展。
新分布式資料庫首先是要避免和傳統關系型資料庫的競爭，這是明智的選擇，能夠輕裝上陣。因此從幾個方面入手，應對海量數據處理、分析、緩存、流式處理、開發模式等等。相對應列式，KV，Document等多種存儲數據結構。
所有這些都被稱為NoSQL資料庫，放棄ACID和事務能力還換取性能。然而，NoSQL又收到了大量的批評反對意見，主要是說把資料庫應該處理的問題交還給了開發是種發展的倒退。這些問題包括，索引、版本、SQL支持、事務支持等等。市場上超過90%的開發員都需要SQL，而且SQL也是非常有效和成熟。於是大家無論底層是什麼存儲結構又開始支持SQL，形成了NewSQL。
這里插一句題外話，在矽谷已經不再用SQL、NoSQL、NewSQL來劃分資料庫了。理由很簡單，SQL是一種語言，從來沒有SQL資料庫的說法，自然也不應該有NoSQL資料庫的說法。NewSQL資料庫就更不合理，用的SQL並非什麼「New「的新東西。所以專業上用關系型和非關系型資料庫來劃分，分布式資料庫主要都是非關系型資料庫。
回過頭來看國內分布式資料庫市場需求，中小企業不滿足Mysql的性能，分庫分表又很難搞，也不徹底；大型企業被Oracle等壟斷支付高額成本，而且又不解決實際碰到的瓶頸問題。因此，用戶都在尋找新的解決方案。小型用戶、雲計算的用
戶、大型企業都需要對應的分布式資料庫產品。
再加上國產自主和去IOE浪潮，更加推動了國產分布式資料庫的發展利好。值得注意的是，資料庫研發是個嚴肅的事情，沒法短平快。
② 現在國產資料庫有哪些品牌
據我網上找的資料,目前國產資料庫主要有3個1、南京大學通用newsql資料庫——gbase2、達夢新1代雲資料庫——dm73、人大金倉分析型資料庫kingbasees但個人觀點,在國外多個知名商業化資料庫oracle,sqlserver,db2等和開源的資料庫如mysql,postgresql等眼前,這些基本沒有甚麼市場
③ 如何評價SequoiaDB巨杉資料庫
equoiaDB巨杉資料庫 是國內領先的新一代分布式資料庫廠商。
主要產品SequoiaDB是國內唯一一款企業級的新一代分布式、標准化NewSQL資料庫。作為商業化的資料庫產品，現已開源。同時也提供了包括企業數據融合和再加工、非結構化數據管理平台、大數據管理平台在內的多個企業級大數據解決方案。
SequoiaDB巨杉資料庫也於近期發布了SequoiaDB 2.0企業版，新版本加入了SQL2003支持、雙引擎核心存儲、雙活機制等，在企業級功能上超越矽谷同類產品。作為Spark全球的發行商之一，巨杉在2.0時代將提供高並發實時計算、高吞吐量批處理分析、以及在線流處理計算等一系列企業級解決方案，SequoiaDB巨杉資料庫平台可以幫助企業快速地進行跨系統的數據融和、提煉和再加工。
近期，在當前的資本寒冬之下，巨杉於近期獲得了DCM領投的近億元B輪融資。這體現了投資界對於這家務實的大數據基礎軟體公司發展的一致看好，而此次融資也成為國內新一代分布式資料庫領域最大的一筆投融資。
④ 分庫分表 VS newsql資料庫
最近與同行 科技 交流，經常被問到分庫分表與分布式資料庫如何選擇，網上也有很多關於中間件+傳統關系資料庫（分庫分表）與NewSQL分布式資料庫的文章，但有些觀點與判斷是我覺得是偏激的，脫離環境去評價方案好壞其實有失公允。
本文通過對兩種模式關鍵特性實現原理對比，希望可以盡可能客觀、中立的闡明各自真實的優缺點以及適用場景。
首先關於「中間件+關系資料庫分庫分表」算不算NewSQL分布式資料庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據該文中的分類，Spanner、TiDB、OB算是第一種新架構型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種雲資料庫，本文暫不詳細介紹）。
基於中間件（包括SDK和Proxy兩種形式）+傳統關系資料庫（分庫分表）模式是不是分布式架構？我覺得是的，因為存儲確實也分布式了，也能實現橫向擴展。但是不是"偽"分布式資料庫？從架構先進性來看，這么說也有一定道理。"偽"主要體現在中間件層與底層DB重復的SQL解析與執行計劃生成、存儲引擎基於B+Tree等，這在分布式資料庫架構中實際上冗餘低效的。為了避免引起真偽分布式資料庫的口水戰，本文中NewSQL資料庫特指這種新架構NewSQL資料庫。
NewSQL資料庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構對比圖：
這些大多也是NewSQL資料庫產品主要宣傳的點，不過這些看起來很美好的功能是否真的如此？接下來針對以上幾點分別闡述下的我的理解。
這是把雙刃劍。
CAP限制
想想更早些出現的NoSQL資料庫為何不支持分布式事務（最新版的mongoDB等也開始支持了），是缺乏理論與實踐支撐嗎？並不是，原因是CAP定理依然是分布式資料庫頭上的頸箍咒，在保證強一致的同時必然會犧牲可用性A或分區容忍性P。為什麼大部分NoSQL不提供分布式事務？
那麼NewSQL資料庫突破CAP定理限制了嗎？並沒有。NewSQL資料庫的鼻主Google Spanner（目前絕大部分分布式資料庫都是按照Spanner架構設計的）提供了一致性和大於5個9的可用性，宣稱是一個「實際上是CA」的，其真正的含義是 系統處於 CA 狀態的概率非常高，由於網路分區導致的服務停用的概率非常小 ，究其真正原因是其打造私有全球網保證了不會出現網路中斷引發的網路分區，另外就是其高效的運維隊伍,這也是cloud spanner的賣點。詳細可見CAP提出者Eric Brewer寫的《Spanner, TrueTime 和CAP理論》。
完備性 ：
兩階段提交協議是否嚴格支持ACID，各種異常場景是不是都可以覆蓋？
2PC在commit階段發送異常，其實跟最大努力一階段提交類似也會有部分可見問題，嚴格講一段時間內並不能保證A原子性和C一致性（待故障恢復後recovery機制可以保證最終的A和C）。完備的分布式事務支持並不是一件簡單的事情，需要可以應對網路以及各種硬體包括網卡、磁碟、CPU、內存、電源等各類異常，通過嚴格的測試。之前跟某友商交流，他們甚至說目前已知的NewSQL在分布式事務支持上都是不完整的，他們都有案例跑不過，圈內人士這么篤定，也說明了 分布式事務的支持完整程度其實是層次不齊的。
但分布式事務又是這些NewSQL資料庫的一個非常重要的底層機制，跨資源的DML、DDL等都依賴其實現，如果這塊的性能、完備性打折扣，上層跨分片SQL執行的正確性會受到很大影響。
性能
傳統關系資料庫也支持分布式事務XA，但為何很少有高並發場景下用呢？ 因為XA的基礎兩階段提交協議存在網路開銷大，阻塞時間長、死鎖等問題，這也導致了其實際上很少大規模用在基於傳統關系資料庫的OLTP系統中。
NewSQL資料庫的分布式事務實現也仍然多基於兩階段提交協議，例如google percolator分布式事務模型，
採用原子鍾+MVCC+ Snapshot Isolation（SI），這種方式通過TSO(Timestamp Oracle)保證了全局一致性，通過MVCC避免了鎖，另外通過primary lock和secondary lock將提交的一部分轉為非同步，相比XA確實提高了分布式事務的性能。
但不管如何優化，相比於1PC，2PC多出來的GID獲取、網路開銷、prepare日誌持久化還是會帶來很大的性能損失，尤其是跨節點的數量比較多時會更加顯著，例如在銀行場景做個批量扣款，一個文件可能上W個賬戶，這樣的場景無論怎麼做還是吞吐都不會很高。
雖然NewSQL分布式資料庫產品都宣傳完備支持分布式事務，但這並不是說應用可以完全不用關心數據拆分，這些資料庫的最佳實踐中仍然會寫到，應用的大部分場景盡可能避免分布式事務。
既然強一致事務付出的性能代價太大，我們可以反思下是否真的需要這種強一致的分布式事務？尤其是在做微服務拆分後，很多系統也不太可能放在一個統一的資料庫中。嘗試將一致性要求弱化，便是柔性事務，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對於大規模高並發OLTP場景，我個人更建議使用柔性事務而非強一致的分布式事務。關於柔性事務，筆者之前也寫過一個技術組件，最近幾年也涌現出了一些新的模型與框架（例如阿里剛開源的Fescar），限於篇幅不再贅述，有空再單獨寫篇文章。
HA與異地多活
主從模式並不是最優的方式，就算是半同步復制，在極端情況下（半同步轉非同步）也存在丟數問題，目前業界公認更好的方案是基於paxos分布式一致性協議或者其它類paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都採用了這種方式，基於Paxos協議的多副本存儲，遵循過半寫原則，支持自動選主，解決了數據的高可靠，縮短了failover時間，提高了可用性，特別是減少了運維的工作量，這種方案技術上已經很成熟，也是NewSQL資料庫底層的標配。
當然這種方式其實也可以用在傳統關系資料庫，阿里、微信團隊等也有將MySQL存儲改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預計不遠的未來主從模式可能就成為 歷史 了。
需要注意的是很多NewSQL資料庫廠商宣傳基於paxos或raft協議可以實現【異地多活】，這個實際上是有前提的，那就是異地之間網路延遲不能太高 。以銀行「兩地三中心」為例，異地之間多相隔數千里，延時達到數十毫秒，如果要多活，那便需異地副本也參與資料庫日誌過半確認，這樣高的延時幾乎沒有OLTP系統可以接受的。
資料庫層面做異地多活是個美好的願景，但距離導致的延時目前並沒有好的方案。 之前跟螞蟻團隊交流，螞蟻異地多活的方案是在應用層通過MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發生異地切換，資料庫同步中間件會告之數據延遲時間，應用從緩存中讀取交易信息，將這段時間內涉及到的業務對象例如用戶、賬戶進行黑名單管理，等數據同步追上之後再將這些業務對象從黑名單中剔除。由於雙寫的不是所有資料庫操作日誌而只是交易信息，數據延遲隻影響一段時間內數據，這是目前我覺得比較靠譜的異地度多活方案。
另外有些系統進行了單元化改造，這在paxos選主時也要結合考慮進去，這也是目前很多NewSQL資料庫欠缺的功能。
Scale橫向擴展與分片機制
paxos演算法解決了高可用、高可靠問題，並沒有解決Scale橫向擴展的問題，所以分片是必須支持的。NewSQL資料庫都是天生內置分片機制的，而且會根據每個分片的數據負載(磁碟使用率、寫入速度等)自動識別熱點，然後進行分片的分裂、數據遷移、合並，這些過程應用是無感知的，這省去了DBA的很多運維工作量。以TiDB為例，它將數據切成region，如果region到64M時，數據自動進行遷移。
分庫分表模式下需要應用設計之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈希或者自定義路由表）、路由規則、拆分庫表數量、擴容方式等。相比NewSQL資料庫，這種模式給應用帶來了很大侵入和復雜度，這對大多數系統來說也是一大挑戰。
這里有個問題是NewSQL資料庫統一的內置分片策略（例如tidb基於range）可能並不是最高效的，因為與領域模型中的劃分要素並不一致，這導致的後果是很多交易會產生分布式事務。 舉個例子，銀行核心業務系統是以客戶為維度，也就是說客戶表、該客戶的賬戶表、流水表在絕大部分場景下是一起寫的，但如果按照各表主鍵range進行分片，這個交易並不能在一個分片上完成，這在高頻OLTP系統中會帶來性能問題。
分布式SQL支持
常見的單分片SQL，這兩者都能很好支持。NewSQL資料庫由於定位與目標是一個通用的資料庫，所以支持的SQL會更完整，包括跨分片的join、聚合等復雜SQL。中間件模式多面向應用需求設計，不過大部分也支持帶拆分鍵SQL、庫表遍歷、單庫join、聚合、排序、分頁等。但對跨庫的join以及聚合支持就不夠了。
NewSQL資料庫一般並不支持存儲過程、視圖、外鍵等功能，而中間件模式底層就是傳統關系資料庫，這些功能如果只是涉及單庫是比較容易支持的。
NewSQL資料庫往往選擇兼容MySQL或者PostgreSQL協議，所以SQL支持僅局限於這兩種，中間件例如驅動模式往往只需做簡單的SQL解析、計算路由、SQL重寫，所以可以支持更多種類的資料庫SQL。
SQL支持的差異主要在於分布式SQL執行計劃生成器，由於NewSQL資料庫具有底層數據的分布、統計信息，因此可以做CBO，生成的執行計劃效率更高，而中間件模式下沒有這些信息，往往只能基於規則RBO（Rule-Based-Opimization），這也是為什麼中間件模式一般並不支持跨庫join，因為實現了效率也往往並不高，還不如交給應用去做。
存儲引擎
傳統關系資料庫的存儲引擎設計都是面向磁碟的，大多都基於B+樹。B+樹通過降低樹的高度減少隨機讀、進而減少磁碟尋道次數，提高讀的性能，但大量的隨機寫會導致樹的分裂，從而帶來隨機寫，導致寫性能下降。NewSQL的底層存儲引擎則多採用LSM，相比B+樹LSM將對磁碟的隨機寫變成順序寫，大大提高了寫的性能。不過LSM的的讀由於需要合並數據性能比B+樹差，一般來說LSM更適合應在寫大於讀的場景。當然這只是單純數據結構角度的對比，在資料庫實際實現時還會通過SSD、緩沖、bloom filter等方式優化讀寫性能，所以讀性能基本不會下降太多。NewSQL數據由於多副本、分布式事務等開銷，相比單機關系資料庫SQL的響應時間並不佔優，但由於集群的彈性擴展，整體QPS提升還是很明顯的，這也是NewSQL資料庫廠商說分布式資料庫更看重的是吞吐，而不是單筆SQL響應時間的原因。
成熟度與生態
分布式資料庫是個新型通用底層軟體，准確的衡量與評價需要一個多維度的測試模型，需包括發展現狀、使用情況、社區生態、監控運維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測試、高可用測試、在線擴容、分布式事務、隔離級別、在線DDL等等，雖然NewSQL資料庫發展經過了一定時間檢驗，但多集中在互聯網以及傳統企業非核心交易系統中，目前還處於快速迭代、規模使用不斷優化完善的階段。
相比而言，傳統關系資料庫則經過了多年的發展，通過完整的評測，在成熟度、功能、性能、周邊生態、風險把控、相關人才積累等多方面都具有明顯優勢，同時對已建系統的兼容性也更好。
對於互聯網公司，數據量的增長壓力以及追求新技術的基因會更傾向於嘗試NewSQL資料庫，不用再考慮庫表拆分、應用改造、擴容、事務一致性等問題怎麼看都是非常吸引人的方案。
對於傳統企業例如銀行這種風險意識較高的行業來說，NewSQL資料庫則可能在未來一段時間內仍處於 探索 、審慎試點的階段。基於中間件+分庫分表模式架構簡單，技術門檻更低，雖然沒有NewSQL資料庫功能全面，但大部分場景最核心的訴求也就是拆分後SQL的正確路由，而此功能中間件模式應對還是綽綽有餘的，可以說在大多數OLTP場景是夠用的。
限於篇幅，其它特性例如在線DDL、數據遷移、運維工具等特性就不在本文展開對比。
總結
如果看完以上內容，您還不知道選哪種模式，那麼結合以下幾個問題，先思考下NewSQL資料庫解決的點對於自身是不是真正的痛點：
如果以上有2到3個是肯定的，那麼你可以考慮用NewSQL資料庫了，雖然前期可能需要一定的學習成本，但它是資料庫的發展方向，未來收益也會更高，尤其是互聯網行業，隨著數據量的突飛猛進，分庫分表帶來的痛苦會與日俱增。當然選擇NewSQL資料庫你也要做好承擔一定風險的准備。
如果你還未做出抉擇，不妨再想想下面幾個問題：
如果這些問題有多數是肯定的，那還是分庫分表吧。在軟體領域很少有完美的解決方案，NewSQL資料庫也不是數據分布式架構的銀彈。相比而言分庫分表是一個代價更低、風險更小的方案，它最大程度復用傳統關系資料庫生態，通過中間件也可以滿足分庫分表後的絕大多數功能，定製化能力更強。 在當前NewSQL資料庫還未完全成熟的階段，分庫分表可以說是一個上限低但下限高的方案，尤其傳統行業的核心系統，如果你仍然打算把資料庫當做一個黑盒產品來用，踏踏實實用好分庫分表會被認為是個穩妥的選擇。
很多時候軟體選型取決於領域特徵以及架構師風格，限於筆者知識與所屬行業特點所限，以上僅為個人粗淺的一些觀點，歡迎討論。
⑤ newsql和nosql的區別和聯系
TiDB 是 PingCAP 公司設計的開源分布式 HTAP (Hybrid Transactional and Analytical Processing) 資料庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具備強一致性和高可用性。TiDB 的目標是為 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。
TiDB 具備如下特性：
高度兼容 MySQL
大多數情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表後的 MySQL 集群亦可通過 TiDB 工具進行實時遷移。
水平彈性擴展
通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。
分布式事務
TiDB 100% 支持標準的 ACID 事務。
真正金融級高可用
相比於傳統主從 (M-S) 復制方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。
一站式 HTAP 解決方案
TiDB 作為典型的 OLTP 行存資料庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解決方案，一份存儲同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程。
雲原生 SQL 資料庫
TiDB 是為雲而設計的資料庫，支持公有雲、私有雲和混合雲，配合TiDB Operator 項目可實現自動化運維，使部署、配置和維護變得十分簡單。
TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析可以通過TiSpark 項目來完成。
TiDB 對業務沒有任何侵入性，能優雅地替換傳統的資料庫中間件、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注資料庫 Scale 的細節問題，專注於業務開發，極大地提升研發的生產力。
⑥ 如何評價SequoiaDB巨杉資料庫
equoiaDB巨杉資料庫 是國內領先的新一代分布式資料庫廠商。
主要產品SequoiaDB是國內唯一一款企業級的新一代分布式、標准化NewSQL資料庫。作為商業化的資料庫產品，現已開源。同時也提供了包括企業數據融合和再加工、非結構化數據管理平台、大數據管理平台在內的多個企業級大數據解決方案。
SequoiaDB巨杉資料庫也於近期發布了SequoiaDB 2.0企業版，新版本加入了SQL2003支持、雙引擎核心存儲、雙活機制等，在企業級功能上超越矽谷同類產品。作為Spark全球的發行商之一，巨杉在2.0時代將提供高並發實時計算、高吞吐量批處理分析、以及在線流處理計算等一系列企業級解決方案，SequoiaDB巨杉資料庫平台可以幫助企業快速地進行跨系統的數據融和、提煉和再加工。
近期，在當前的資本寒冬之下，巨杉於近期獲得了DCM領投的近億元B輪融資。這體現了投資界對於這家務實的大數據基礎軟體公司發展的一致看好，而此次融資也成為國內新一代分布式資料庫領域最大的一筆投融資。
⑦ NewSQL為何使傳統關系資料庫黯然失色
傳統資料庫仍舊會有一席之地，至於NewSQL的優勢又是什麼，簡單和大家說說：
首先關於「中間件+關系資料庫分庫分表」算不算NewSQL分布式資料庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據該文中的分類，Spanner、TiDB、OB算是第一種新架構型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種雲資料庫，本文暫不詳細介紹）。
基於中間件（包括SDK和Proxy兩種形式）+傳統關系資料庫（分庫分表）模式是不是分布式架構？我覺得是的，因為存儲確實也分布式了，也能實現橫向擴展。但是不是「偽」分布式資料庫？從架構先進性來看，這么說也有一定道理。
「偽」主要體現在中間件層與底層DB重復的SQL解析與執行計劃生成、存儲引擎基於B+Tree等，這在分布式資料庫架構中實際上冗餘低效的。為了避免引起真偽分布式資料庫的口水戰，本文中NewSQL資料庫特指這種新架構NewSQL資料庫。
NewSQL資料庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構對比圖：
- 傳統資料庫面向磁碟設計，基於內存的存儲管理及並發控制，不如NewSQL資料庫那般高效利用；
- 中間件模式SQL解析、執行計劃優化等在中間件與資料庫中重復工作，效率相比較低；
- NewSQL資料庫的分布式事務相比於XA進行了優化，性能更高；
- 新架構NewSQL資料庫存儲設計即為基於paxos（或Raft）協議的多副本，相比於傳統資料庫主從模式（半同步轉非同步後也存在丟數問題），在實現了真正的高可用、高可靠（RTO<30s，RPO=0）；
- NewSQL資料庫天生支持數據分片，數據的遷移、擴容都是自動化的，大大減輕了DBA的工作，同時對應用透明，無需在SQL指定分庫分表鍵。
⑧ 資料庫為什麼要分庫分表
1 基本思想之什麼是分庫分表？
從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2 基本思想之為什麼要分庫分表？
數
據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增
刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（CPU、磁碟、內存、IO等）是有限的，最終資料庫所能承載的數據量、
數據處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1
何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workDB、商品資料庫payDB、用戶數據
庫userDB、日誌資料庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
3.2
何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然後存儲到多個結構相同的表，和不同的庫
上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、
part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，
然後將這些表按照一定的規則存儲到多個userDB上。
3.3 應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。
而
如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體
的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。
4 分庫分表存在的問題。
4.1 事務問題。
在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額
外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於
一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order
by語句就可以搞定，但是在進行分表之後，將需要n個order
by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。
⑨ 什麼是資料庫啊
資料庫是一種存儲技術。最簡單和通俗地理解就是，我們把需要存儲的內容做成一張張二維表格，資料庫負責把這些表存放到計算機的磁碟上，並提供增、刪、改、查詢等各種手段來維護和管理這它們。最傳統的關系型資料庫就是這樣的。數據量小的一台計算機就可以搞定，當數據量越來越大，就需要專用的存儲介質（比如存儲陣列）來放，到後來要讀和寫的人越來越多，就需要多台計算機搭配存儲陣列一起來工作，其中一台負責寫，多台讀。數據量再大就需要分布式架構，多台讀、多台寫。現在在關系型資料庫之外，還有NoSQL、NewSQL等資料庫出來，它們提供更自由的保存數據的方式，能儲存更多數據。
⑩ 關於NewSQL資料庫對於CAP的再解釋
作者 石默研
關於CAP的討論已經很多，包括作者的另一篇文章「對CAP的初步解釋」，基本已經即定思維的理解就是：分布式系統必須遵循CAP，一個分布式系統的設計只能同時滿足其中兩個，不可能同時滿足；傳統關系資料庫選擇A與C，代表了互聯網新興技術的NoSQL資料庫則選擇A與P（或者C與P，雖然這種情況其實需要詳細討論）。
但是，近年來，新興的NewSQL資料庫（TiDB或者OceanBase），則是一種在分布式環境下，保證的ACID強事務特徵的強一致性資料庫，並且很顯然，它同時也滿足了高可用性與優秀的分區可容忍性（很好的可擴展特性便是其一個層面的證明），似乎看起來，C、A、P都同時保證了，這不是違反了已經經過嚴格證明的CAP理論嗎？
這個問題初看起來，似乎是比較神奇，但仔細分析，其實答案是很明顯的。
首先，需要讀者區分「分布式」與CAP中所提到的分區可容忍性Paritition Tolerance並不是一回事。分區可容忍性P是指以下兩種分布式的情況：
. 同一份數據的多個副本的可分布性
. 有相互關聯的數據的可分布性（操作中表現為保證ACID的強分布式事務）
即使是分庫分表，如果不存在以上兩種情況，只是獨立數據在同一個節點上的情況，雖然也是分布式，但跟CAP中的P沒有半毛錢關系。
那麼，還是回到上面的問題，NewSQL資料庫，確實也是在保證了同一份數據多副本的強讀寫一致性、以及強分布式事務特性這樣的C的情況下，同時保證了A與P呀！事實確實如此，但這還是要仔細分析：
無論是TiDB，還是OceanBase，其在保證數據多副本的強一致性時，都採用了Paxos協議或者Raft，它們簡單來講就是多數選舉的原則，即寫不需要全部副本都完成，就能保證讀的強一致性，反過來也是一樣。因此，其在分布式情況下，保證數據讀寫強一致性的效率還是很高的，就是說，在同一個數據中心的網路環境下，雖然這種分布可容忍性的滿足理論上講也會比單節點多一點點效率損失，但實際上是可以忽略不計的。但需要指出的是，在跨數據中心、跨城市的分布式情況下，如果要保證數據多副本的強一致性，即保證分區可容忍性，對效率（實際上是可用性A）的影響那還是不可忽略的。因此，在這種情況下，CAP理論依然成立。
再來看相互關聯數據的可分布性，這就涉及到了分布式事務。現有的NewSQL資料庫，即使在同一數據中心，為了保證強的分布式事務，對效率的折衷都是不可忽略的，所謂的樂觀事務，只是因為客觀問題本身沖突就少，並不改變沖突很多時效率明顯受影響的現實。因此，NewSQL資料庫雖然提供強分布式事務的能力，但在現實應用中，都是提倡盡量避免大量的分布式事務出現。如果你所遇到的應用場景是確實需要大量的分布式事務執行，又不做應用優化全交給資料庫執行，那麼，現有的NewSQL分布式資料庫，依然會遇到明顯的性能問題，其實就是可用性A降低了。同學仔細去研究應用中的實際情況就會發現，很多互聯網應用，當其所需要的QPS很高很高，而對讀寫一致性與強分布式事務的要求又不那很高時候，其實，NewSQL資料庫還是不能滿足他們的需求的，他們仍然需要根據自己的情況改造或者選用NoSQL資料庫，這也是CAP理論並沒有被NewSQL打破的現實證明。
因此，總結來講，NewSQL資料庫，也是遵循CAP理論的，只不過，在同中心數據多副本情況下，保證P的同時對A的影響微乎其微；而在分布式事務的情況下，又採用了與應用特性相關的策略（其實樂觀、悲觀事務本質上就有根本應用特性區分的意思）來保證性能而已。當然，隨著網路與計算機性能的提高，CAP三個特徵中，保證其中兩個，折衷另外一個，所帶來的影響也會逐漸變小，但其理論依然是正確的。