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

Chinaunix

標(biāo)題: MySQL Cluster性能測(cè)試結(jié)果以及疑問 [打印本頁(yè)]

作者: 飛哥林 時(shí)間: 2008-05-20 14:54
標(biāo)題: MySQL Cluster性能測(cè)試結(jié)果以及疑問
我在redhat as5 4G mem環(huán)境里面搭了一套cluster環(huán)境。
4臺(tái)Data node， 4臺(tái)MySQL node，1臺(tái)mgm node，2臺(tái)LVS前置做load balance

測(cè)試結(jié)果是：
insert操作和標(biāo)準(zhǔn)mysql比較下降差不多80%
select操作和標(biāo)準(zhǔn)mysql比較下降差不多50%
LVS對(duì)性能影響不大，但能起到負(fù)荷分擔(dān)作用

我用的是5.0里面帶的cluster，全靠?jī)?nèi)存，不寫磁盤的。說明一下，我覺得性能瓶頸還沒到網(wǎng)絡(luò)帶寬這，我仔細(xì)算了一下，client到mysql api節(jié)點(diǎn)的帶寬占用很低的，除非是mysql node和data node之間通信的帶寬是瓶頸。

有個(gè)疑問：
為什么4個(gè)data node里面有一個(gè)是master？沒有找到文檔描述，然道是只有master能寫，所有能讀的模式？
另外，壇子里面有沒有人把cluster用到生產(chǎn)上的？能否討論下，我正考慮是否將我們的數(shù)據(jù)遷移到cluster上來。

看到mysql今年年會(huì)上提到，未來會(huì)考慮memcached和mysql的結(jié)合，有沒有誰(shuí)實(shí)驗(yàn)過？感覺上和新浪提得memcachedb以及dbcached差不多的概念。

添加對(duì)CGE測(cè)試的一些東東:

[root@localhost ~]# ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> show
Connected to Management Server at: 192.168.1.230:1186
Cluster Configuration
---------------------
[ndbd(NDB)]    4 node(s)
id=2 @192.168.1.230  (mysql-5.1.24 ndb-6.3.14, Nodegroup: 0, Master)
id=3 @192.168.1.232  (mysql-5.1.24 ndb-6.3.14, Nodegroup: 0)
id=4 @192.168.1.234  (mysql-5.1.24 ndb-6.3.14, Nodegroup: 1)
id=5 @192.168.1.236  (mysql-5.1.24 ndb-6.3.14, Nodegroup: 1)

