亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: MySQL版《一周一議》之mysql sharding方案分享（積分已轉(zhuǎn)賬-2012-12-19） [打印本頁]

作者: chinafenghao 時間: 2012-12-04 10:03
標題: MySQL版《一周一議》之mysql sharding方案分享（積分已轉(zhuǎn)賬-2012-12-19）
20積分已轉(zhuǎn)賬，請注意查收！

上周的話題比較輕松,主要討論公司及DBA的人數(shù)配比有關(guān)系,一般看來DBA在研發(fā)團隊的配比5%是比較合適的。
現(xiàn)在隆重宣布上周獲得《鋒利的SQL》的用戶是：ruochen
其他參與討論的用戶到將至少獲得20積分,積分是需要管理員手工加，加上后會發(fā)站內(nèi)信的。

本周的話題是偏技術(shù)方面的。
大家都知道m(xù)ysql是一個輕量級數(shù)據(jù)庫,主流的INNODB引擎使用B+樹和hash索引,hash索引是自適應的。由于INNODB是索引聚集表，如果當一個表的數(shù)據(jù)量達到上E，或者數(shù)據(jù)量達到幾十個G的時候，性能就會下降的比較厲害。

針對這種情況,比較主流的一種處理方法就是Sharding.關(guān)于sharding更多的信息，推薦兩篇博文給大家.
http://dbanotes.net/database/database_sharding.html 開源數(shù)據(jù)庫Sharding技術(shù)
http://www.dedecms.com/knowledge ... 2012/0820/9172.html mysqlshareding可擴展設(shè)計

今天我們的話題就是mysql sharding方案分享。

1、分享你經(jīng)歷和處理過的mysql sharding方案,包括業(yè)務(wù)場景,架構(gòu),使用的軟件,實施中的難點。
活動獎勵:
1、每周會評選一位最活躍的用戶，有一本mysql相關(guān)的書籍送出,本周送出的書籍是《Cassandra實戰(zhàn)指南》。
2、由于是話題討論，所以每位參加者都能獲得適當?shù)姆e分獎勵。最低20分，最高不限,^_^想要賺分的朋友也可以來湊熱鬧喲。

作者: cenalulu 時間: 2012-12-04 10:25
本帖最后由 cenalulu 于 2012-12-07 11:39 編輯

先說說sharding的好處：
1. 表查詢效率提升
2. 表運維代價降低
3. 服務(wù)器擴容便捷

如果單純?yōu)榱藢崿F(xiàn)【1】其實sharding的可操作性還不如堆slave來的直接。
一般迫不得已sharding的情況主要有以下集中：
1. 單表數(shù)據(jù)庫超大，已經(jīng)超過服務(wù)器硬盤容量上限的1/2 （插槽全滿）
2. 業(yè)務(wù)增長太快，每天疲于應付服務(wù)器擴容。
3. 大表更新需求很頻繁，DDL的操作時間已經(jīng)超過可接受范圍

再說說sharding必須注意的：
1. sharding key一定要選的好，分布也要考慮周到。否則數(shù)據(jù)分布不均勻，或者add node導致大數(shù)據(jù)量漂移就是悲劇。
2. sharding不代表 availablity，可用性也要做好。一般雙主綁在一起作為一個node比較靠譜。當然用dynamo的思路去做更好。

作者: huzi1986 時間: 2012-12-04 13:20
我來說一下吧

MySQL sharding 主要分為兩種，分別為水平和垂直

一、業(yè)務(wù)場景
1、MMORPG網(wǎng)絡(luò)游戲日志庫：由于國家文化部門審計需要，需保留3個月的日志數(shù)據(jù)。過期數(shù)據(jù)可刪除，采用的是程序按天自動分表，程序自動刪除3個月之前的分表。這種好處就是可以有效節(jié)約日志數(shù)據(jù)庫磁盤空間。查詢某一天的玩家行為分析非�？�，基本上不會用到同時查詢多天的某個角色日志的情況

