男女做那個(gè)暖暖網(wǎng)站百度標(biāo)注平臺(tái)怎么加入
目錄
一、ShardingSphere分庫分表產(chǎn)品介紹
二、客戶端分庫分表與服務(wù)端分庫分表
1、ShardingJDBC客戶端分庫分表
2、ShardingProxy服務(wù)端分庫分表
3、ShardingSphere混合部署架構(gòu)
三、分庫分表,能不分就不分!
1、為什么要分庫分表?
2、分庫分表的優(yōu)勢(shì)
3、分庫分表的挑戰(zhàn)
一、ShardingSphere分庫分表產(chǎn)品介紹
shardingsphere官網(wǎng)地址:Apache ShardingSphere
?
ShardingSphere是一款起源于當(dāng)當(dāng)網(wǎng)內(nèi)部的應(yīng)用框架。2015年在當(dāng)當(dāng)網(wǎng)內(nèi)部誕生,最初就叫ShardingJDBC。2016年的時(shí)候,由其中一個(gè)主要的開發(fā)人員張亮,帶入到京東數(shù)科,組件團(tuán)隊(duì)繼續(xù)開發(fā)。在國(guó)內(nèi)歷經(jīng)了當(dāng)當(dāng)網(wǎng)、電信翼支付、京東數(shù)科等多家大型互聯(lián)網(wǎng)企業(yè)的考驗(yàn),在2017年開始開源。并逐漸由原本只關(guān)注于關(guān)系型數(shù)據(jù)庫增強(qiáng)工具的ShardingJDBC升級(jí)成為一整套以數(shù)據(jù)分片為基礎(chǔ)的數(shù)據(jù)生態(tài)圈,更名為ShardingSphere。到2020年4月,已經(jīng)成為了Apache軟件基金會(huì)的頂級(jí)項(xiàng)目。發(fā)展至今,已經(jīng)成為了業(yè)界分庫分表最成熟的產(chǎn)品。
ShardingSphere這個(gè)詞可以分為兩個(gè)部分,其中Sharding就是我們之前介紹過的數(shù)據(jù)分片。從官網(wǎng)介紹上就能看到,他的核心功能就是可以將任意數(shù)據(jù)庫組合,轉(zhuǎn)換成為一個(gè)分布式的數(shù)據(jù)庫,提供整體的數(shù)據(jù)庫集群服務(wù)。只是給自己的定位并不是Database,而是Database plus。其實(shí)這個(gè)意思是他自己并不做數(shù)據(jù)存儲(chǔ),而是對(duì)其他數(shù)據(jù)庫產(chǎn)品進(jìn)行整合。整個(gè)ShardingSphere其實(shí)就是圍繞數(shù)據(jù)分片這個(gè)核心功能發(fā)展起來的。
后面的Sphere是生態(tài)的意思。這意味著ShardingSphere不是一個(gè)單獨(dú)的框架或者產(chǎn)品,而是一個(gè)由多個(gè)框架以及產(chǎn)品構(gòu)成的一個(gè)完整的技術(shù)生態(tài)。目前ShardingSphere中比較成型的產(chǎn)品主要包含核心的ShardingJDBC以及ShardingProxy兩個(gè)產(chǎn)品,以及一個(gè)用于數(shù)據(jù)遷移的子項(xiàng)目ElasticJob。另外現(xiàn)在也提供了基于公有云的云上服務(wù)ShardingSphere-on-Cloud。
ShardingSphere經(jīng)過這么多年的發(fā)展,已經(jīng)不僅僅只是用來做分庫分表,而是形成了一個(gè)圍繞分庫分表核心的技術(shù)生態(tài)。他的核心功能已經(jīng)包括了數(shù)據(jù)分片、分布式事務(wù)、讀寫分離、高可用、數(shù)據(jù)遷移、聯(lián)邦查詢、數(shù)據(jù)加密、影子庫、DistSQL龐大的技術(shù)體系。
目前ShardingSphere已經(jīng)演進(jìn)到了5.x大版本。在這個(gè)大版本中,ShardingSphere的核心是可插拔。其核心設(shè)計(jì)哲學(xué)就是連接、增強(qiáng)以及可拔插。這是官網(wǎng)對(duì)于其整個(gè)設(shè)計(jì)哲學(xué)的核心描述。
二、客戶端分庫分表與服務(wù)端分庫分表
ShardingSphere最為核心的產(chǎn)品有兩個(gè):一個(gè)是ShardingJDBC,這是一個(gè)進(jìn)行客戶端分庫分表的框架。另一個(gè)是ShardingProxy,這是一個(gè)進(jìn)行服務(wù)端分庫分表的產(chǎn)品。他們代表了兩種不同的分庫分表的實(shí)現(xiàn)思路。
1、ShardingJDBC客戶端分庫分表
ShardingSphere-JDBC 定位為輕量級(jí) Java 框架,在 Java 的 JDBC 層提供的額外服務(wù)。 它使用客戶端直連數(shù)據(jù)庫,以 jar 包形式提供服務(wù),無需額外部署和依賴,可理解為增強(qiáng)版的 JDBC 驅(qū)動(dòng),完全兼容 JDBC 和各種 ORM 框架。
- 適用于任何基于 JDBC 的 ORM 框架,如:JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC;
- 支持任何第三方的數(shù)據(jù)庫連接池,如:DBCP, C3P0, BoneCP, HikariCP 等;
- 支持任意實(shí)現(xiàn) JDBC 規(guī)范的數(shù)據(jù)庫,目前支持 MySQL,PostgreSQL,Oracle,SQLServer 以及任何可使用 JDBC 訪問的數(shù)據(jù)庫。
這是ShardingSphere最初的產(chǎn)品形態(tài)。
2、ShardingProxy服務(wù)端分庫分表
ShardingSphere-Proxy 定位為透明化的數(shù)據(jù)庫代理端,通過實(shí)現(xiàn)數(shù)據(jù)庫二進(jìn)制協(xié)議,對(duì)異構(gòu)語言提供支持。 目前提供 MySQL 和 PostgreSQL 協(xié)議,透明化數(shù)據(jù)庫操作,對(duì) DBA 更加友好。
- 向應(yīng)用程序完全透明,可直接當(dāng)做 MySQL/PostgreSQL 使用;
- 兼容 MariaDB 等基于 MySQL 協(xié)議的數(shù)據(jù)庫,以及 openGauss 等基于 PostgreSQL 協(xié)議的數(shù)據(jù)庫;
- 適用于任何兼容 MySQL/PostgreSQL 協(xié)議的客戶端,如:MySQL Command Client, MySQL Workbench, Navicat 等。
3、ShardingSphere混合部署架構(gòu)
這兩個(gè)產(chǎn)品都各有優(yōu)勢(shì)。ShardingJDBC跟客戶端在一起,使用更加靈活。而ShardingProxy是一個(gè)獨(dú)立部署的服務(wù),所以他的功能相對(duì)就比較固定。他們的整體區(qū)別如下:
ShardingSphere-JDBC | ShardingSphere-Proxy | |
數(shù)據(jù)庫 | 任意 |
|
連接消耗數(shù) | 高 |
|
異構(gòu)語言 | 僅 Java |
|
性能 | 損耗低 |
|
無中心化 | 是 |
|
靜態(tài)入口 | 無 |
|
另外,在產(chǎn)品圖中,Governance Center也是其中重要的部分。他的作用有點(diǎn)類似于微服務(wù)架構(gòu)中的配置中心,可以使用第三方服務(wù)統(tǒng)一管理分庫分表的配置信息,當(dāng)前建議使用的第三方服務(wù)是Zookeeper,同時(shí)也支持Nacos,Etcd等其他第三方產(chǎn)品。
由于ShardingJDBC和ShardingProxy都支持通過Governance Center,將配置信息交個(gè)第三方服務(wù)管理,因此,也就自然支持了通過Governance Center進(jìn)行整合的混合部署架構(gòu)。
三、分庫分表,能不分就不分!
1、為什么要分庫分表?
數(shù)據(jù)庫,應(yīng)該是一個(gè)應(yīng)用當(dāng)中最為核心的價(jià)值所在,也是開發(fā)過程中必須熟練掌握的工具。之前我們就學(xué)習(xí)過很多對(duì)MySQL的調(diào)優(yōu)。但是隨著現(xiàn)在互聯(lián)網(wǎng)應(yīng)用越來越大,數(shù)據(jù)庫會(huì)頻繁的成為整個(gè)應(yīng)用的性能瓶頸。我們經(jīng)常使用的MySQL數(shù)據(jù)庫,也就不斷面臨數(shù)據(jù)量太大、數(shù)據(jù)訪問太頻繁、數(shù)據(jù)讀寫速度太快等一系列的問題。而傳統(tǒng)的這些調(diào)優(yōu)方式,在真正面對(duì)海量數(shù)據(jù)沖擊時(shí),往往就會(huì)顯得很無力。因此,現(xiàn)在互聯(lián)網(wǎng)對(duì)于數(shù)據(jù)庫的使用也越來越小心謹(jǐn)慎。例如添加Redis緩存、增加MQ進(jìn)行流量削峰等。但是,數(shù)據(jù)庫本身如果性能得不到提升,這就相當(dāng)于是水桶理論中的最短板。
要提升數(shù)據(jù)庫的性能,最直接的思路,當(dāng)然是對(duì)數(shù)據(jù)庫本身進(jìn)行優(yōu)化。例如對(duì)MySQL進(jìn)行調(diào)優(yōu),優(yōu)化SQL邏輯,優(yōu)化索引結(jié)構(gòu),甚至像阿里等互聯(lián)網(wǎng)大廠一樣,直接優(yōu)化MySQL的源碼。但是這種思路在面對(duì)互聯(lián)網(wǎng)環(huán)境時(shí),會(huì)有很多非常明顯的弊端。
- 數(shù)據(jù)量和業(yè)務(wù)量快速增長(zhǎng),會(huì)帶來性能瓶頸、服務(wù)宕機(jī)等很多問題。
- 單點(diǎn)部署的數(shù)據(jù)庫無法保證服務(wù)高可用。
- 單點(diǎn)部署的數(shù)據(jù)庫無法進(jìn)行水平擴(kuò)展,難以應(yīng)對(duì)業(yè)務(wù)爆發(fā)式的增長(zhǎng)。
這些問題背后的核心還是數(shù)據(jù)。數(shù)據(jù)庫不同于上層的一些服務(wù),他所管理的數(shù)據(jù)甚至比服務(wù)本身更重要。即要保證數(shù)據(jù)能夠持續(xù)穩(wěn)定的寫入,又不能因?yàn)榉?wù)故障造成數(shù)據(jù)丟失。現(xiàn)在互聯(lián)網(wǎng)上的大型應(yīng)用,動(dòng)輒幾千萬上億的數(shù)據(jù)量,就算做好數(shù)據(jù)的壓縮,隨隨便便也可以超過任何服務(wù)器的存儲(chǔ)能力。并且,服務(wù)器單點(diǎn)部署,也無法真正解決把雞蛋放在一個(gè)籃子里的問題。將數(shù)據(jù)放在同一個(gè)服務(wù)器上,如果服務(wù)器出現(xiàn)崩潰,就很難保證數(shù)據(jù)的安全性。這些都不是光靠?jī)?yōu)化MySQL產(chǎn)品,優(yōu)化服務(wù)器配置能夠解決的問題。
2、分庫分表的優(yōu)勢(shì)
那么自然就需要換另外一種思路了。我們可以像微服務(wù)架構(gòu)一樣,來維護(hù)數(shù)據(jù)庫的服務(wù)。把數(shù)據(jù)庫從單體服務(wù)升級(jí)到數(shù)據(jù)庫集群,這樣才能真正全方位解放數(shù)據(jù)庫的性能瓶頸,并且能夠通過水平擴(kuò)展的方式,靈活提升數(shù)據(jù)庫的存儲(chǔ)能力。這也就是我們常說的分庫分表。通過分庫分表可以給數(shù)據(jù)庫帶來很大的好處:
- 提高系統(tǒng)性能:分庫分表可以將大型數(shù)據(jù)庫分成多個(gè)小型數(shù)據(jù)庫,每個(gè)小型數(shù)據(jù)庫只需要處理部分?jǐn)?shù)據(jù),因此可以提高數(shù)據(jù)庫的并發(fā)處理能力和查詢性能。
- 提高系統(tǒng)可用性:分庫分表可以將數(shù)據(jù)復(fù)制到多個(gè)數(shù)據(jù)庫中,以提高數(shù)據(jù)的可用性和可靠性。如果一個(gè)數(shù)據(jù)庫崩潰了,其他數(shù)據(jù)庫可以接管其工作,以保持系統(tǒng)的正常運(yùn)行。
- 提高系統(tǒng)可擴(kuò)展性:分庫分表可以使系統(tǒng)更容易擴(kuò)展。當(dāng)數(shù)據(jù)量增加時(shí),只需要增加更多的數(shù)據(jù)庫和表,而不是替換整個(gè)數(shù)據(jù)庫,因此系統(tǒng)的可擴(kuò)展性更高。
- 提高系統(tǒng)靈活性:分庫分表可以根據(jù)數(shù)據(jù)的使用情況,對(duì)不同的數(shù)據(jù)庫和表進(jìn)行不同的優(yōu)化。例如,可以將經(jīng)常使用的數(shù)據(jù)存儲(chǔ)在性能更好的數(shù)據(jù)庫中,或者將特定類型的數(shù)據(jù)存儲(chǔ)在特定的表中,以提高系統(tǒng)的靈活性。
- 降低系統(tǒng)成本:分庫分表可以使系統(tǒng)更加高效,因此可以降低系統(tǒng)的運(yùn)營(yíng)成本。此外,分庫分表可以使用更便宜的硬件和存儲(chǔ)設(shè)備,因?yàn)槊總€(gè)小型數(shù)據(jù)庫和表需要的資源更少。
3、分庫分表的挑戰(zhàn)
可能你會(huì)說,分庫分表嘛, 也不是很難。一個(gè)庫存不下,那就把數(shù)據(jù)拆分到多個(gè)庫。一張表數(shù)據(jù)太多了,就把同一張表的數(shù)據(jù)拆分到多張。至于怎么做,也不難啊。要操作多個(gè)數(shù)據(jù)庫,那么建立多個(gè)JDBC連接就行了。要寫到多張表,修改下SQL語句就行了。
如果你也這么覺得,那么就大錯(cuò)特錯(cuò)了。分庫分表也并不是字面意義上的將數(shù)據(jù)分到多個(gè)庫或者多個(gè)表這么簡(jiǎn)單,他需要的是一系列的分布式解決方案。
因?yàn)閿?shù)據(jù)的特殊性,造成數(shù)據(jù)庫服務(wù)其實(shí)是幾乎沒有試錯(cuò)的成本的。在微服務(wù)階段,從單機(jī)架構(gòu)升級(jí)到微服務(wù)架構(gòu)是很靈活的,中間很多細(xì)節(jié)步驟都可以隨時(shí)做調(diào)整。比如對(duì)于微服務(wù)的接口限流功能,你并不需要一上來就用Sentinel這樣復(fù)雜的流控工具。一開始不考慮性能,自己進(jìn)行限流是很容易的事情。然后你可以慢慢嘗試用Guava等框架提供的一些簡(jiǎn)單的流控工具進(jìn)行零散的接口限流。直到整個(gè)應(yīng)用的負(fù)載真正上來了之后,流控的要求更高更復(fù)雜了,再開始引入Sentinel,進(jìn)行統(tǒng)一流控,這都沒有問題。這種試錯(cuò)的過程其實(shí)是你能夠真正用好一項(xiàng)技術(shù)的基礎(chǔ)。
但是對(duì)于數(shù)據(jù)庫就不一樣了。當(dāng)應(yīng)用中用來存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)庫,從一個(gè)單機(jī)的數(shù)據(jù)庫服務(wù)升級(jí)到多個(gè)數(shù)據(jù)庫組成的集群服務(wù)時(shí),需要考慮的,除了分布式的各種讓人摸不著邊際的復(fù)雜問題外,還要考慮到一個(gè)更重要的因素,數(shù)據(jù)。數(shù)據(jù)的安全性甚至比數(shù)據(jù)庫服務(wù)本身更重要!因此,如果你在一開始做分庫分表時(shí)的方案不太成熟,對(duì)數(shù)據(jù)的規(guī)劃不是很合理,那么這些問題大概率會(huì)隨著數(shù)據(jù)永遠(yuǎn)沉淀下去,成為日后對(duì)分庫分表方案進(jìn)行調(diào)整時(shí)最大的攔路虎。
所以在決定進(jìn)行分庫分表之前,一定需要提前對(duì)于所需要面對(duì)的各種問題進(jìn)行考量。如果你沒有考慮清楚數(shù)據(jù)要如何存儲(chǔ)、計(jì)算、使用,或者你對(duì)于分庫分表的各種問題都還沒有進(jìn)行過思考,那么千萬不要在真實(shí)項(xiàng)目中貿(mào)然的進(jìn)行分庫分表。
分庫分表,也稱為Sharding。Sharding表示將數(shù)據(jù)拆分到不同的數(shù)據(jù)片中。由于數(shù)據(jù)往往是一個(gè)應(yīng)用的基礎(chǔ),隨著數(shù)據(jù)從單體服務(wù)拆分到多個(gè)數(shù)據(jù)分片,應(yīng)用層面也需要面臨很多新的問題。比如:
- 主鍵避重問題
在分庫分表環(huán)境中,由于表中數(shù)據(jù)同時(shí)存在不同數(shù)據(jù)庫中,某個(gè)分區(qū)數(shù)據(jù)庫生成的ID就無法保證全局唯一。因此需要單獨(dú)設(shè)計(jì)全局主鍵,以避免跨庫主鍵重復(fù)問題。
- 數(shù)據(jù)備份問題
隨著數(shù)據(jù)庫由單機(jī)變?yōu)榧?#xff0c;整體服務(wù)的穩(wěn)定性也會(huì)隨之降低。如何保證集群在各個(gè)服務(wù)不穩(wěn)定的情況下,依然保持整體服務(wù)穩(wěn)定就是數(shù)據(jù)庫集群需要面對(duì)的重要問題。而對(duì)于數(shù)據(jù)庫,還需要對(duì)數(shù)據(jù)安全性做更多的考量。
- 數(shù)據(jù)遷移問題
當(dāng)數(shù)據(jù)庫集群需要進(jìn)行擴(kuò)縮容時(shí),集群中的數(shù)據(jù)也需要隨著服務(wù)進(jìn)行遷移。如何在不影響業(yè)務(wù)穩(wěn)定性的情況下進(jìn)行數(shù)據(jù)遷移也是數(shù)據(jù)庫集群化后需要考慮的問題。
- 分布式事務(wù)問題
原本單機(jī)數(shù)據(jù)庫有很好的事務(wù)機(jī)制能夠幫我們保證數(shù)據(jù)一致性。但是分庫分表后,由于數(shù)據(jù)分布在不同庫甚至不同服務(wù)器,不可避免會(huì)帶來分布式事務(wù)問題。
- SQL路由問題
數(shù)據(jù)被拆分到多個(gè)分散的數(shù)據(jù)庫服務(wù)當(dāng)中,每個(gè)數(shù)據(jù)庫服務(wù)只能保存一部分的數(shù)據(jù)。這時(shí),在執(zhí)行SQL語句檢索數(shù)據(jù)時(shí),如何快速定位到目標(biāo)數(shù)據(jù)所在的數(shù)據(jù)庫服務(wù),并將SQL語句轉(zhuǎn)到對(duì)應(yīng)的數(shù)據(jù)庫服務(wù)中執(zhí)行,也是提升檢索效率必須要考慮的問題。
- 跨節(jié)點(diǎn)查詢,歸并問題
跨節(jié)點(diǎn)進(jìn)行查詢時(shí),每個(gè)分散的數(shù)據(jù)庫中只能查出一部分的數(shù)據(jù),這時(shí)要對(duì)整體結(jié)果進(jìn)行歸并時(shí),就會(huì)變得非常復(fù)雜。比如常見的limit、order by等操作。
在實(shí)際項(xiàng)目中,遇到的問題還會(huì)更多。從這里可以看出,Sharding其實(shí)是一個(gè)很復(fù)雜的問題,往往很難通過項(xiàng)目定制的方式整體解決。因此,大部分情況下,都是通過第三方的服務(wù)來解決Sharding的問題。比如像TiDB、ClickHouse、Hadoop這一類的NewSQL產(chǎn)品,大部分情況下是將數(shù)據(jù)問題整體封裝到一起,從而提供Sharding方案。但是這些產(chǎn)品畢竟太重了。更靈活的方式還是使用傳統(tǒng)數(shù)據(jù)庫,通過軟件層面來解決多個(gè)數(shù)據(jù)庫之間的數(shù)據(jù)問題。這也誕生了很多的產(chǎn)品,比如早前的MyCat,還有后面我們要學(xué)習(xí)的ShardingSphere等。
另外,關(guān)于何時(shí)要開始考慮分庫分表呢?當(dāng)然是數(shù)據(jù)太大了,數(shù)據(jù)庫服務(wù)器壓力太大了就要進(jìn)行分庫分表。但是這其實(shí)是沒有一個(gè)具體的標(biāo)準(zhǔn)的,需要根據(jù)項(xiàng)目情況進(jìn)行靈活設(shè)計(jì)。業(yè)界目前唯一比較值得參考的詳細(xì)標(biāo)準(zhǔn),是阿里公開的開發(fā)手冊(cè)中提到的,建議預(yù)估三年內(nèi),單表數(shù)據(jù)超過500W,或者單表數(shù)據(jù)大小超過2G,就需要考慮分庫分表。