[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.1.230  (mysql-5.1.24 ndb-6.3.14)

[mysqld(API)] 4 node(s)
id=6 @192.168.1.230  (mysql-5.1.24 ndb-6.3.14)
id=7 @192.168.1.232  (mysql-5.1.24 ndb-6.3.14)
id=8 @192.168.1.234  (mysql-5.1.24 ndb-6.3.14)
id=9 @192.168.1.236  (mysql-5.1.24 ndb-6.3.14)

ndb_mgm>

昨天簡(jiǎn)單的測(cè)試了一下CGE版本，沒有加前置LVS的情況下，insert性能沒有提高，但是select性能有提高，大概提高有20-25%左右。說明一下，在還沒打開非index列寫磁盤的功能情況下測(cè)試的
300w條記錄，單條記錄1K，查詢測(cè)試結(jié)果，沒有LVS的情況下，性能差不多是MySQL Server的70%，LVS前置帶2個(gè)MySQL節(jié)點(diǎn)，基本上等于MySQL Server，LVS帶4個(gè)mysql節(jié)點(diǎn)，性能比MySQL Server好，并發(fā)連接數(shù)越多，越明顯

后來試了一下ndbapi，讀寫速度奇快，比同樣環(huán)境下的mysql server還要好不少，當(dāng)然是全mem的情況下。大部分row都寫磁盤的情況下，也和mysqlserver差不多

[ 本帖最后由飛哥林于 2008-6-4 17:33 編輯 ]

作者: ruochen 時(shí)間: 2008-05-20 14:58
LZ是高手了

已經(jīng)玩了這么多節(jié)點(diǎn)的MySQL

作者: huifeideluotuo 時(shí)間: 2008-05-20 15:11
mysql集群是比較吃內(nèi)存的了，最好內(nèi)存在8G以上。。。。。

前段時(shí)間我們也準(zhǔn)備把mysql做成集群的架構(gòu)，但是后來查詢資料，和一些有經(jīng)驗(yàn)的管理員交流下，個(gè)人認(rèn)為，mysql集群適合小負(fù)載的查詢，不太適合高負(fù)載下的應(yīng)用。

還請(qǐng)高手指點(diǎn)。

作者: 飛哥林 時(shí)間: 2008-05-20 15:20
我也覺得現(xiàn)在的cluster猶如雞肋。

看官方說CGE版本性能有了很大提高，不知道有沒有高手已經(jīng)測(cè)試過了。

作者: 飛哥林 時(shí)間: 2008-05-20 15:20
標(biāo)題: 回復(fù) #2 ruochen 的帖子
哪里啊，剛剛注冊(cè)的ID，不懂得東西太多了。

作者: yueliangdao0608 時(shí)間: 2008-05-20 15:39
CLUSTER 里面的NODE全部都是MASTER

作者: yueliangdao0608 時(shí)間: 2008-05-20 15:40
LZ有沒有試過在光纖下的插入和查詢性能？

作者: 飛哥林 時(shí)間: 2008-05-20 16:33
標(biāo)題: 回復(fù) #6 yueliangdao0608 的帖子
具體是不是master，我找不到有官方文檔來支持。
但是我在ndb_mgm里面show出來結(jié)果如下
其中id=3的后面顯示是master其他的沒有啊

ndb_mgm> show
Cluster Configuration
---------------------
[ndbd(NDB)]    4 node(s)
id=2 @192.168.1.221  (Version: 5.0.51, Nodegroup: 0)
id=3 @192.168.1.223  (Version: 5.0.51, Nodegroup: 0, Master)
id=4 @192.168.1.225  (Version: 5.0.51, Nodegroup: 1)
id=5 @192.168.1.227  (Version: 5.0.51, Nodegroup: 1)

[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.1.207  (Version: 5.0.51)

我這沒有光纖的環(huán)境啊，試不了。

[ 本帖最后由飛哥林于 2008-5-20 16:35 編輯 ]

作者: showsa 時(shí)間: 2008-05-20 16:54
lz應(yīng)該測(cè)試高并發(fā)的情況
因?yàn)閏luster網(wǎng)絡(luò)特性，具有高延時(shí)，如果單線程測(cè)試的話，性能肯定很差
并且在高并發(fā)的情況下，可以設(shè)置多結(jié)果集綁定返回，從而提高吞吐量

作者: showsa 時(shí)間: 2008-05-20 17:02
目前網(wǎng)上很多所謂mysql cluster的測(cè)試，其實(shí)基本上只是個(gè)搭建起來能夠運(yùn)行而已
很多人還不理解mysql cluster構(gòu)架的初衷
當(dāng)你們遇到大數(shù)據(jù)量需要分表分庫(kù)的時(shí)候再來審視mysql cluster的構(gòu)架，你會(huì)發(fā)現(xiàn)是多么的親切
mysql cluster當(dāng)前之所以沒有大量被采用，主要在于單線程的延時(shí)

你們說的mysql cluster只適合小負(fù)載的查詢是不科學(xué)的，看看官方的測(cè)試，那是100,000 TPM

作者: 飛哥林 時(shí)間: 2008-05-20 17:40
標(biāo)題: 回復(fù) #9 showsa 的帖子
呵呵，高手來了

我沒有把自己的測(cè)試說清楚，我做過不同數(shù)量的線程的測(cè)試。
舉個(gè)例子：
我有1個(gè)線程插入10000條記錄，標(biāo)準(zhǔn)MySQL用時(shí)7323ms，而cluster用時(shí)37505ms
10個(gè)線程插入10000條記錄，標(biāo)準(zhǔn)MySQL用時(shí)898ms，而cluster用時(shí)5100ms

從這個(gè)測(cè)試結(jié)果來看，同樣的并發(fā)操作，cluster耗時(shí)也是mysql的差不多5倍，是不是可以理解為單單是高并發(fā)只能增加系統(tǒng)的連接數(shù)，并不能提高多少性能，當(dāng)然如果多結(jié)果集的方案的話，也許有用，沒試過。

另外，我覺得cluster的方案本身確實(shí)很不錯(cuò)，但是實(shí)在是很少資料描述其實(shí)現(xiàn)方式，看源代碼的話，對(duì)我而言難度太大。不知您是否有些資料能共享？不勝感激。再，能幫忙解釋一下master node的作用么？

作者: talen-t 時(shí)間: 2008-05-20 19:36

原帖由 showsa 于 2008-5-20 17:02 發(fā)表
目前網(wǎng)上很多所謂mysql cluster的測(cè)試，其實(shí)基本上只是個(gè)搭建起來能夠運(yùn)行而已
很多人還不理解mysql cluster構(gòu)架的初衷
當(dāng)你們遇到大數(shù)據(jù)量需要分表分庫(kù)的時(shí)候再來審視mysql cluster的構(gòu)架，你會(huì)發(fā)現(xiàn)是多么的 ...

可否帖一下你目前cluster下的性能參數(shù),比如用了幾個(gè)節(jié)點(diǎn),每個(gè)節(jié)點(diǎn)的每秒讀寫比,cpu,load,等

作者: showsa 時(shí)間: 2008-05-20 19:52

原帖由 飛哥林 于 2008-5-20 17:40 發(fā)表
呵呵，高手來了

我沒有把自己的測(cè)試說清楚，我做過不同數(shù)量的線程的測(cè)試。
舉個(gè)例子：
我有1個(gè)線程插入10000條記錄，標(biāo)準(zhǔn)MySQL用時(shí)7323ms，而cluster用時(shí)37505ms
10個(gè)線程插入10000條記錄，標(biāo)準(zhǔn)MySQL用時(shí) ...

master data node 主要是負(fù)責(zé)處理 ndb 內(nèi)部 protocol 相關(guān)方面的工作，還有meta data ，比如 creating tables

作者: showsa 時(shí)間: 2008-05-20 20:01
Num. of Messages = 2 × Num. of Fragments × (NoOfReplicas + 1)

如果4個(gè)ndbd節(jié)點(diǎn)，NoOfReplicas=2，那么就有24條消息，每條0.5ms的話，那么這里網(wǎng)絡(luò)延時(shí)就達(dá)到了12ms之多
這就是為什么mysql cluster表面上看起來那么不堪的原因

但是隨著并發(fā)的增加，這些message是可以batch的，這樣就可以大大提高整個(gè)系統(tǒng)的吞吐量

作者: showsa 時(shí)間: 2008-05-20 20:42
飛哥林在頂樓提到memcached，現(xiàn)在所有的web2.0網(wǎng)站，基本上100%使用了memcached
mysql 2008 會(huì)議上提高的是UDF 的memcached擴(kuò)展，可以利用trigger更新數(shù)據(jù)，實(shí)現(xiàn)push的功能

不過這個(gè)跟朋友們討論過，采用trigger更新還是由app實(shí)現(xiàn)大家看法各不相同，都是合理的

作者: yueliangdao0608 時(shí)間: 2008-05-21 09:00
其實(shí)你直接用APACHE 的 AB就可以簡(jiǎn)單測(cè)試了。

作者: sunnyfun 時(shí)間: 2008-05-21 10:24

原帖由 飛哥林 于 2008-5-20 17:40 發(fā)表
呵呵，高手來了

我沒有把自己的測(cè)試說清楚，我做過不同數(shù)量的線程的測(cè)試。
舉個(gè)例子：
我有1個(gè)線程插入10000條記錄，標(biāo)準(zhǔn)MySQL用時(shí)7323ms，而cluster用時(shí)37505ms
10個(gè)線程插入10000條記錄，標(biāo)準(zhǔn)MySQL用時(shí) ...

這種測(cè)法瓶頸是在網(wǎng)絡(luò)延遲啦，試試10000個(gè)線程各插入1條記錄

作者: yueliangdao0608 時(shí)間: 2008-05-21 10:35

原帖由 sunnyfun 于 2008-5-21 10:24 發(fā)表

這種測(cè)法瓶頸是在網(wǎng)絡(luò)延遲啦，試試10000個(gè)線程各插入1條記錄

SUNNYFUN 你在深嘛？

作者: sunnyfun 時(shí)間: 2008-05-21 13:05

原帖由 yueliangdao0608 于 2008-5-21 10:35 發(fā)表

SUNNYFUN 你在深嘛？

貌似離深有點(diǎn)距離

作者: yueliangdao0608 時(shí)間: 2008-05-21 13:20

原帖由 sunnyfun 于 2008-5-21 13:05 發(fā)表

貌似離深有點(diǎn)距離

看來深圳的兄弟太少了。

作者: 飛哥林 時(shí)間: 2008-05-21 14:04

原帖由 yueliangdao0608 于 2008-5-21 13:20 發(fā)表

看來深圳的兄弟太少了。

不少吧，我也在深圳的說

作者: 飛哥林 時(shí)間: 2008-05-21 14:07

原帖由 sunnyfun 于 2008-5-21 10:24 發(fā)表

這種測(cè)法瓶頸是在網(wǎng)絡(luò)延遲啦，試試10000個(gè)線程各插入1條記錄

剛剛把CGE的版本的cluster搞起來，這次是4G mem的至強(qiáng)4core機(jī)器，一會(huì)按照你的方式測(cè)試一下看看結(jié)果。

作者: showsa 時(shí)間: 2008-05-21 14:09
在并發(fā)高的情況下，別忘記設(shè)置相關(guān)參數(shù) 可以batch多條message

作者: yueliangdao0608 時(shí)間: 2008-05-21 14:32

原帖由 huifeideluotuo 于 2008-5-20 15:11 發(fā)表
mysql集群是比較吃內(nèi)存的了，最好內(nèi)存在8G以上。。。。。

前段時(shí)間我們也準(zhǔn)備把mysql做成集群的架構(gòu)，但是后來查詢資料，和一些有經(jīng)驗(yàn)的管理員交流下，個(gè)人認(rèn)為，mysql集群適合小負(fù)載的查詢，不太適合高負(fù)載 ...

小負(fù)載的用單機(jī)就搞定了。

何必怎么費(fèi)神。

作者: yueliangdao0608 時(shí)間: 2008-05-21 14:34
再討論熱烈一點(diǎn)就加精了。

作者: 飛哥林 時(shí)間: 2008-05-21 14:55

原帖由 showsa 于 2008-5-21 14:09 發(fā)表
在并發(fā)高的情況下，別忘記設(shè)置相關(guān)參數(shù) 可以batch多條message

請(qǐng)教一下，需要設(shè)置哪些參數(shù)?我知道就是一些最大同時(shí)連接數(shù)，之類的。另外測(cè)試高并發(fā)一般用哪些工具呢？我現(xiàn)在用的是兩個(gè)，一個(gè)是super-smark,一個(gè)是自己寫的多線程的基于mysql++的工具。都不是很好用

作者: yueliangdao0608 時(shí)間: 2008-05-21 15:33

原帖由 飛哥林 于 2008-5-21 14:55 發(fā)表

請(qǐng)教一下，需要設(shè)置哪些參數(shù)?我知道就是一些最大同時(shí)連接數(shù)，之類的。另外測(cè)試高并發(fā)一般用哪些工具呢？我現(xiàn)在用的是兩個(gè)，一個(gè)是super-smark,一個(gè)是自己寫的多線程的基于mysql++的工具。都不是很好用

APACHE 的 AB工具，不是說了嘛

作者: 飛哥林 時(shí)間: 2008-05-21 15:42

原帖由 yueliangdao0608 于 2008-5-21 15:33 發(fā)表

APACHE 的 AB工具，不是說了嘛

我暈，我沒好好看回帖，我試試先。

目前測(cè)試的insert操作，我50個(gè)線程同時(shí)工作，結(jié)果很慢很慢，不知道是我自己的測(cè)試方法的原因，還是cluster里面的寫的時(shí)候，鎖比較多。

作者: yejr 時(shí)間: 2008-05-21 15:43
我的測(cè)試結(jié)果沒你這么大差距，我用的是5.1版本，并且隨著并發(fā)線程數(shù)的增加，tps也會(huì)增加，不過不是無限增加，呵呵

作者: 飛哥林 時(shí)間: 2008-05-21 15:55

原帖由 yueliangdao0608 于 2008-5-21 15:33 發(fā)表

APACHE 的 AB工具，不是說了嘛

apache ab是一個(gè)httpd的測(cè)試工具啊，怎么直接測(cè)試數(shù)據(jù)庫(kù)呢？新人比較愚笨，請(qǐng)明示。然道自己在寫一個(gè)web服務(wù)來訪問數(shù)據(jù)庫(kù)？

作者: 飛哥林 時(shí)間: 2008-05-21 15:57

原帖由 yejr 于 2008-5-21 15:43 發(fā)表
我的測(cè)試結(jié)果沒你這么大差距，我用的是5.1版本，并且隨著并發(fā)線程數(shù)的增加，tps也會(huì)增加，不過不是無限增加，呵呵

看官方文檔應(yīng)該5.1性能是有所提升，我測(cè)試的結(jié)果也是并發(fā)線程數(shù)的增加，tps會(huì)增加，不過不是無限增加，但是我只測(cè)試了10個(gè)線程，剛剛在CGE版本里面測(cè)試50和100個(gè)線程，簡(jiǎn)直慢死。不過我不知道是不是我的測(cè)試工具的原因，等我找到原因了，再和大家說。

作者: yejr 時(shí)間: 2008-05-21 16:18
我用sysbench測(cè)試的，4個(gè)data node，3個(gè)sql node，基于磁盤存儲(chǔ)數(shù)據(jù)；標(biāo)準(zhǔn)2950，8g內(nèi)存，600w行記錄
我測(cè)試的最好情況中，tps大概是正常innodb的1/3，myisam沒對(duì)比過。
3個(gè)sql node我采用mysql proxy來做中間件的，如果是單獨(dú)連接到一個(gè)sql node，則效率確實(shí)很差。

作者: 飛哥林 時(shí)間: 2008-05-21 16:54

原帖由 yejr 于 2008-5-21 16:18 發(fā)表
我用sysbench測(cè)試的，4個(gè)data node，3個(gè)sql node，基于磁盤存儲(chǔ)數(shù)據(jù)；標(biāo)準(zhǔn)2950，8g內(nèi)存，600w行記錄
我測(cè)試的最好情況中，tps大概是正常innodb的1/3，myisam沒對(duì)比過。
3個(gè)sql node我采用mysql proxy來做中間 ...

我忘了說清楚了，對(duì)比的是myisam
我也考慮一個(gè)sql node不行，前置加了lvs，確實(shí)會(huì)好很多。

作者: 飛哥林 時(shí)間: 2008-05-21 17:38
再引入一個(gè)話題，mysql cluster到目前為止是不能在線增加data node和sql node的。有沒有同學(xué)考慮過怎么實(shí)現(xiàn)這個(gè)？
google的理念里面，似乎有一段說，最好是不要修節(jié)點(diǎn)而是替換和增加，假如能做到系統(tǒng)里面的節(jié)點(diǎn)都是同質(zhì)化的，同樣的硬件同樣的軟件，一旦性能瓶頸到了，直接再上一臺(tái)機(jī)器就解決了，豈不是很爽。目前很多東西應(yīng)該都是這么做的吧。

作者: yejr 時(shí)間: 2008-05-21 18:08

原帖由 飛哥林 于 2008-5-21 17:38 發(fā)表
再引入一個(gè)話題，mysql cluster到目前為止是不能在線增加data node和sql node的。有沒有同學(xué)考慮過怎么實(shí)現(xiàn)這個(gè)？
google的理念里面，似乎有一段說，最好是不要修節(jié)點(diǎn)而是替換和增加，假如能做到系統(tǒng)里面的節(jié)點(diǎn) ...

現(xiàn)在是沒辦法了，相信以后應(yīng)該會(huì)支持的。

作者: showsa 時(shí)間: 2008-05-21 19:21
貼一點(diǎn)早期的測(cè)試數(shù)據(jù)

作者: talen-t 時(shí)間: 2008-05-21 20:38
樓上的,你貼出來的測(cè)試數(shù)據(jù),單機(jī)內(nèi)存是多少?有多少個(gè)對(duì)象?多少數(shù)據(jù)量?并發(fā)數(shù)是多少?

作者: showsa 時(shí)間: 2008-05-21 22:12
內(nèi)存2G/6G
數(shù)據(jù) 6W
并發(fā)300左右

這只是其中很少部分?jǐn)?shù)據(jù)，還有各種對(duì)比測(cè)試節(jié)點(diǎn)組合 cpu負(fù)載 Ethernet/sci socket/sci transporter 等