2、網(wǎng)頁游戲平臺數(shù)據(jù)庫： MERGE引擎：通過 MERGE引擎可以把user_1 到user_n等幾十個表連接起來進行匯總查詢，程序一般通過一定的算法對 user_1 user_n進行DML操作
      1、觸發(fā)器：通過相關(guān)算法對user表分拆為user_1 user_n表，在user_1 user_n表的dml操作前，觸發(fā) 器會對 user表進行變更到一張總表，便于后臺進行數(shù)據(jù)分析。
      2、CRC32取模：通過CRC32算法取模對 user_1 user_n表，每次操作會進行兩次（insert,update,delete)同時對 user_1 user_n  和 user_total表進行操作，user_total是匯總表。
   3、MySQL 分區(qū)表：zabbix監(jiān)控平臺 history 表和trends等相關(guān)表。由于history 表比較大，數(shù)據(jù)保留一個月，采用存儲過程按天分區(qū)，腳本定期刪除一定時間前的分區(qū)，有效保證數(shù)據(jù)庫數(shù)據(jù)不被擴漲大快。trends表采用按月分區(qū) 。

作者: huzi1986 時間: 2012-12-04 13:26
當然象大公司 sharding后都可能會有中間層。中小公司一般都可能采取水平或者垂直分表方式

至于架構(gòu)方面

目前我還主要用的是 Master-Master、Master-Slave-Slave

其它還有 MMM ,MHA ,MM+KEEPALIVED等高可用。目前公司都還達不到這個要求，所以，還是主要停留單機和 MS MM這種常見的架構(gòu)

作者: kerlion 時間: 2012-12-05 10:38
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: lloydm 時間: 2012-12-05 23:15
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: xike2002 時間: 2012-12-06 11:39
這個話題很好，大家可以好好討論一下。

作者: xike2002 時間: 2012-12-06 11:55
下面和大家聊一聊mysql sharding，歡迎大家的建議和意見，大家一起學習！

一.背景
　　我們知道，當數(shù)據(jù)庫中的數(shù)據(jù)量越來越大時，不論是讀還是寫，壓力都會變得越來越大。采用MySQL Replication多master多slave方案，在上層做負載均衡，雖然能夠一定程度上緩解壓力。但是當一張表中的數(shù)據(jù)變得非常龐大時，壓力還是非常大的。試想，如果一張表中的數(shù)據(jù)量達到了千萬甚至上億級別的時候，不管是建索引，優(yōu)化緩存等，都會面臨巨大的性能壓力。
二.定義
　　數(shù)據(jù)sharding，也稱作數(shù)據(jù)切分，或分區(qū)。是指通過某種條件，把同一個數(shù)據(jù)庫中的數(shù)據(jù)分散到多個數(shù)據(jù)庫或多臺機器上，以減小單臺機器壓力。
三.分類
　　數(shù)據(jù)分區(qū)根據(jù)切分規(guī)則，可以分為兩類：
　　(1)垂直分區(qū)：以表為單位，把不同的表分散到不同的數(shù)據(jù)庫或主機上。特點是規(guī)則簡單，實施方便，適合業(yè)務(wù)之間耦合度低的系統(tǒng)。
　　(2)水平分區(qū)：以行為單位，將同一個表中的數(shù)據(jù)按照某種條件拆分到不同的數(shù)據(jù)庫或主機上。特點是相對復雜，適合單表巨大的系統(tǒng)。
　　在實際情況中，有的時候把垂直分區(qū)和水平分區(qū)結(jié)合使用。
四.注意事項
　　下面我們所說的分區(qū)，主要是指水平分區(qū)。
　　(1)在實施分區(qū)前，我們可以查看所安裝版本的mysql是否支持分區(qū)：

　mysql> show variables like "%partition%";

　　如果支持則會顯示：
      +-------------------+-------+
      | Variable_name    | Value |
      +-------------------+-------+
      | have_partitioning | YES |
      +-------------------+-------+
　　(2)分區(qū)適用于一個表的所有數(shù)據(jù)和索引;不能只對數(shù)據(jù)分區(qū)而不對索引分區(qū)，反之亦然，同時也不能只對表的一部分進行分區(qū)。
　　(3)分區(qū)類型:
　　RANGE 分區(qū)：基于屬于一個給定連續(xù)區(qū)間的列值，把多行分配給分區(qū)。
　　LIST 分區(qū)：類似于按RANGE分區(qū)，區(qū)別在于LIST分區(qū)是基于列值匹配一個離散值集合中的某個值來進行選擇。
　　HASH分區(qū)：基于用戶定義的表達式的返回值來進行選擇的分區(qū)，該表達式使用將要插入到表中的這些行的列值進行計算。
　　KEY 分區(qū)：類似于按HASH分區(qū)，區(qū)別在于KEY分區(qū)只支持計算一列或多列，且MySQL 服務(wù)器提供其自身的哈希函數(shù)。必須有一列或多列包含整數(shù)值。
　　無論使用何種類型的分區(qū)，分區(qū)總是在創(chuàng)建時就自動的順序編號，且從0開始記錄。當有一新行插入到一個分區(qū)表中時，就是使用這些分區(qū)編號來識別正確的分區(qū)。
　　(4) MySQL提供了許多修改分區(qū)表的方式。添加、刪除、重新定義、合并或拆分已經(jīng)存在的分區(qū)是可能的。所有這些操作都可以通過使用ALTER TABLE 命令的分區(qū)擴展來實現(xiàn).
　　(5) 可以對已經(jīng)存在的表進行分區(qū)，直接使用alter table命令即可。

