跟我一塊兒雲計算（5）——Shards

時間 2019-11-24

標籤一塊兒計算 shards 简体版

原文原文鏈接

什麼是sharding

Sharding的基本思想就要把一個數據庫切分紅多個部分放到不一樣的數據庫 (server)上，從而緩解單一數據庫的性能問題。不太嚴格的講，對於海量數據的數據庫，若是是由於表多而數據多，這時候適合使用垂直切分，即把關係緊密（好比同一模塊）的表切分出來放在一個server上。若是表並很少，但每張表的數據很是多，這時候適合水平切分，即把表的數據按某種規則（好比按ID 散列）切分到多個數據庫(server)上。固然，現實中更可能是這兩種狀況混雜在一塊兒，這時候須要根據實際狀況作出選擇，也可能會綜合使用垂直與水平切分，從而將原有數據庫切分紅相似矩陣同樣能夠無限擴充的數據庫(server)陣列。html

什麼是切分

數據庫切分 是一個固有的關係流程，能夠經過一些邏輯數據塊將一個表的行分爲不一樣的小組。例如，若是您正在根據時間戳對一個名爲 foo 的超大型表進行分區，2010 年 8 月以前的全部數據都將進入分區 A，而以後的數據則所有進入分區 B。分區能夠加快讀寫速度，由於它們的目標是單獨分區中的較小型數據集。前端

分區功能並不老是可用的（MySQL 直到 5.1 版本後才支持），並且其須要的商業系統的成本也讓人望而卻步。更重要的是，大部分分區實如今同一個物理機上存儲數據，因此受到硬件基礎的影響。除此以外，分區也不能鑑別硬件的可靠性或者說缺少可靠性。所以，不少智慧的人們開始尋找進行伸縮的新方法。java

切分實質上是數據庫級別的分區：它不是經過數據塊分割數據表的行，而是經過一些邏輯數據元素對數據庫自己進行分割（一般跨不一樣的計算機）。也就是說，切分不是將數據表 分割成小塊，而是將整個數據庫 分割成小塊。node

切分的一個典型示例是基於根據區域對一個存儲世界範圍客戶數據的大型數據庫進行分割：切分 A 用於存儲美國的客戶信息，切分 B 用戶存儲亞洲的客戶信息，切分 C 歐洲，等。這些切分分別處於不一樣的計算機上，且每一個切分將存儲全部相關數據，如客戶喜愛或訂購歷史。python

切分的好處（如分區同樣）在於它能夠壓縮大型數據：單獨的數據表在每一個切分中相對較小，這樣就能夠支持更快速的讀寫速度，從而提升性能。切分還能夠改善可靠性，由於即使一個切分意外失效，其餘切分仍然能夠服務數據。並且由於切分是在應用程序層面進行的，您能夠對不支持常規分區的數據庫進行切分處理。資金成本較低一樣也是一個潛在優點。mysql

垂直拆分

垂直切分的最大特色就是規則簡單，實施也更爲方便，尤爲適合各業務之間的耦合度很是低，相互影響很小，業務邏輯很是清晰的系統。在這種系統中，能夠很容易作到將不一樣業務模塊所使用的表分拆到不一樣的數據庫中。根據不一樣的表來進行拆分，對應用程序的影響也更小，拆分規則也會比較簡單清晰。git

水平拆分

水平切分於垂直切分相比，相對來講稍微複雜一些。由於要將同一個表中的不一樣數據拆分到不一樣的數據庫中，對於應用程序來講，拆分規則自己就較根據表名來拆分更爲複雜，後期的數據維護也會更爲複雜一些。github

兩種拆分組合

讓咱們從廣泛的狀況來考慮數據的切分：一方面，一個庫的全部表一般不可能由某一張表所有串聯起來，這句話暗含的意思是，水平切分幾乎都是針對一小搓一小搓（實際上就是垂直切分出來的塊）關係緊密的表進行的，而不多是針對全部表進行的。另外一方面，一些負載很是高的系統，即便僅僅只是單個表都沒法經過單臺數據庫主機來承擔其負載，這意味着單單是垂直切分也不能徹底解決問明。所以多數系統會將垂直切分和水平切分聯合使用，先對系統作垂直切分，再針對每一小搓表的狀況選擇性地作水平切分。從而將整個數據庫切分紅一個分佈式矩陣。web