其實(shí)現(xiàn)在看來，很多地方還可以優(yōu)化，可我現(xiàn)在沒條件進(jìn)行詳細(xì)的測(cè)試

作者: yueliangdao0608 時(shí)間: 2008-05-21 22:12
多個(gè)節(jié)點(diǎn)組是可以間接在線添加的.去看一下MAIL LIST

作者: showsa 時(shí)間: 2008-05-21 22:16
月亮，現(xiàn)在還沒法在線添加data node節(jié)點(diǎn)，不過有辦法在線增加節(jié)點(diǎn)內(nèi)存

作者: yueliangdao0608 時(shí)間: 2008-05-21 22:20

原帖由 showsa 于 2008-5-21 22:16 發(fā)表
月亮，現(xiàn)在還沒法在線添加data node節(jié)點(diǎn)，不過有辦法在線增加節(jié)點(diǎn)內(nèi)存

手冊(cè)上是說沒有直接的辦法.可是我以前測(cè)試的時(shí)候的確可以在線添加.

作者: showsa 時(shí)間: 2008-05-21 23:12
不知道你是怎么添加的

現(xiàn)在的內(nèi)部機(jī)制，根據(jù)我的理解，是沒辦法在線添加的

作者: qlks 時(shí)間: 2008-05-22 09:31
貼出配置文件