作者: laputa73 時間: 2012-12-06 16:09
關(guān)注。
云時代，數(shù)據(jù)庫的分片還是很必要的。
先百度了一下什么sharding...汗
http://eddysheng.iteye.com/blog/461393
mysql的分區(qū)表，怎么拆分到不同的數(shù)據(jù)庫或者主機上？
拆分以后，還能夠用普通的查詢嗎？

sharding最主要的問題還是跨片的查詢，這個有什么好的解決方案?

作者: kellyseeme123 時間: 2012-12-06 16:50
mysql沒用過，不過oracle里面也有這個相同的東西
關(guān)注下～

作者: ylky_2000 時間: 2012-12-07 10:39
數(shù)據(jù)庫真不懂，除了寫幾個selct語句 from where之外，其他只有概念了。
圍觀中，請教一個問題吧，mysql中如何跟蹤mysql語句的執(zhí)行呢?類似sql server的事件探測器。

作者: chinafenghao 時間: 2012-12-07 11:36
@ylky_2000
你google下 explain profiling的用法。

作者: cenalulu 時間: 2012-12-07 11:40
2樓更新了討論內(nèi)容～大家拍磚哈

作者: ylky_2000 時間: 2012-12-07 11:43
謝謝。提供信息。

chinafenghao 發(fā)表于 2012-12-07 11:36
@ylky_2000
你google下 explain profiling的用法。

作者: chinafenghao 時間: 2012-12-07 13:22
@cenalulu
贊同。
不過我覺得sharding對數(shù)據(jù)更新能力提升也是很關(guān)鍵的。

作者: cenalulu 時間: 2012-12-07 14:34
回復 15# chinafenghao

哦，對！當傳統(tǒng)m-s架構(gòu)中的m成為性能瓶頸的時候，也是sharding接入的最好時機

作者: pandorabag 時間: 2012-12-07 16:43

huzi1986 發(fā)表于 2012-12-04 13:26
當然象大公司 sharding后都可能會有中間層。中小公司一般都可能采取水平或者垂直分表方式

至于架構(gòu) ...

MM 你采用什么方式避免的雙主自增id問題

作者: 唯吾顧家三少 時間: 2012-12-07 18:13
新人留爪，看到好多很好的回復啊，感謝大家的無私分享。

謝謝樓主真么好的活動了。謝謝大家無私的分享經(jīng)驗。

作者: pitonas 時間: 2012-12-08 14:29
這個話題很好

作者: je50 時間: 2012-12-08 18:15
mysql沒用過

作者: iask 時間: 2012-12-09 13:21
回復 17# pandorabag

M1:
auto_increment_increment = 2
auto_increment_increment = 1

M2:
auto_increment_increment = 2
auto_increment_increment = 2

作者: G8bao7 時間: 2012-12-09 19:51
謝謝lz和同學們的分享，支持一下！

鑒于自己目前公司業(yè)務(wù)數(shù)據(jù)量比較小，雖然也進行了簡單sharding(ms)，但由于數(shù)據(jù)量遠不夠形成壓力，希望有同學能分享下實際業(yè)務(wù)sharding碰到的問題

作者: bellszhu 時間: 2012-12-09 21:56
不太清楚sharding的概念。。。
sharding和散表的區(qū)別？？
因為我只散過表

作者: chinafenghao 時間: 2012-12-10 10:29
回復 23# bellszhu

參見一樓帖子的文章鏈接。

作者: huzi1986 時間: 2012-12-10 15:13
回復 17# pandorabag

目前所有使用雙主的架構(gòu)中，一般都使用 HA+MM，只有一個實例同時提供寫功能。

作者: frogoscar 時間: 2012-12-10 20:39
學習了，看了網(wǎng)上幾篇東西才知道 sharding這個概念，落后了啊。之前只是用過數(shù)據(jù)庫。。。。。。。