hibernate shards

hibernate的shards方案：redis

這裏有幾篇文章能夠參考一下：

Hibernate Shards 數據的水平、垂直切割（一）- Hibernate測試環境

Hibernate Shards 數據的水平、垂直切割（二）- Hibernate Shards基本演示

Hibernate Shards 數據的水平、垂直切割（三）- Hibernate Shards結構

注意：Hibernate Shards是不支持跨切分查詢的。

使用hibernate shards進行拆分：

http://www.ibm.com/developerworks/cn/java/j-javadev2-11/index.html

也能夠用hibernate shards構建基於SAAS的應用，由於咱們知道在SAAS應用中，數據是須要隔離的，如今的隔離有不少種方案：

好比在IAAS創建虛擬化的徹底隔離。

在PAAS基於策略的隔離等。

下面這篇是數據隔離的一個示例：

http://www.oschina.net/question/12_12465

apache slice

Slice擴展自OpenJPA用於分佈式數據庫的一個開源項目。Slice以插件的方式附加至OpenJPA runtime，經過配置一個持久單元就可以激活多個數據庫支持。一旦配置好Slice，現有OpenJPA應用程序就可以在同一個事務中利用多個數據庫進行處理。查詢也將依賴全部數據庫並行執行，任何更新也會提交至相應的數據庫。

更確切的說slice更像是openjpa的一個插件，用來實現shards，下面看一下官方的圖

若是使用openjpa的方案能夠考慮一下。

順便附一下官方的網址：

http://people.apache.org/~ppoddar/slice/site/

dbShards

首先，這個是一個商用的產品，絕對不是一個開源的方案。

單一數據庫：

首先從配置一個網站應用開始，其由4太應用服務器及一個數據庫組成。下圖展現了一個應用的配置，數據庫配置max_connections爲1000。爲避免數據庫過載，咱們將其併發請求數設置爲800，所以設置每一個應用服務器的鏈接池爲容許最多200鏈接。設置每一個應用服務器對於入站HTTP請求最少支持200線程的處理。

拆分數據庫：

如今假設咱們採用拆分數據庫，其中有4個物理子庫（每一個專用服務器上有1個單獨的MySQL實例）。如今咱們有4個數據庫，每個的 max_connections配置爲1000。一樣，咱們要限制每一個數據庫800個併發事務。假設拆分架構的結果是在全部4個子庫上平均分佈查詢，即每臺應用服務器能夠處理4倍的併發請求，並能夠同每一個子庫創建200個鏈接。

詳細的配置等可參考官方的文檔：

http://www.dbshards.cn/articles/database-sharding-configuration/

最後再說一句，這個是商用的不是免費的。

CUBRID

CUBRID 是一個全面開源，且徹底免費的關係數據庫管理系統。CUBRID爲高效執行Web應用進行了高度優化，特別是須要處理大數據量和高併發請求的複雜商務服務。經過提供獨特的最優化特性，CUBRID能夠支持更多的併發請求，更少的響應時間。
CUBRID這個名稱，其實是兩個單詞的組合:"Cube"(立方體)和"Bride"(橋樑)。對CUBRID而言，"Bride"表明"data bridge"(數據橋)，而"Cube"表明密封盒子，能夠爲放在其中的數據提供安全。所以，CUBRID表明能夠爲機密信息提供安全保障。

從下表中能夠對比一下cubrid的shards方案與其它的shards的不一樣之處：

大多數的解決方案都基於一個特定的數據庫。他們一般的方式是使用一箇中間的代理層。也就是說每一次的SQL請求都須要通過解析。

cubrid的架構：

操做流程以下：

這是很是不錯的一個方案，能夠考慮在團隊中推廣應用。

IBM WebSphere eXtreme Scale

IBM的分區方案，更確切的說應該是一套總體的方案：

1）WebSphere eXtreme Scale 初探，第 1 部分: 瞭解 WebSphere eXtreme Scale 及其工做原理

http://www.ibm.com/developerworks/cn/websphere/techjournal/0911_kirby/0911_kirby.html