以及你現(xiàn)在數(shù)據(jù)庫(kù)大小

作者: skynet 時(shí)間: 2008-05-22 12:16
為什么不用postgresql來測(cè)試呢，我想知道，但沒有環(huán)境。

作者: babyyellow 時(shí)間: 2008-05-22 13:21
我做了有1個(gè)月的測(cè)試吧，

mysql cluster 的并發(fā)很差勁，至少我的測(cè)試結(jié)果是這樣的。

我這邊經(jīng)常會(huì)把集群給壓死，導(dǎo)致cluster 失敗。

后來，干脆放棄mysql CLUSTER 了。

作者: wwdwwd 時(shí)間: 2008-05-22 14:44

原帖由 飛哥林 于 2008-5-20 14:54 發(fā)表
我在redhat as5 4G mem環(huán)境里面搭了一套cluster環(huán)境。
4臺(tái)Data node， 4臺(tái)MySQL node，1臺(tái)mgm node，2臺(tái)LVS前置做load balance

測(cè)試結(jié)果是：
insert操作和標(biāo)準(zhǔn)mysql比較下降差不多80%
select操作和標(biāo)準(zhǔn)my ...

哥們，chinaunix的論壇里面有一篇帖子里面詳細(xì)討論了這個(gè)方案，大部分人的觀點(diǎn)是暫不適合企業(yè)級(jí)應(yīng)用，個(gè)人測(cè)試測(cè)試就ok了。
我自己簡(jiǎn)單的測(cè)試了一下，三臺(tái)。一臺(tái)mysql server，兩代data，mgm node也放在mysql server上，算是最精簡(jiǎn)配置了。
我測(cè)試的結(jié)果是：

1：bug太多，我在5.0.*系列上配了幾次都不成功，在5.1.*系列上就正常；
2：速度跟單臺(tái)的相比差不多；
3：所有的數(shù)據(jù)都存儲(chǔ)在每個(gè)data node的內(nèi)存里面，比如說數(shù)據(jù)庫(kù)大小為10m，就會(huì)占用每個(gè)data node的10m內(nèi)存，但是同時(shí)也會(huì)占用100m左右的硬盤，這個(gè)很奇怪。

作者: 飛哥林 時(shí)間: 2008-05-22 14:52

原帖由 wwdwwd 于 2008-5-22 14:44 發(fā)表

哥們，chinaunix的論壇里面有一篇帖子里面詳細(xì)討論了這個(gè)方案，大部分人的觀點(diǎn)是暫不適合企業(yè)級(jí)應(yīng)用，個(gè)人測(cè)試測(cè)試就ok了。
我自己簡(jiǎn)單的測(cè)試了一下，三臺(tái)。一臺(tái)mysql server，兩代data，mgm node也放在mysq ...

我暈，太打擊我了。

作者: wwdwwd 時(shí)間: 2008-05-22 15:00

原帖由 showsa 于 2008-5-20 16:54 發(fā)表
lz應(yīng)該測(cè)試高并發(fā)的情況
因?yàn)閏luster網(wǎng)絡(luò)特性，具有高延時(shí)，如果單線程測(cè)試的話，性能肯定很差
并且在高并發(fā)的情況下，可以設(shè)置多結(jié)果集綁定返回，從而提高吞吐量

請(qǐng)問多結(jié)果集綁定返回是什么意思？

作者: wwdwwd 時(shí)間: 2008-05-22 15:20

原帖由 showsa 于 2008-5-20 17:02 發(fā)表
目前網(wǎng)上很多所謂mysql cluster的測(cè)試，其實(shí)基本上只是個(gè)搭建起來能夠運(yùn)行而已
很多人還不理解mysql cluster構(gòu)架的初衷
當(dāng)你們遇到大數(shù)據(jù)量需要分表分庫(kù)的時(shí)候再來審視mysql cluster的構(gòu)架，你會(huì)發(fā)現(xiàn)是多么的 ...

有一個(gè)問題：mysql cluster的數(shù)據(jù)會(huì)放到內(nèi)存里面，大數(shù)據(jù)量需要分庫(kù)分表的話那得多大的內(nèi)存？

作者: yueliangdao0608 時(shí)間: 2008-05-22 16:19

原帖由 wwdwwd 于 2008-5-22 15:20 發(fā)表

有一個(gè)問題：mysql cluster的數(shù)據(jù)會(huì)放到內(nèi)存里面，大數(shù)據(jù)量需要分庫(kù)分表的話那得多大的內(nèi)存？

