 |
 |
 |
 |
 |
 |
||
 |
 |
 |
 |
 |
| 4 | 1/1 | 返回列表 |
| 查看: 1025 | 回復(fù): 3 | |||
mingyue8608銀蟲 (小有名氣)
|
[交流]
材料數(shù)據(jù)庫(kù)的編制 已有2人參與
|
||
| 最近在做一個(gè)數(shù)據(jù)庫(kù)，發(fā)現(xiàn)材料的性能很多很雜，屬于非關(guān)系型，如何處理？求高手探討！ |
回復(fù)此樓» 猜你喜歡
材料與化工328分調(diào)劑
已經(jīng)有3人回復(fù)
-
279分求調(diào)劑 一志愿211
已經(jīng)有20人回復(fù)
-
293求調(diào)劑
已經(jīng)有3人回復(fù)
-
一志愿華東理工大學(xué)081700，初試分?jǐn)?shù)271
已經(jīng)有6人回復(fù)
-
085404電子信息284分求調(diào)劑
已經(jīng)有3人回復(fù)
-
306求0703調(diào)劑一志愿華中師范
已經(jīng)有9人回復(fù)
-
一志愿吉大化學(xué)322求調(diào)劑
已經(jīng)有6人回復(fù)
-
求調(diào)劑
已經(jīng)有5人回復(fù)
-
344求調(diào)劑
已經(jīng)有3人回復(fù)
-
一志愿哈工大，085400，320，求調(diào)劑
已經(jīng)有3人回復(fù)
» 本主題相關(guān)商家推薦: (我也要在這里推廣)
» 本主題相關(guān)價(jià)值貼推薦，對(duì)您同樣有幫助:
- 《天然產(chǎn)物研究與開發(fā)》雜志招聘專業(yè)編輯一名（事業(yè)編制崗位）
已經(jīng)有3人回復(fù)
- 上海高等研究院（籌）信息科學(xué)與技術(shù)研究部招聘啟事
已經(jīng)有8人回復(fù)
libralibra
至尊木蟲 (著名寫手)
驃騎將軍
- 程序強(qiáng)帖: 40
- 應(yīng)助: 817 (博后)
- 金幣: 12914.1
- 紅花: 64
- 帖子: 2238
- 在線: 287.3小時(shí)
- 蟲號(hào): 696514
- 注冊(cè): 2009-02-05
- 專業(yè): 計(jì)算機(jī)軟件
3樓2012-07-27 16:53:24
mingyue8608
銀蟲 (小有名氣)
- 應(yīng)助: 0 (幼兒園)
- 金幣: 275.4
- 紅花: 1
- 帖子: 72
- 在線: 49.4小時(shí)
- 蟲號(hào): 657200
- 注冊(cè): 2008-11-18
- 性別: GG
- 專業(yè): 金屬材料表面科學(xué)與工程
4樓2012-07-27 18:03:48
yalefield
金蟲 (文壇精英)
老漢一枚
- 程序強(qiáng)帖: 3
- 應(yīng)助: 129 (高中生)
- 貴賓: 0.17
- 金幣: 21238.9
- 散金: 3440
- 紅花: 66
- 帖子: 12101
- 在線: 759.1小時(shí)
- 蟲號(hào): 96063
- 注冊(cè): 2005-10-07
- 專業(yè): 高等教育學(xué)
- 管轄: 計(jì)算模擬
★
小木蟲: 金幣+0.5, 給個(gè)紅包，謝謝回帖
小木蟲: 金幣+0.5, 給個(gè)紅包，謝謝回帖
|
考慮NoSQL數(shù)據(jù)庫(kù)---MongoDB和Redis。 --------------以下是轉(zhuǎn)載------------------- http://www.iteye.com/topic/524977 隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，非關(guān)系型的數(shù)據(jù)庫(kù)現(xiàn)在成了一個(gè)極其熱門的新領(lǐng)域，非關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品的發(fā)展非常迅速。而傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問(wèn)題，例如： 1、High performance - 對(duì)數(shù)據(jù)庫(kù)高并發(fā)讀寫的需求 web2.0網(wǎng)站要根據(jù)用戶個(gè)性化信息來(lái)實(shí)時(shí)生成動(dòng)態(tài)頁(yè)面和提供動(dòng)態(tài)信息，所以基本上無(wú)法使用動(dòng)態(tài)頁(yè)面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫(kù)并發(fā)負(fù)載非常高，往往要達(dá)到每秒上萬(wàn)次讀寫請(qǐng)求。關(guān)系數(shù)據(jù)庫(kù)應(yīng)付上萬(wàn)次SQL查詢還勉強(qiáng)頂?shù)米�，但是�?yīng)付上萬(wàn)次SQL寫數(shù)據(jù)請(qǐng)求，硬盤IO就已經(jīng)無(wú)法承受了。其實(shí)對(duì)于普通的BBS網(wǎng)站，往往也存在對(duì)高并發(fā)寫請(qǐng)求的需求，例如像JavaEye網(wǎng)站的實(shí)時(shí)統(tǒng)計(jì)在線用戶狀態(tài)，記錄熱門帖子的點(diǎn)擊次數(shù)，投票計(jì)數(shù)等，因此這是一個(gè)相當(dāng)普遍的需求。 2、Huge Storage - 對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪問(wèn)的需求 類似Facebook，twitter，F(xiàn)riendfeed這樣的SNS網(wǎng)站，每天用戶產(chǎn)生海量的用戶動(dòng)態(tài)，以Friendfeed為例，一個(gè)月就達(dá)到了2.5億條用戶動(dòng)態(tài)，對(duì)于關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，在一張2.5億條記錄的表里面進(jìn)行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動(dòng)輒數(shù)以億計(jì)的帳號(hào)，關(guān)系數(shù)據(jù)庫(kù)也很難應(yīng)付。 3、High Scalability && High Availability- 對(duì)數(shù)據(jù)庫(kù)的高可擴(kuò)展性和高可用性的需求 在基于web的架構(gòu)當(dāng)中，數(shù)據(jù)庫(kù)是最難進(jìn)行橫向擴(kuò)展的，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶量和訪問(wèn)量與日俱增的時(shí)候，你的數(shù)據(jù)庫(kù)卻沒(méi)有辦法像web server和app server那樣簡(jiǎn)單的通過(guò)添加更多的硬件和服務(wù)節(jié)點(diǎn)來(lái)擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來(lái)說(shuō)，對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫(kù)不能通過(guò)不斷的添加服務(wù)器節(jié)點(diǎn)來(lái)實(shí)現(xiàn)擴(kuò)展呢？ 在上面提到的“三高”需求面前，關(guān)系數(shù)據(jù)庫(kù)遇到了難以克服的障礙，而對(duì)于web2.0網(wǎng)站來(lái)說(shuō)，關(guān)系數(shù)據(jù)庫(kù)的很多主要特性卻往往無(wú)用武之地，例如： 1、數(shù)據(jù)庫(kù)事務(wù)一致性需求 很多web實(shí)時(shí)系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫(kù)事務(wù)，對(duì)讀一致性的要求很低，有些場(chǎng)合對(duì)寫一致性要求也不高。因此數(shù)據(jù)庫(kù)事務(wù)管理成了數(shù)據(jù)庫(kù)高負(fù)載下一個(gè)沉重的負(fù)擔(dān)。 2、數(shù)據(jù)庫(kù)的寫實(shí)時(shí)性和讀實(shí)時(shí)性需求 對(duì)關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來(lái)這條數(shù)據(jù)的，但是對(duì)于很多web應(yīng)用來(lái)說(shuō)，并不要求這么高的實(shí)時(shí)性，比方說(shuō)我（JavaEye的robbin）發(fā)一條消息之后，過(guò)幾秒乃至十幾秒之后，我的訂閱者才看到這條動(dòng)態(tài)是完全可以接受的。 3、對(duì)復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢的需求 任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個(gè)大表的關(guān)聯(lián)查詢，以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報(bào)表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設(shè)計(jì)角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡(jiǎn)單條件分頁(yè)查詢，SQL的功能被極大的弱化了。 因此，關(guān)系數(shù)據(jù)庫(kù)在這些越來(lái)越多的應(yīng)用場(chǎng)景下顯得不那么合適了，為了解決這類問(wèn)題的非關(guān)系數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生，現(xiàn)在這兩年，各種各樣非關(guān)系數(shù)據(jù)庫(kù)，特別是鍵值數(shù)據(jù)庫(kù)(Key-Value Store DB)風(fēng)起云涌，多得讓人眼花繚亂。前不久國(guó)外剛剛舉辦了NoSQL Conference，各路NoSQL數(shù)據(jù)庫(kù)紛紛亮相，加上未亮相但是名聲在外的，起碼有超過(guò)10個(gè)開源的NoSQLDB，例如： Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB， ...... 這些NoSQL數(shù)據(jù)庫(kù)，有的是用C/C++編寫的，有的是用Java編寫的，還有的是用Erlang編寫的，每個(gè)都有自己的獨(dú)到之處，看都看不過(guò)來(lái)了，我(robbin)也只能從中挑選一些比較有特色，看起來(lái)更有前景的產(chǎn)品學(xué)習(xí)和了解一下。這些NoSQL數(shù)據(jù)庫(kù)大致可以分為以下的三類： 一、滿足極高讀寫性能需求的Kye-Value數(shù)據(jù)庫(kù)：Redis，Tokyo Cabinet， Flare 高性能Key-Value數(shù)據(jù)庫(kù)的主要特點(diǎn)就是具有極高的并發(fā)讀寫性能，Redis，Tokyo Cabinet， Flare，這3個(gè)Key-Value DB都是用C編寫的，他們的性能都相當(dāng)出色，但出了出色的性能，他們還有自己獨(dú)特的功能： 1、Redis Redis是一個(gè)很新的項(xiàng)目，剛剛發(fā)布了1.0版本。Redis本質(zhì)上是一個(gè)Key-Value類型的內(nèi)存數(shù)據(jù)庫(kù)，很像memcached，整個(gè)數(shù)據(jù)庫(kù)統(tǒng)統(tǒng)加載在內(nèi)存當(dāng)中進(jìn)行操作，定期通過(guò)異步操作把數(shù)據(jù)庫(kù)數(shù)據(jù)flush到硬盤上進(jìn)行保存。因?yàn)槭羌儍?nèi)存操作，Redis的性能非常出色，每秒可以處理超過(guò)10萬(wàn)次讀寫操作，是我知道的性能最快的Key-Value DB。 Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存List鏈表和Set集合的數(shù)據(jù)結(jié)構(gòu)，而且還支持對(duì)List進(jìn)行各種操作，例如從List兩端push和pop數(shù)據(jù)，取List區(qū)間，排序等等，對(duì)Set支持各種集合的并集交集操作，此外單個(gè)value的最大限制是1GB，不像memcached只能保存1MB的數(shù)據(jù)，因此Redis可以用來(lái)實(shí)現(xiàn)很多有用的功能，比方說(shuō)用他的List來(lái)做FIFO雙向鏈表，實(shí)現(xiàn)一個(gè)輕量級(jí)的高性能消息隊(duì)列服務(wù)，用他的Set可以做高性能的tag系統(tǒng)等等。另外Redis也可以對(duì)存入的Key-Value設(shè)置expire時(shí)間，因此也可以被當(dāng)作一個(gè)功能加強(qiáng)版的memcached來(lái)用。 Redis的主要缺點(diǎn)是數(shù)據(jù)庫(kù)容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫，并且它沒(méi)有原生的可擴(kuò)展機(jī)制，不具有scale（可擴(kuò)展）能力，要依賴客戶端來(lái)實(shí)現(xiàn)分布式讀寫，因此Redis適合的場(chǎng)景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。目前使用Redis的網(wǎng)站有g(shù)ithub，Engine Yard。 2、Tokyo Cabinet和Tokoy Tyrant TC和TT的開發(fā)者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS網(wǎng)站mixi.jp上，TC發(fā)展的時(shí)間最早，現(xiàn)在已經(jīng)是一個(gè)非常成熟的項(xiàng)目，也是Kye-Value數(shù)據(jù)庫(kù)領(lǐng)域最大的熱點(diǎn)，現(xiàn)在被廣泛的應(yīng)用在很多很多網(wǎng)站上。TC是一個(gè)高性能的存儲(chǔ)引擎，而TT提供了多線程高并發(fā)服務(wù)器，性能也非常出色，每秒可以處理4-5萬(wàn)次讀寫操作。 TC除了支持Key-Value存儲(chǔ)之外，還支持保存Hashtable數(shù)據(jù)類型，因此很像一個(gè)簡(jiǎn)單的數(shù)據(jù)庫(kù)表，并且還支持基于column的條件查詢，分頁(yè)查詢和排序功能，基本上相當(dāng)于支持單表的基礎(chǔ)查詢功能了，所以可以簡(jiǎn)單的替代關(guān)系數(shù)據(jù)庫(kù)的很多操作，這也是TC受到大家歡迎的主要原因之一，有一個(gè)Ruby的項(xiàng)目miyazakiresistance將TT的hashtable的操作封裝成和ActiveRecord一樣的操作，用起來(lái)非常爽。 TC/TT在mixi的實(shí)際應(yīng)用當(dāng)中，存儲(chǔ)了2000萬(wàn)條以上的數(shù)據(jù)，同時(shí)支撐了上萬(wàn)個(gè)并發(fā)連接，是一個(gè)久經(jīng)考驗(yàn)的項(xiàng)目。TC在保證了極高的并發(fā)讀寫性能的同時(shí)，具有可靠的數(shù)據(jù)持久化機(jī)制，同時(shí)還支持類似關(guān)系數(shù)據(jù)庫(kù)表結(jié)構(gòu)的hashtable以及簡(jiǎn)單的條件，分頁(yè)和排序操作，是一個(gè)很棒的NoSQL數(shù)據(jù)庫(kù)。 TC的主要缺點(diǎn)是在數(shù)據(jù)量達(dá)到上億級(jí)別以后，并發(fā)寫數(shù)據(jù)性能會(huì)大幅度下降，NoSQL: If Only It Was That Easy提到，他們發(fā)現(xiàn)在TC里面插入1.6億條2-20KB數(shù)據(jù)的時(shí)候，寫入性能開始急劇下降。看來(lái)是當(dāng)數(shù)據(jù)量上億條的時(shí)候，TC性能開始大幅度下降，從TC作者自己提供的mixi數(shù)據(jù)來(lái)看，至少上千萬(wàn)條數(shù)據(jù)量的時(shí)候還沒(méi)有遇到這么明顯的寫入性能瓶頸。 這個(gè)是Tim Yang做的一個(gè)Memcached，Redis和Tokyo Tyrant的簡(jiǎn)單的性能評(píng)測(cè)，僅供參考 3、Flare TC是日本第一大SNS網(wǎng)站mixi開發(fā)的，而Flare是日本第二大SNS網(wǎng)站green.jp開發(fā)的，有意思吧。Flare簡(jiǎn)單的說(shuō)就是給TC添加了scale功能。他替換掉了TT部分，自己另外給TC寫了網(wǎng)絡(luò)服務(wù)器，F(xiàn)lare的主要特點(diǎn)就是支持scale能力，他在網(wǎng)絡(luò)服務(wù)端之前添加了一個(gè)node server，來(lái)管理后端的多個(gè)服務(wù)器節(jié)點(diǎn)，因此可以動(dòng)態(tài)添加數(shù)據(jù)庫(kù)服務(wù)節(jié)點(diǎn)，刪除服務(wù)器節(jié)點(diǎn)，也支持failover。如果你的使用場(chǎng)景必須要讓TC可以scale，那么可以考慮flare。 flare唯一的缺點(diǎn)就是他只支持memcached協(xié)議，因此當(dāng)你使用flare的時(shí)候，就不能使用TC的table數(shù)據(jù)結(jié)構(gòu)了，只能使用TC的key-value數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)。 二、滿足海量存儲(chǔ)需求和訪問(wèn)的面向文檔的數(shù)據(jù)庫(kù)：MongoDB，CouchDB 面向文檔的非關(guān)系數(shù)據(jù)庫(kù)主要解決的問(wèn)題不是高性能的并發(fā)讀寫，而是保證海量數(shù)據(jù)存儲(chǔ)的同時(shí)，具有良好的查詢性能。MongoDB是用C++開發(fā)的，而CouchDB則是Erlang開發(fā)的： 1、MongoDB MongoDB是一個(gè)介于關(guān)系數(shù)據(jù)庫(kù)和非關(guān)系數(shù)據(jù)庫(kù)之間的產(chǎn)品，是非關(guān)系數(shù)據(jù)庫(kù)當(dāng)中功能最豐富，最像關(guān)系數(shù)據(jù)庫(kù)的。他支持的數(shù)據(jù)結(jié)構(gòu)非常松散，是類似json的bjson格式，因此可以存儲(chǔ)比較復(fù)雜的數(shù)據(jù)類型。Mongo最大的特點(diǎn)是他支持的查詢語(yǔ)言非常強(qiáng)大，其語(yǔ)法有點(diǎn)類似于面向?qū)ο蟮牟樵冋Z(yǔ)言，幾乎可以實(shí)現(xiàn)類似關(guān)系數(shù)據(jù)庫(kù)單表查詢的絕大部分功能，而且還支持對(duì)數(shù)據(jù)建立索引。 Mongo主要解決的是海量數(shù)據(jù)的訪問(wèn)效率問(wèn)題，根據(jù)官方的文檔，當(dāng)數(shù)據(jù)量達(dá)到50GB以上的時(shí)候，Mongo的數(shù)據(jù)庫(kù)訪問(wèn)速度是MySQL的10倍以上。Mongo的并發(fā)讀寫效率不是特別出色，根據(jù)官方提供的性能測(cè)試表明，大約每秒可以處理0.5萬(wàn)－1.5次讀寫請(qǐng)求。對(duì)于Mongo的并發(fā)讀寫性能，我（robbin）也打算有空的時(shí)候好好測(cè)試一下。 因?yàn)镸ongo主要是支持海量數(shù)據(jù)存儲(chǔ)的，所以Mongo還自帶了一個(gè)出色的分布式文件系統(tǒng)GridFS，可以支持海量的數(shù)據(jù)存儲(chǔ)，但我也看到有些評(píng)論認(rèn)為GridFS性能不佳，這一點(diǎn)還是有待親自做點(diǎn)測(cè)試來(lái)驗(yàn)證了。 最后由于Mongo可以支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，而且?guī)в袕?qiáng)大的數(shù)據(jù)查詢功能，因此非常受到歡迎，很多項(xiàng)目都考慮用MongoDB來(lái)替代MySQL來(lái)實(shí)現(xiàn)不是特別復(fù)雜的Web應(yīng)用，比方說(shuō)why we migrated from MySQL to MongoDB就是一個(gè)真實(shí)的從MySQL遷移到MongoDB的案例，由于數(shù)據(jù)量實(shí)在太大，所以遷移到了Mongo上面，數(shù)據(jù)查詢的速度得到了非常顯著的提升。 MongoDB也有一個(gè)ruby的項(xiàng)目MongoMapper，是模仿Merb的DataMapper編寫的MongoDB的接口，使用起來(lái)非常簡(jiǎn)單，幾乎和DataMapper一模一樣，功能非常強(qiáng)大易用。 2、CouchDB CouchDB現(xiàn)在是一個(gè)非常有名氣的項(xiàng)目，似乎不用多介紹了。但是我卻對(duì)CouchDB沒(méi)有什么興趣，主要是因?yàn)镃ouchDB僅僅提供了基于HTTP REST的接口，因此CouchDB單純從并發(fā)讀寫性能來(lái)說(shuō)，是非常糟糕的，這讓我立刻拋棄了對(duì)CouchDB的興趣。 三、滿足高可擴(kuò)展性和可用性的面向分布式計(jì)算的數(shù)據(jù)庫(kù)：Cassandra，Voldemort 面向scale能力的數(shù)據(jù)庫(kù)其實(shí)主要解決的問(wèn)題領(lǐng)域和上述兩類數(shù)據(jù)庫(kù)還不太一樣，它首先必須是一個(gè)分布式的數(shù)據(jù)庫(kù)系統(tǒng)，由分布在不同節(jié)點(diǎn)上面的數(shù)據(jù)庫(kù)共同構(gòu)成一個(gè)數(shù)據(jù)庫(kù)服務(wù)系統(tǒng)，并且根據(jù)這種分布式架構(gòu)來(lái)提供online的，具有彈性的可擴(kuò)展能力，例如可以不停機(jī)的添加更多數(shù)據(jù)節(jié)點(diǎn)，刪除數(shù)據(jù)節(jié)點(diǎn)等等。因此像Cassandra常常被看成是一個(gè)開源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java開發(fā)的： 1、Cassandra Cassandra項(xiàng)目是Facebook在2008年開源出來(lái)的，隨后Facebook自己使用Cassandra的另外一個(gè)不開源的分支，而開源出來(lái)的Cassandra主要被Amazon的Dynamite團(tuán)隊(duì)來(lái)維護(hù)，并且Cassandra被認(rèn)為是Dynamite2.0版本。目前除了Facebook之外，twitter和digg.com都在使用Cassandra。 Cassandra的主要特點(diǎn)就是它不是一個(gè)數(shù)據(jù)庫(kù)，而是由一堆數(shù)據(jù)庫(kù)節(jié)點(diǎn)共同構(gòu)成的一個(gè)分布式網(wǎng)絡(luò)服務(wù)，對(duì)Cassandra的一個(gè)寫操作，會(huì)被復(fù)制到其他節(jié)點(diǎn)上去，對(duì)Cassandra的讀操作，也會(huì)被路由到某個(gè)節(jié)點(diǎn)上面去讀取。對(duì)于一個(gè)Cassandra群集來(lái)說(shuō)，擴(kuò)展性能是比較簡(jiǎn)單的事情，只管在群集里面添加節(jié)點(diǎn)就可以了。我看到有文章說(shuō)Facebook的Cassandra群集有超過(guò)100臺(tái)服務(wù)器構(gòu)成的數(shù)據(jù)庫(kù)群集。 Cassandra也支持比較豐富的數(shù)據(jù)結(jié)構(gòu)和功能強(qiáng)大的查詢語(yǔ)言，和MongoDB比較類似，查詢功能比MongoDB稍弱一些，twitter的平臺(tái)架構(gòu)部門領(lǐng)導(dǎo)Evan Weaver寫了一篇文章介紹Cassandra：http://blog.evanweaver.com/artic ... ing-with-cassandra/，有非常詳細(xì)的介紹。 Cassandra以單個(gè)節(jié)點(diǎn)來(lái)衡量，其節(jié)點(diǎn)的并發(fā)讀寫性能不是特別好，有文章說(shuō)評(píng)測(cè)下來(lái)Cassandra每秒大約不到1萬(wàn)次讀寫請(qǐng)求，我也看到一些對(duì)這個(gè)問(wèn)題進(jìn)行質(zhì)疑的評(píng)論，但是評(píng)價(jià)Cassandra單個(gè)節(jié)點(diǎn)的性能是沒(méi)有意義的，真實(shí)的分布式數(shù)據(jù)庫(kù)訪問(wèn)系統(tǒng)必然是n多個(gè)節(jié)點(diǎn)構(gòu)成的系統(tǒng)，其并發(fā)性能取決于整個(gè)系統(tǒng)的節(jié)點(diǎn)數(shù)量，路由效率，而不僅僅是單節(jié)點(diǎn)的并發(fā)負(fù)載能力。 2、Voldemort Voldemort是個(gè)和Cassandra類似的面向解決scale問(wèn)題的分布式數(shù)據(jù)庫(kù)系統(tǒng)，Cassandra來(lái)自于Facebook這個(gè)SNS網(wǎng)站，而Voldemort則來(lái)自于Linkedin這個(gè)SNS網(wǎng)站。說(shuō)起來(lái)SNS網(wǎng)站為我們貢獻(xiàn)了n多的NoSQL數(shù)據(jù)庫(kù)，例如Cassandar，Voldemort，Tokyo Cabinet，F(xiàn)lare等等。Voldemort的資料不是很多，因此我沒(méi)有特別仔細(xì)去鉆研，Voldemort官方給出Voldemort的并發(fā)讀寫性能也很不錯(cuò)，每秒超過(guò)了1.5萬(wàn)次讀寫。 從Facebook開發(fā)Cassandra，Linkedin開發(fā)Voldemort，我們也可以大致看出國(guó)外大型SNS網(wǎng)站對(duì)于分布式數(shù)據(jù)庫(kù)，特別是對(duì)數(shù)據(jù)庫(kù)的scale能力方面的需求是多么殷切。前面我（robbin）提到，web應(yīng)用的架構(gòu)當(dāng)中，web層和app層相對(duì)來(lái)說(shuō)都很容易橫向擴(kuò)展，唯有數(shù)據(jù)庫(kù)是單點(diǎn)的，極難scale，現(xiàn)在Facebook和Linkedin在非關(guān)系型數(shù)據(jù)庫(kù)的分布式方面探索了一條很好的方向，這也是為什么現(xiàn)在Cassandra這么熱門的主要原因。 如今，NoSQL數(shù)據(jù)庫(kù)是個(gè)令人很興奮的領(lǐng)域，總是不斷有新的技術(shù)新的產(chǎn)品冒出來(lái)，改變我們已經(jīng)形成的固有的技術(shù)觀念，我自己（robbin）稍微了解了一些，就感覺(jué)自己深深的沉迷進(jìn)去了，可以說(shuō)NoSQL數(shù)據(jù)庫(kù)領(lǐng)域也是博大精深的，我（robbin）也只能淺嘗輒止，我（robbin）寫這篇文章既是自己一點(diǎn)點(diǎn)鉆研心得，也是拋磚引玉，希望吸引對(duì)這個(gè)領(lǐng)域有經(jīng)驗(yàn)的朋友來(lái)討論和交流。 [ Last edited by yalefield on 2012-7-27 at 09:34 ] |
2樓2012-07-27 09:32:04
相關(guān)版塊跳轉(zhuǎn)
我要訂閱樓主 mingyue8608 的主題更新
| 4 | 1/1 | 返回列表 |
| 最具人氣熱帖推薦 [查看全部] | 作者 | 回/看 | 最后發(fā)表 | |
|---|---|---|---|---|
|
[考研] 306求0703調(diào)劑一志愿華中師范 +8 | 紙魚ly 2026-03-21 | 9/450 |
|
|---|---|---|---|---|
|
|
[考研] 一志愿南航材料專317分求調(diào)劑 +4 | 炸呀炸呀炸薯?xiàng)l 2026-03-23 | 4/200 |
|
|
|
[考研] 299求調(diào)劑 +5 | 某某某某位 2026-03-21 | 5/250 |
|
|
|
[考研] 361求調(diào)劑 +3 | Glack 2026-03-22 | 3/150 |
|
|
|
[考研] 265求調(diào)劑 +10 | 梁梁校校 2026-03-17 | 10/500 |
|
|
[考研] 一志愿上海交大生物與醫(yī)藥專碩324分，求調(diào)劑 +5 | jiajunX 2026-03-22 | 5/250 |
|
|
|
[考研]
 材料與化工考研調(diào)劑