2）Websphere eXtreme Scale 的先進先出（FIFO）特性研究

http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1209_zhujf_fifo/1209_zhujf_fifo.html

3）深刻剖析 WebSphere eXtreme Scale HTTP 會話管理

http://www.ibm.com/developerworks/cn/websphere/techjournal/1301_ying/1301_ying.html

IBM® WebSphere® eXtreme Scale 是一種通用、高速的緩存解決方案，可在各類不一樣的設計中予以配置和使用。不過，您不能盲目地使用 WebSphere eXtreme Scale 提供的 API，並想固然地認爲它會減輕數據庫的工做重負，使您的應用程序更快地運行。做爲提升應用程序性能的一種策略，緩存應當被明智謹慎地應用。一樣地，您不能想固然地認爲您的應用程序能夠彈性地應對硬件故障，除非您爲此籌備了有意識的計劃。

最後仍是要說一句，東西是好東西，惋惜即不開源，也難免費。

MongoDB sharding

MongoDB 是一種流行的非關係型數據庫。做爲一種文檔型數據庫，除了有無 schema 的靈活的數據結構，支持複雜、豐富的查詢功能外，MongoDB 還自帶了至關強大的 sharding 功能。

下面是架構圖：

關於更詳細的介紹，能夠參考：

http://xiezhenye.com/2012/12/mongodb-sharding-%E6%9C%BA%E5%88%B6%E5%88%86%E6%9E%90.html

也能夠參考官方的文檔：

http://docs.mongodb.org/manual/sharding/

這對於正在使用非關係型數據庫而且正用到分表功能的團隊能夠說是一個福音。

MySQL Cluster

MySQL Cluster 是一種技術，該技術容許在無共享的系統中部署「內存中」數據庫的 Cluster 。經過無共享體系結構，系統可以使用廉價的硬件，並且對軟硬件無特殊要求。此外，因爲每一個組件有本身的內存和磁盤，不存在單點故障。

MySQL Cluster 由一組計算機構成，每臺計算機上均運行着多種進程，包括MySQL服務器，NDB Cluster 的數據節點，管理服務器，以及（可能）專門的數據訪問程序。關於 Cluster 中這些組件的關係。

若是想作mysql集羣能夠考慮使用。

Plugin for Grails

這個沒什麼可說的，基於grails的shards插件。

網站是：

http://grails.org/plugin/sharding

Redis

redis-sharding 是一個由perl寫的 Redis 的proxy，使用它，你能夠將數據分佈存儲在多個Redis實例上，而在操做數據時卻像只操做一個實例同樣。利用它至關於透明地解決了 Redis 單線程沒法有效利用多核心服務器的問題。固然，咱們更期待官方的cluster方案。

項目地址：https://github.com/kni/redis-sharding

架構：

/- Redis (node 1)
 Client 1 ---                /-- Redis (node 2)
              Redis Sharding --- Redis (node 3)
 Client 2 ---                \-- Redis (node 4)
                              \- Redis (node 5)

啓動redis-sharding，分別爲使用默認host，port與指定host，port的方式：

perl redis_sharding.pl                             --nodes=10.1.1.2:6380,10.1.1.3:6380,...
   perl redis_sharding.pl                 --port=6379 --nodes=10.1.1.2:6380,10.1.1.3:6380,...
   perl redis_sharding.pl --host=10.1.1.1 --port=6379 --nodes=10.1.1.2:6380,10.1.1.3:6380,...

redis-sharding還支持從新切分數據，但這須要暫時停掉proxy，下面是將原來的db 9的數據從新sharding到B1-B5五個實例上：

停掉redis-sharding後再執行：

perl resharding.pl --db=9 --from=A1 --nodes=B1,B2,B3,B4,B5
perl resharding.pl --db=9 --from=A2 --nodes=B1,B2,B3,B4,B5

而後再啓動新的管理B1-B5的redis-sharding實例便可：

perl redis_sharding.pl --nodes=B1,B2,B3,B4,B5

若是需求簡單能夠考慮使用。

Ruby ActiveRecord

功能和hibernate shards相似，都是基於orm的shard，若是使用ruby的朋友可使用。

ScaleBase's Data Traffic Manager