I remember there is a formula to calculate this.

Except the os and other memory in use,the approximate memory of a data node is a half of the actual data.

作者: sunnyfun 時(shí)間: 2008-05-22 16:22

原帖由 wwdwwd 于 2008-5-22 15:20 發(fā)表

有一個(gè)問題：mysql cluster的數(shù)據(jù)會(huì)放到內(nèi)存里面，大數(shù)據(jù)量需要分庫(kù)分表的話那得多大的內(nèi)存？

有意思，那看看這個(gè)：

So how will MySQL Cluster work on a
Niagara-II with 256 GB memory?
Unpublished results from 2002
* Benchmark load:
* Simple read, read 100 bytes of data through primary key
* Simple update, update 8 bytes of data through primary key
* Both are transactional
* HW: 72-CPU SunFire 15k, 256 GB memory
* CPU’s: Ultra Sparc-III@900MHz
* 32-node NDB Cluster, 1 data node locked to 1 CPU
* Results (Database size = 88 Gbyte, ~900 million records):
* Simple Read: 1.5 million reads per second
* Simple update: 340.000 updates per second

作者: yueliangdao0608 時(shí)間: 2008-05-22 16:25

原帖由 sunnyfun 于 2008-5-22 16:22 發(fā)表

有意思，那看看這個(gè)：

This machine is very robust!

作者: sunnyfun 時(shí)間: 2008-05-22 16:38
順便看看網(wǎng)絡(luò)對(duì)Cluster的影響：

PS：什么是SCI

　　IEEE SCI

　　IEEE 標(biāo)準(zhǔn) SCI 的延遲更少（低于 2.5 微秒），并且其單向速度可達(dá)到 400 MB／秒 (3.2 Gbps)。SCI 是基于環(huán)拓?fù)涞木W(wǎng)絡(luò)系統(tǒng)，不像以太網(wǎng)是星形拓?fù)�。這將使在較大規(guī)模的節(jié)點(diǎn)之間通信速度更快。更有用的是環(huán)面拓?fù)渚W(wǎng)絡(luò)，它在節(jié)點(diǎn)之間有許多環(huán)形結(jié)構(gòu)。兩維環(huán)面可以用 n 乘 m 的網(wǎng)格表示，其中在每一行和每一列都有一個(gè)環(huán)形網(wǎng)絡(luò)。三維環(huán)面也類似，可以用三維立體節(jié)點(diǎn)網(wǎng)格表示，每一層上有一個(gè)環(huán)形網(wǎng)絡(luò)。密集超級(jí)計(jì)算并行系統(tǒng)使用環(huán)面拓?fù)渚W(wǎng)絡(luò)，為成百上千個(gè)節(jié)點(diǎn)之間的通信提供相對(duì)最快的路徑。

　　大多數(shù)操作系統(tǒng)的限制因素不是操作系統(tǒng)或網(wǎng)絡(luò)接口，而是服務(wù)器的內(nèi)部 PCI 總線系統(tǒng)。幾乎所有臺(tái)式 PC 通常有基本 32-位，33-MHz PCI，并且大多數(shù)低端服務(wù)器只提供 133 MB／秒 (1 Gbps)，這限制了那些網(wǎng)卡的能力。一些昂貴的高端服務(wù)器，如 Compaq Proliant 6500 和 IBM Netfinity 7000 系列，都有 64-位， 66-MHz 網(wǎng)卡，它們能夠以四倍速度運(yùn)行。不幸地是，矛盾是更多公司使用低端的系統(tǒng)，因此大多數(shù)供應(yīng)商最終生產(chǎn)和銷售更多低端 PCI 網(wǎng)卡。也有專門的 64-位，66-MHz PCI 網(wǎng)卡，但價(jià)格要貴許多。例如，Intel 提供了這種類型的“快速以太網(wǎng)”網(wǎng)卡，價(jià)格約 $400 到 $500，幾乎是普通 PCI 版本價(jià)格的 5 倍。

千兆以太網(wǎng)卡延遲估計(jì)起碼在8、9微秒吧。相信將來服務(wù)器能直連萬(wàn)兆網(wǎng)的話，就會(huì)是另一種情況了。

作者: yueliangdao0608 時(shí)間: 2008-05-22 16:43
加精了。

再討論。

作者: sihexuan 時(shí)間: 2008-05-22 20:46

原帖由 showsa 于 2008-5-20 17:02 發(fā)表
目前網(wǎng)上很多所謂mysql cluster的測(cè)試，其實(shí)基本上只是個(gè)搭建起來能夠運(yùn)行而已
很多人還不理解mysql cluster構(gòu)架的初衷
當(dāng)你們遇到大數(shù)據(jù)量需要分表分庫(kù)的時(shí)候再來審視mysql cluster的構(gòu)架，你會(huì)發(fā)現(xiàn)是多么的 ...

太親切了，NDB這個(gè)東西真的很好，不過技術(shù)要求也比較高，我們的NDB因?yàn)镾WAP過小而起不來的問題而發(fā)展成大問題

作者: sihexuan 時(shí)間: 2008-05-22 21:15

原帖由 showsa 于 2008-5-21 23:12 發(fā)表
不知道你是怎么添加的

現(xiàn)在的內(nèi)部機(jī)制，根據(jù)我的理解，是沒辦法在線添加的

• N: Node Restart
• IN: Initial Node Restart
• S: System Restart
• IS: Initial System Restart

DataMemory bytes 80M 1M 1024G (subject to available system RAM and size of IndexMemory) N

這個(gè)是手冊(cè)上說明的，數(shù)據(jù)節(jié)點(diǎn)內(nèi)存大小只要重起節(jié)點(diǎn)就可以做到

作者: showsa 時(shí)間: 2008-05-23 00:24

原帖由 sihexuan 于 2008-5-22 21:15 發(fā)表

• N: Node Restart
• IN: Initial Node Restart
• S: System Restart
• IS: Initial System Restart