作者: fanzhilin515 時間: 2012-12-11 02:51
新手，混點分用用。
mysql不是很懂，mark下

作者: zhangshengdong 時間: 2012-12-11 12:44
現(xiàn)在是越來越懶了，我把個人認為的mysql sharding寫一下。

1.Master(W/R)    單實例讀寫master服務(wù)器的時代
2.Master (W) + Slaves (R) 下一步，慢慢地就發(fā)展到了Mater和Slave的時代，因為單實例無法承載應用的所有請求。所以，把所有的write queries(INSERT/UPDATE/DELETE)
  給予master，把所有或者近乎所有的 read queries給予slave。
3.Vertical Partitioning （垂直拆分）

*繼續(xù)往后發(fā)展之后，可能不只是讀請求超過負載，就連寫請求也會超過負載。
*當出現(xiàn)write-heavy applications時候，我們該怎么辦？
*使用Vertical Partitioning,把一些重業(yè)務(wù)分離出來（按庫分離或者按表分離）。分別單獨放在一個服務(wù)器，分擔讀寫分離的請求。分散Top Master的寫請求

基于上述的架構(gòu)，會碰到的瓶頸：
（1):become harder and harder
  (2): Lose some JOIN-functionality
  (3):  if table grew so rapidly ，so
the performance of the host  wasn’t guranteed any more。
怎么辦？
加更多的salve？
買更貴的服務(wù)器？
就算你怎么加，它都會hit limit。

4.當上述又得不到解決的時候，horizontal partitioning到來了。

*前面討論的瓶頸，以及后時代的web數(shù)據(jù)管理�；谏鲜龅睦碚摻鉀Q。而這個早在1996年多人大型游戲online（MMO (Massive Multiplayer Online) Games world）就已經(jīng)開始積極使用。

基于上圖描述，根據(jù)上述的算法，針對一張photos表的分割，根據(jù)"%10”的算法，連接10臺服務(wù)器的哪一臺進行處理。（其實是有圖片的，就是一個表根據(jù)"%10"的方法，分布到不同的服務(wù)器中），這個要從程序方面調(diào)用來解決了。

圖我就不貼了，如果有興趣的，我可以把ppt到時候貼出來。

作者: zhangshengdong 時間: 2012-12-11 12:51
多半做sharding都是用replication來做。拆庫。拆表的話，應該跟應用層相關(guān)了。我個人認為的。

作者: visician 時間: 2012-12-11 19:04
好話題，關(guān)注

作者: fengfeng919 時間: 2012-12-11 21:32
我做準備找方法來做這個事情，前兩天還發(fā)了一個求幫助的帖子！還請版主頂一下我這個需求，有經(jīng)驗的老師給點建議。

我目前的情況是多個數(shù)據(jù)庫，所有表都使用innodb引擎共享表空間模式，其中有一張表目前已經(jīng)多大于3千萬條數(shù)據(jù)了，現(xiàn)在老大提出的直接辦法是分表，當然也就是水平分表了，由于前端我們要根據(jù)ID去寫和讀，所以希望分表后能夠按照順序?qū)懕�，例如第一張�?00萬條數(shù)據(jù)，然后從301就開始到第二張表去寫，怎么樣能夠自動的去實現(xiàn)呢，默認的merge表好像是隨機的而且不保證多張表的ID唯一。
我目前自己的想法是我手動建立好10張表，程序每次寫完數(shù)據(jù)能夠把最后一個ID覆蓋寫到一張臨時表，然后我系統(tǒng)里腳步實時去查詢這個臨時表ID，如果大于300就創(chuàng)建第二張表，以此類推，不知道這樣是否可行。

作者: mickey_51 時間: 2012-12-11 21:52

很好我也頂一頂

作者: 靈魂守衛(wèi)者 時間: 2012-12-14 11:27
不錯，支持一下

作者: fengfeng919 時間: 2012-12-14 12:54
版主們，給點建議呀？？？

作者: chinafenghao 時間: 2012-12-17 09:28
@fengfeng919
你這種分區(qū)方法基本不太可行哈。用腳本控制數(shù)據(jù)庫，很不靠譜。
你要描述你的數(shù)據(jù)庫瓶頸,大家根據(jù)你的瓶頸來指定方案，不一定要你老大說那種。他說的水平分表方式基本不可能在不修改業(yè)務(wù)代碼的前提下完成。

歡迎光臨 Chinaunix (http://72891.cn/)