ScaleBase 的關鍵賣點是它的旗艦產品 Data Traffic Manager。其最大的特色是能夠跟客戶已有的應用協同工做，不須要客戶重寫應用。Data Traffic Manager 的做用至關於在數據庫與客戶端（能夠是 app server、BI 工具或任何數據庫客戶端）之間充當代理，其部署方式能夠是在本地或雲端。

商用產品，很少說，前景十分看好。

Solr Search Server

顧名思意：

solr提供的服務器分發。在處理搜索的能夠深刻一下。

SQLAlchemy ORM

SQLAlchemy是Python編程語言下的一款開源軟件。提供了SQL工具包及對象關係映射（ORM）工具，使用MIT許可證發行。

SQLAlchemy「採用簡單的Python語言，爲高效和高性能的數據庫訪問設計，實現了完整的企業級持久模型」。SQLAlchemy的理念是，SQL數據庫的量級和性能重要於對象集合；而對象集合的抽象又重要於表和行。所以，SQLAlchmey採用了相似於Java裏Hibernate的數據映射模型，而不是其餘ORM框架採用的Active Record模型。不過，Elixir和declarative等可選插件可讓用戶使用聲明語法。

若是你正在用python，並且想作分表的功能，能夠重點關注下。

SQL Azure

microsoft的分片方案：

對於大數據分析高度可擴展的NoSQL數據庫是很熱門的話題，可是組織能夠對傳統的關係型數據庫經過水平行分區進行橫向擴展和縱向擴展，使它們運行於多個服務器實例上，這也就是所謂的分片技術(Sharding)。 SQL Azure是定製版SQL Server 2008 R2集羣基於雲的實現，運行於微軟公司全球數據中心網絡上。SQL Azure提供了高達99.9%服務級別協議的高可用性，由三重數據複製實現，省下了爲處理運營高峯負載壓力須要在服務器硬件上的資本投資。

SQL Azure服務是在12月12日發佈的，該版本把SQL Azure數據庫的最大容量從50GB增長到了150GB，引入了稱之爲SQL Azure Federation的分片技術，隱性地下降了每個月運營成本達到45%到95%之多，具體比例依賴於數據庫大小。Federations使從新分配和劃分數據更容易了，並且提供了無需應用停機處理這些操做的路由層。

DBA和開發人員如何利用SQL Azure發揮他們的T-SQL管理技能，並可以消除按需分配數據庫服務器的常規配置和維護成本呢?須要作聯邦的數據來源於接近800萬行的 Windows Azure表特徵數據，這些數據來自於六個默認的計數器：網絡接口每秒發送的字節數和接收的字節數，每秒鐘ASP.NET應用請求數，創建的TCPv4鏈接數，內存可用字節和處理時間百分比。SQL Server 2008 R2 SP1源表(WADPerfCounters)有一個組合的集羣主鍵，由PartitionKey和RowKey值組成。SQL Azure目標表作聯邦後增長了CounterID值，從1到6，表明了六個時間計數器。這些表給他們的主鍵增長了CounterID，由於必須包含聯邦分發主鍵值。

若是你正在跟微軟合做或者考慮使用微軟的方案，能夠選用。

IBM Informix

IBM的數據庫：

IBM Informix 關係數據庫管理系統爲全部規模的企業提供了聯機事務處理和決策支持應用，適用於Microsoft Windows、Linux、UNIX 和 Apple Mac OS X 平臺。

若是使用這個數據庫可使用它的shard功能。

Gizzard

Twitter已經從以往的數據存儲開發經驗中提出一個名爲Gizzard的Scala框架，讓用戶能夠更方便地建立自定義容錯、分佈式數據庫。 Twitter給出了一個名爲「Rowz」的示例，方便用戶上手。Twitter還公佈了Gizzard的完整代碼。有了Gizzard，初創公司和小公司就能夠更好更快地處理大量數據，從而利用更少的資源知足用戶需求。

它更像是一個數據shards的方案之一，能夠不使用關係型數據庫。

Spock Proxy