DataMemory bytes 80M 1M 1024G (subject to available system RAM an ...

請(qǐng)看我之前的回復(fù)

原帖由 showsa 于 2008-5-21 22:16 發(fā)表
月亮，現(xiàn)在還沒法在線添加data node節(jié)點(diǎn)，不過有辦法在線增加節(jié)點(diǎn)內(nèi)存

作者: linux_admin 時(shí)間: 2008-05-23 15:31
高手過招，十分幸運(yùn)
留個(gè)名。。

作者: hzcgz 時(shí)間: 2008-05-23 15:43
標(biāo)題: 回復(fù) #11 飛哥林的帖子
現(xiàn)實(shí)問題,在很多情況下并不能有效提高速度.不光是mysql cluster, 其它數(shù)據(jù)庫(kù)也有這樣的類似情況, 贊一個(gè)LZ的這種精神.

作者: 飛哥林 時(shí)間: 2008-05-23 16:18

原帖由 hzcgz 于 2008-5-23 15:43 發(fā)表
現(xiàn)實(shí)問題,在很多情況下并不能有效提高速度.不光是mysql cluster, 其它數(shù)據(jù)庫(kù)也有這樣的類似情況, 贊一個(gè)LZ的這種精神.

既然是內(nèi)存數(shù)據(jù)存儲(chǔ)的方式，不能提高速度，我實(shí)在是不明白。

我們團(tuán)隊(duì)原來自己做過一個(gè)分布式內(nèi)存數(shù)據(jù)庫(kù)，性能沒的說，現(xiàn)在field很多點(diǎn)大量用戶數(shù)據(jù)在跑。只是我們的方案是記錄根據(jù)hash分配到不同的node，而mysql cluster是將表分片，每條記錄都分一部分?jǐn)?shù)據(jù)到每個(gè)node上保存，我們節(jié)省了拆和拼的過程。

作者: raid_fifa 時(shí)間: 2008-05-23 16:40
mysql cluster 也是把記錄做hash，然后平均分布到每個(gè)data node上的；只不過是根據(jù)主鍵的hash分片的

ndbd的效率其實(shí)是很高的，mysql cluster的響應(yīng)時(shí)間上不去可能主要還和ndbd之間、ndbd和mysqld之間的數(shù)據(jù)傳輸、數(shù)據(jù)通訊、mysqld上的數(shù)據(jù)集生成等因素有關(guān)。

哪位兄弟試試NDBAPI？據(jù)說很多mysql cluster的case都是用NDBAPI，效率很高

作者: hzcgz 時(shí)間: 2008-05-23 17:01

原帖由 raid_fifa 于 2008-5-23 16:40 發(fā)表
mysql cluster 也是把記錄做hash，然后平均分布到每個(gè)data node上的；只不過是根據(jù)主鍵的hash分片的

ndbd的效率其實(shí)是很高的，mysql cluster的響應(yīng)時(shí)間上不去可能主要還和ndbd之間、ndbd和mysqld之間的數(shù)據(jù)傳 ...

有道理,謝謝提醒,抽空看一下NDBAPI.

但cluster系統(tǒng)的整體性能上不去也是一個(gè)現(xiàn)實(shí)問題(雖然有可能是數(shù)據(jù)傳輸和通信的瓶頸),特別是要在實(shí)際環(huán)境中使用時(shí)這點(diǎn)尤其頭痛.
我們?cè)瓉頂?shù)據(jù)庫(kù)cluster選型時(shí)也化了很多時(shí)間和精力,最后由于種種原因而放棄了常規(guī)的cluster 而采用了HA+GDA,現(xiàn)在8臺(tái)數(shù)據(jù)庫(kù)組成的服務(wù)還算滿足要求. 反正覺得一上多機(jī)系統(tǒng)后各方面要考慮的事情就來了.

作者: 飛哥林 時(shí)間: 2008-05-23 17:20

原帖由 raid_fifa 于 2008-5-23 16:40 發(fā)表
mysql cluster 也是把記錄做hash，然后平均分布到每個(gè)data node上的；只不過是根據(jù)主鍵的hash分片的

ndbd的效率其實(shí)是很高的，mysql cluster的響應(yīng)時(shí)間上不去可能主要還和ndbd之間、ndbd和mysqld之間的數(shù)據(jù)傳 ...

是hash完了，把整條記錄存到一個(gè)data node還是，將記錄分成n片，把每一片放到不同的node？這個(gè)里面實(shí)現(xiàn)的細(xì)節(jié)有沒有文檔能參考一下？實(shí)在不行，只能看源代碼了。
說道ndbapi倒是應(yīng)該會(huì)比較快，晚點(diǎn)我再試試。

作者: sunnyfun 時(shí)間: 2008-05-23 17:20
嗯，只有使用NDB API才能真正發(fā)揮 cluster 的效率，性能可以提高數(shù)倍。
不過要用C++直接從底層操作數(shù)據(jù)庫(kù)，難度還是有點(diǎn)的。

作者: chuhongze 時(shí)間: 2008-05-23 17:53
對(duì)于大量的數(shù)據(jù)的讀寫以及大量的數(shù)據(jù)并發(fā)，現(xiàn)在就我知道沒有太多更好的解決辦法。對(duì)于網(wǎng)絡(luò)的流量可以分流，對(duì)于數(shù)據(jù)庫(kù)的瓶頸，如何處理呢？LZ的測(cè)試是"符合實(shí)際情況的" .

[ 本帖最后由 chuhongze 于 2008-5-27 14:44 編輯 ]

作者: iamacnhero 時(shí)間: 2008-05-24 19:01
NDB不支持外鍵，而CLUSTER又必須用NDB

作者: raid_fifa 時(shí)間: 2008-05-26 09:39
標(biāo)題: 回復(fù) #63 飛哥林的帖子
記錄本身不再分片

作者: gxcooo 時(shí)間: 2008-05-26 09:48

原帖由 wwdwwd 于 2008-5-22 14:44 發(fā)表

哥們，chinaunix的論壇里面有一篇帖子里面詳細(xì)討論了這個(gè)方案，大部分人的觀點(diǎn)是暫不適合企業(yè)級(jí)應(yīng)用，個(gè)人測(cè)試測(cè)試就ok了。
我自己簡(jiǎn)單的測(cè)試了一下，三臺(tái)。一臺(tái)mysql server，兩代data，mgm node也放在mysq ...

3：所有的數(shù)據(jù)都存儲(chǔ)在每個(gè)data node的內(nèi)存里面，比如說數(shù)據(jù)庫(kù)大小為10m，就會(huì)占用每個(gè)data node的10m內(nèi)存，但是同時(shí)也會(huì)占用100m左右的硬盤，這個(gè)很奇怪。

有人能確認(rèn)wwdwwd說的這個(gè)第3點(diǎn)嗎？
我感覺不應(yīng)該是這樣的吧

作者: huifeideluotuo 時(shí)間: 2008-05-26 11:43
真應(yīng)該好好研究下QQ的數(shù)據(jù)庫(kù)架構(gòu)，他們的技術(shù)應(yīng)該說是比較牛B的了，記得網(wǎng)上有個(gè)帖子，QQ的技術(shù)在國(guó)內(nèi)也是數(shù)得著了。

哪位兄弟有此方面的信息，可以共享下，造福貧民！

作者: talen-t 時(shí)間: 2008-05-26 14:38
樓上的!
你想錯(cuò)了,如果論性能,一個(gè)體系中牛的不是DB層,是APP層!
騰訊的DB層很一般,強(qiáng)大的是APP