+4
|
孅華 2026-03-22 | 4/200 |
|
|
|
[考研] 298求調(diào)劑 +8 | 上岸6666@ 2026-03-20 | 8/400 |
|
|
|
[考研]
求調(diào)劑材料學(xué)碩080500，總分289分
 5+3
|
@taotao 2026-03-19 | 21/1050 |
|
|
|
[考研] 尋找調(diào)劑 +4 | 倔強(qiáng)芒? 2026-03-21 | 4/200 |
|
|
|
[考研] 319求調(diào)劑 +4 | 小力氣珂珂 2026-03-20 | 4/200 |
|
|
|
[考研] 286求調(diào)劑 +10 | Faune 2026-03-21 | 10/500 |
|
|
|
[考研] 280求調(diào)劑 +11 | 咕嚕曉曉 2026-03-18 | 12/600 |
|
|
|
[考研] 求調(diào)劑 +3 | 13341 2026-03-20 | 3/150 |
|
|
|
[考研] 材料 271求調(diào)劑 +5 | 展信悅_ 2026-03-21 | 5/250 |
|
|
|
[考研] 085601調(diào)劑 358分 +3 | zzzzggh 2026-03-20 | 4/200 |
|
|
|
[考研] 085700資源與環(huán)境308求調(diào)劑 +12 | 墨墨漠 2026-03-18 | 13/650 |
|
|
|
[考研] 考研調(diào)劑求學(xué)校推薦 +3 | 伯樂(lè)29 2026-03-18 | 5/250 |
|
|
|
[考研] 招收調(diào)劑碩士 +4 | lidianxing 2026-03-19 | 12/600 |
|
|
|
[考研] 考研求調(diào)劑 +3 | 橘頌. 2026-03-17 | 4/200 |
|