這也是在實際需求中產生的一個開源項目。Spock（http://www.spock.com/）是一我的員查找的 Web 2.0 網站。經過對本身的單一 DB 進行有效 Sharding化而產生了Spock Proxy(http://spockproxy.sourceforge.net/ ) 項目，Spock Proxy 算得上 MySQL Proxy 的一個分支，提供基於範圍的 Sharding 機制。Spock 是基於 Rails 的，因此Spock Proxy 也是基於 Rails 構建，關注 RoR 的朋友不該錯過這個項目。

架構示意圖：

HiveDB

上面介紹了 RoR 的實現，HiveDB (http://www.hivedb.org/)則是基於Java 的實現，另外，稍有不一樣的是，這個項目背後有商業公司支持。

架構示意圖：

PL/Proxy

前面幾個都是針對 MySQL 的 Sharding 方案，PL/Proxy 則是針對 PostgreSQL 的，設計思想相似 Teradata 的 Hash 機制，數據存儲對客戶端是透明的，客戶請求發送到 PL/Proxy 後，由這裏分佈式存儲過程調用，統一分發。 PL/Proxy 的設計初衷就是在這一層充當」數據總線」的職責，因此，當數據吞吐量支撐不住的時候，只須要增長更多的 PL/Proxy 服務器便可。大名鼎鼎的 Skype 用的就是 PL/Proxy 的解決方案。

Pyshards

http://code.google.com/p/pyshards/wiki/Pyshards
這是個基於 Python的解決方案。該工具的設計目標還有個 Re-balancing 在裏面，這卻是個比較激進的想法。目前只支持 MySQL 數據庫。

Amoeba

Amoeba是一個以MySQL爲底層數據存儲，並對應用提供MySQL協議接口的proxy。它集中地響應應用的請求，依據用戶事先設置的規則，將SQL請求發送到特定的數據庫上執行。基於此能夠實現負載均衡、讀寫分離、高可用性等需求。與MySQL官方的MySQL Proxy相比，做者強調的是amoeba配置的方便（基於XML的配置文件，用SQLJEP語法書寫規則，比基於lua腳本的MySQL Proxy簡單）。

Amoeba至關於一個SQL請求的路由器，目的是爲負載均衡、讀寫分離、高可用性提供機制，而不是徹底實現它們。用戶須要結合使用MySQL的 Replication等機制來實現副本同步等功能。amoeba對底層數據庫鏈接管理和路由實現也採用了可插撥的機制，第三方能夠開發更高級的策略類來替代做者的實現。這個程序整體上比較符合KISS原則的思想。

主要解決如下問題：
a). 數據切分後複雜數據源整合
b). 提供數據切分規則並下降數據切分規則給數據庫帶來的影響
c). 下降數據庫與客戶端鏈接
d). 讀寫分離路由
Amoeba For MySQL是專門針對MySQL數據庫的方案，架構示意圖：

Amoeba For Aiadin是個更通用的方案，他前端接收MySQL協議的請求，後端可使用MySQL、Oracle、PostGreSql等其餘數據源，這些對應用程序是透明的。架構示意圖：

altas

Atlas是由奇虎360公司Web平臺部基礎架構組開發維護的一個基於MySQL協議的數據中間層項目。它在MySQL官方推出的MySQL- Proxy 0.8.2版本的基礎上，修改了大量bug，添加了不少功能特性。目前該項目在360公司內部獲得了普遍應用，3/4以上的MySQL業務已經接入了 Atlas平臺，天天承載的讀寫請求數達20億條以上。
主要功能特性：
1. 自動讀寫分離，對應用透明
2. 自動分表
3. IP過濾，包括指定具體IP和網段IP
4. SQL語句黑白名單
5. 字符集和默認數據庫的自動修正
6. 可強制讀主庫，避免從庫的同步延遲
7. 主庫宕機的狀況下讀操做不受影響
8. 在掛接LVS的狀況下可平滑重啓，應用不感知
9. 自動檢測DB狀態，故障或鏈接不上的DB自動摘除，再也不導入請求，在故障或網絡恢復後自動從新導入請求
10. 可在線手動將某臺DB設置爲上線或下線狀態
11. 可在線手動增長或減小一臺DB
12. 從庫間加權的負載均衡

官方網址：

https://github.com/Qihoo360/Atlas

剛開源出來不久，文檔較少，不過能夠嘗試使用，畢竟中國本身的開源框架嗎。