作者: yueliangdao0608 時(shí)間: 2008-05-26 15:49
DB只是存放信息的地方。這點(diǎn)要搞清楚。

作者: 飛哥林 時(shí)間: 2008-05-26 17:43

原帖由 gxcooo 于 2008-5-26 09:48 發(fā)表

有人能確認(rèn)wwdwwd說的這個(gè)第3點(diǎn)嗎？
我感覺不應(yīng)該是這樣的吧

說實(shí)話，我測(cè)試過程中沒有占用這么多硬盤空間。所占硬盤空間和我內(nèi)存中數(shù)據(jù)量基本平衡。

作者: nicsky 時(shí)間: 2008-05-27 14:17
very good.........................................

作者: nicsky 時(shí)間: 2008-06-01 07:13
good

作者: qlks 時(shí)間: 2008-06-02 11:56
貼出配置文件。。。
還有你測(cè)試時(shí)的網(wǎng)絡(luò)是多少的？是不是獨(dú)立的千兆網(wǎng)絡(luò)
這是最低要求，手冊(cè)上寫著的
還有我到現(xiàn)在都沒看到你測(cè)試的實(shí)際數(shù)據(jù)
比如單MySQL InnoDB key_buffer 4G 1線程，2線程，4線程，8線程，16線程...128線程事務(wù)量，或者說速度是多少，Cluster是多少？
你提供所謂的快20%~25%的數(shù)據(jù)太抽象
還有你測(cè)試的SQL語(yǔ)句是怎么樣的？主鍵的簡(jiǎn)單查詢？RANGE查詢？全表掃的查詢？
要解決問題，先把具體問題說清楚，我一直這么覺得的

作者: any0129 時(shí)間: 2008-06-02 14:46
這幾天剛剛接觸MySQL Cluster，準(zhǔn)備測(cè)試看是否適用于我們自己的業(yè)務(wù)

無奈配置起來一直有問題，現(xiàn)在也沒有搭建好配置環(huán)境。

哪位老大有自己整理的、可用的配置文檔，麻煩發(fā)給我一份。

我的Email是 w.zl29#163.com。

非常感謝

作者: 飛哥林 時(shí)間: 2008-06-04 16:35

原帖由 qlks 于 2008-6-2 11:56 發(fā)表
貼出配置文件。。。
還有你測(cè)試時(shí)的網(wǎng)絡(luò)是多少的？是不是獨(dú)立的千兆網(wǎng)絡(luò)
這是最低要求，手冊(cè)上寫著的
還有我到現(xiàn)在都沒看到你測(cè)試的實(shí)際數(shù)據(jù)
比如單MySQL InnoDB key_buffer 4G 1線程，2線程，4線程，8線程 ...

配置就懶得貼了。這兩個(gè)東西的對(duì)比，我主要是考慮在同樣環(huán)境，同樣配置情況下來做比較，假如為了測(cè)試上cluster，就要在硬件上網(wǎng)絡(luò)上都去做提升，那我這測(cè)試成本就上去了，不是我測(cè)試cluster的初衷。

作者: vrlinux.cn 時(shí)間: 2008-06-04 17:45
今天才看到這文章,遲了.也看了很多牛人牛語(yǔ).

我早前一段時(shí)間也簡(jiǎn)單測(cè)試過三四個(gè)節(jié)點(diǎn)的.我覺得mysql cluster的應(yīng)用,是針對(duì)大數(shù)據(jù)量,大并發(fā)的應(yīng)用上.否則就不如單機(jī)的性能.而要將mysql cluster的性能發(fā)揮到最大,就必要地結(jié)合LVS或第三方均衡軟件,這樣的效果,應(yīng)該是比較理想的

作者: vrlinux.cn 時(shí)間: 2008-06-04 17:46

原帖由 飛哥林 于 2008-5-20 16:33 發(fā)表
具體是不是master，我找不到有官方文檔來支持。
但是我在ndb_mgm里面show出來結(jié)果如下
其中id=3的后面顯示是master其他的沒有啊

ndb_mgm> show
Cluster Configuration
---------------------
[ndbd(NDB ...

對(duì)于master的問題,我支持6樓的觀點(diǎn).雖然在show顯示出來的,只有一個(gè)master,但在實(shí)際測(cè)試使用中,不管你寫入哪個(gè)NDB,數(shù)據(jù)都會(huì)同步到其它的NDB上.所以,認(rèn)為都是master

作者: showsa 時(shí)間: 2008-06-05 09:45

原帖由 vrlinux.cn 于 2008-6-4 17:46 發(fā)表

對(duì)于master的問題,我支持6樓的觀點(diǎn).雖然在show顯示出來的,只有一個(gè)master,但在實(shí)際測(cè)試使用中,不管你寫入哪個(gè)NDB,數(shù)據(jù)都會(huì)同步到其它的NDB上.所以,認(rèn)為都是master

你根本就不知道你在說什么
至于master這個(gè)用詞，開發(fā)組都說了不妥，可是現(xiàn)在改已經(jīng)來不及了

13樓才是正確的解釋

這個(gè)精華帖子我看不出來哪里是精華了，很多都是胡說八道

[ 本帖最后由 showsa 于 2008-6-5 09:47 編輯 ]

作者: yueliangdao0608 時(shí)間: 2008-06-05 10:00

原帖由 showsa 于 2008-6-5 09:45 發(fā)表

你根本就不知道你在說什么
至于master這個(gè)用詞，開發(fā)組都說了不妥，可是現(xiàn)在改已經(jīng)來不及了

13樓才是正確的解釋

這個(gè)精華帖子我看不出來哪里是精華了，很多都是胡說八道

I added this highlight post in order to make every one here discuss more and more.

作者: qlks 時(shí)間: 2008-06-05 11:12

原帖由 showsa 于 2008-6-5 09:45 發(fā)表

你根本就不知道你在說什么
至于master這個(gè)用詞，開發(fā)組都說了不妥，可是現(xiàn)在改已經(jīng)來不及了

13樓才是正確的解釋

這個(gè)精華帖子我看不出來哪里是精華了，很多都是胡說八道

的確，我也沒看出解決了什么問題

作者: vrlinux.cn 時(shí)間: 2008-06-05 17:29

原帖由 showsa 于 2008-6-5 09:45 發(fā)表

你根本就不知道你在說什么
至于master這個(gè)用詞，開發(fā)組都說了不妥，可是現(xiàn)在改已經(jīng)來不及了

13樓才是正確的解釋

這個(gè)精華帖子我看不出來哪里是精華了，很多都是胡說八道

也許你是牛一點(diǎn),研究得多一點(diǎn)

但我說的master,是針對(duì)這個(gè)結(jié)果里的master

[ndbd(NDB)]    4 node(s)
id=2 @192.168.1.221  (Version: 5.0.51, Nodegroup: 0)
id=3 @192.168.1.223  (Version: 5.0.51, Nodegroup: 0, Master)
id=4 @192.168.1.225  (Version: 5.0.51, Nodegroup: 1)
id=5 @192.168.1.227  (Version: 5.0.51, Nodegroup: 1)

作者: yueliangdao0608 時(shí)間: 2008-06-05 17:45
We should spend more time and energy to study and discuss , no matter who is right or not.

After all,everyone here is a novice from the beginning.

作者: nicsky 時(shí)間: 2008-06-06 00:05
good...................

作者: showsa 時(shí)間: 2008-06-06 09:30

原帖由 vrlinux.cn 于 2008-6-5 17:29 發(fā)表

也許你是牛一點(diǎn),研究得多一點(diǎn)

但我說的master,是針對(duì)這個(gè)結(jié)果里的master

我沒有針對(duì)你個(gè)人的意思，如果傷害到你了，向你說聲對(duì)不起。

還有我想說的是，我所說的就是你指的master

作者: vrlinux.cn 時(shí)間: 2008-06-06 16:54

原帖由 showsa 于 2008-6-6 09:30 發(fā)表

我沒有針對(duì)你個(gè)人的意思，如果傷害到你了，向你說聲對(duì)不起。

還有我想說的是，我所說的就是你指的master

雖然感覺不爽,但也沒那么嚴(yán)重
那我那想請(qǐng)教一下,8樓里的

ndb_mgm> show
Cluster Configuration
---------------------
[ndbd(NDB)]    4 node(s)
id=2 @192.168.1.221  (Version: 5.0.51, Nodegroup: 0)
id=3 @192.168.1.223  (Version: 5.0.51, Nodegroup: 0, Master)
id=4 @192.168.1.225  (Version: 5.0.51, Nodegroup: 1)
id=5 @192.168.1.227  (Version: 5.0.51, Nodegroup: 1)

這四個(gè)里,是其中一個(gè)是master,還是四個(gè)都是master,是平等關(guān)系.

作者: yueliangdao0608 時(shí)間: 2008-06-06 17:47

原帖由 vrlinux.cn 于 2008-6-6 16:54 發(fā)表

雖然感覺不爽,但也沒那么嚴(yán)重
那我那想請(qǐng)教一下,8樓里的

這四個(gè)里,是其中一個(gè)是master,還是四個(gè)都是master,是平等關(guān)系.

There are the same position within the whole cluster.

作者: chuhongze 時(shí)間: 2008-06-07 00:20
大家說得不錯(cuò),但都不是最有效的解決方法

[ 本帖最后由 chuhongze 于 2008-6-7 00:22 編輯 ]

作者: scottsiu 時(shí)間: 2008-06-15 13:38
標(biāo)題: 回復(fù) #1 飛哥林的帖子
不知LZ想將MySQL用于什么方面，我個(gè)人還是認(rèn)為如果是要做并發(fā)事務(wù)處理的話PostgreSQL會(huì)高性能得多，不管是Cluster還是單點(diǎn)運(yùn)行！

[ 本帖最后由 qlks 于 2008-6-16 16:09 編輯 ]

作者: qlks 時(shí)間: 2008-06-16 16:10

原帖由 scottsiu 于 2008-6-15 13:38 發(fā)表
不知LZ想將MySQL用于什么方面，我個(gè)人還是認(rèn)為如果是要做并發(fā)事務(wù)處理的話PostgreSQL會(huì)高性能得多，不管是Cluster還是單點(diǎn)運(yùn)行！

就知道吹吧~~~再怎么使勁吹，PostgreSQL也就那樣了

作者: wwdwwd 時(shí)間: 2008-06-29 13:36

原帖由 sunnyfun 于 2008-5-22 16:22 發(fā)表

有意思，那看看這個(gè)：

這個(gè)服務(wù)器這么牛？小弟見識(shí)短淺，還真沒見過，呵呵

作者: ruochen 時(shí)間: 2008-07-10 15:00

原帖由 qlks 于 2008-6-16 16:10 發(fā)表

就知道吹吧~~~再怎么使勁吹，PostgreSQL也就那樣了

LS說的是并發(fā)事務(wù)處理的話，我覺得沒什么不妥

如果不是用外鍵，也就是使用MyISAM單純存儲(chǔ)數(shù)據(jù)的話
還是選擇MySQL

作者: cserken 時(shí)間: 2008-11-28 16:55
我想問問樓主是用什么測(cè)試的呢?

作者: ooooldman 時(shí)間: 2010-07-20 21:46

頂起來，現(xiàn)在出7.0了，大家有沒有測(cè)試的了，
我準(zhǔn)備在生產(chǎn)上集群

作者: findmywayout 時(shí)間: 2011-07-13 17:40
期待下文。。。

作者: Donqixode 時(shí)間: 2011-09-26 11:46

嗯，只有使用NDB API才能真正發(fā)揮 cluster 的效率，性能可以提高數(shù)倍。
不過要用C++直接從底層操作數(shù)據(jù)庫(kù)， ...
sunnyfun 發(fā)表于 2008-05-23 17:20

我用過NDB API，感覺支持的查詢條件太過簡(jiǎn)單，如果對(duì)于一個(gè)復(fù)雜事務(wù)，還是需要將中間結(jié)果返回到應(yīng)用再做判別后，再調(diào)用NDB API，這樣的上下文切換和代碼復(fù)雜度造成效率降低且易出錯(cuò)。
而且，NDB API也無法支持SQL級(jí)別的東西，如存儲(chǔ)過程，所以在很多應(yīng)用中，感覺NDB API是個(gè)雞肋。當(dāng)然，這個(gè)結(jié)論是我對(duì)NDB API還不是很熟悉的基礎(chǔ)上得出的，請(qǐng)高手指點(diǎn)。

作者: q1030965736 時(shí)間: 2013-01-04 09:31
{:3_200:}

作者: Shaquile 時(shí)間: 2013-01-04 17:04
本帖最后由 Shaquile 于 2013-01-04 17:05 編輯

[MYSQLD]

[MYSQLD]

作者: caabcal 時(shí)間: 2013-09-21 00:41

請(qǐng)問樓主用過當(dāng)前的版本：mysql-5.6.11 ndb-7.3.2 做過測(cè)試嗎？

現(xiàn)在MySQL集群還是雞肋嗎？

飛哥林發(fā)表于 2008-05-20 14:54
我在redhat as5 4G mem環(huán)境里面搭了一套cluster環(huán)境。
4臺(tái)Data node， 4臺(tái)MySQL node，1臺(tái)mgm node，2臺(tái)LV ...

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