NoSQL層出不窮,各種NOSQL產(chǎn)品的比較和優(yōu)劣勢討論

liklstar

回復(fù) 4# lyhabc


   
什么意思？你是說Tair是阿里巴巴（淘寶是阿里巴巴旗下的嗎？它跟阿里巴巴是什么關(guān)系？我不太知道？）的技術(shù)團(tuán)隊(duì)根據(jù)市場需要創(chuàng)造性地形成產(chǎn)品概念、探索出產(chǎn)品開發(fā)和運(yùn)行的概念和原理、之后又獨(dú)立地設(shè)計(jì)了產(chǎn)品并實(shí)現(xiàn)之，最后成功應(yīng)用嗎？

如果是這樣的話，那就太好了？！

liklstar

回復(fù) 10# SeAL80s


   
其實(shí)，創(chuàng)新并不“難”？！并不一定需要豐富大量的知識和技能？！關(guān)鍵是具有一定知識和基礎(chǔ)的人（學(xué)校、老師、學(xué)生、科研人員、工程師）要緊密聯(lián)系實(shí)際、聯(lián)系市場、根據(jù)市場和技術(shù)自身發(fā)展的需要通過研究、開發(fā)合適的產(chǎn)品來完成科研和學(xué)習(xí)。否則，科研和研發(fā)就是無源之水、無本之木了？！廣泛、大量、全面地學(xué)習(xí)，對于學(xué)生來說，當(dāng)然有好處。但是，不能為了學(xué)習(xí)而學(xué)習(xí)，或者至少是不能總是、長期是為了學(xué)習(xí)而學(xué)習(xí)。而要針對市場需要、科學(xué)技術(shù)自身發(fā)展的需要，以此為中心，展開研究和學(xué)習(xí)。只有這樣才能真正把聰明才智轉(zhuǎn)化為生產(chǎn)力，也才能賺錢、賺大錢，之后再大規(guī)模地投入科研和學(xué)習(xí)？！

我覺得我們最大的問題在于學(xué)校與市場嚴(yán)重脫鉤、學(xué)生的學(xué)習(xí)與市場完全脫鉤？！就比如：RISC的創(chuàng)始人Hennesy和Patterson就是從學(xué)校出來，帶著研究成果辦公司，又從公司回到學(xué)校搞科研。

liklstar

我就想問一問我們的工程師們：我們能不能下定決心，花一年、三年、五年的時(shí)間，不吃不喝，瞄準(zhǔn)數(shù)據(jù)庫或操作系統(tǒng)中的一個(gè)，搞一個(gè)出來？不管它一開始有多“丑”？

laputa73

國產(chǎn)的文檔數(shù)據(jù)庫有sequoiaDB啊，和mongodb兼容，但是性能好很多。
mongodb更像DB,是因?yàn)樗�不僅支持KV,還支持按文檔的field索引。基本上可以等效于一個(gè)單表的mysql.
但是nosql數(shù)據(jù)庫的通用短板，就是對join的支持不好。mongodb也不例外。這個(gè)是它的原理決定的。

redis我們也叫他內(nèi)存數(shù)據(jù)庫，同時(shí)還支持持久化。但是它的功能確實(shí)太有限了�；�本就就限于二級的key+field索引。數(shù)據(jù)類型有限。
redis對應(yīng)的國內(nèi)改良品也有SSDB.可以支持主主集群，而且容量10倍。可惜性能也隨之下降很多。

memcache就更只有KV了。

lyhabc

@laputa73
總結(jié)得不錯  

cjfeii

占個(gè)樓先。

will009

回復(fù) 13# liklstar

你提出來的觀點(diǎn)令人深思，我覺得這牽涉到很多東西，比如教育、社會風(fēng)氣等等，研發(fā)操作系統(tǒng)和數(shù)據(jù)庫還需要走一段很長的路。


   

jieforest

其實(shí)，我們看過了外國人的代碼和文檔后覺得不過如此。那為什么我們就創(chuàng)造不出這樣的文檔和代碼呢？

真心不同意，你看了哪些項(xiàng)目的源碼和文檔？真正廣為流行的開源項(xiàng)目，代碼質(zhì)量都非常高，文檔未必詳細(xì)，但是代碼都很不錯。像Redis之類的源碼，里面蘊(yùn)含了很多富有創(chuàng)新性的技術(shù)和思想。我感覺“不過如此”這句話有點(diǎn)自大。

sjf0115

回不了呢                     

sjf0115

1.redis memcached 等和mongodb哪個(gè)更像DB？說明原因。

關(guān)系型數(shù)據(jù)庫已不能承受t級別，甚至pt級別的任務(wù)。nosql這時(shí)候就能起到作用。
nosql流行的原因是為了性能，不得不犧牲使用的復(fù)雜性。

2.大家一般把redis用在什么場景？mongodb用在什么場景？

（1）Redis
最佳應(yīng)用場景：適用于數(shù)據(jù)變化快且數(shù)據(jù)庫大小可遇見（適合內(nèi)存容量）的應(yīng)用程序。
例如：股票價(jià)格、數(shù)據(jù)分析、實(shí)時(shí)數(shù)據(jù)搜集、實(shí)時(shí)通訊。
（2）Mongodb
最佳應(yīng)用場景：        適用于需要動態(tài)查詢支持；
                                需要使用索引而不是 map/reduce功能；
                                需要對大數(shù)據(jù)庫有性能要求；
                                需要使用 CouchDB但因?yàn)閿?shù)據(jù)改變太頻繁而占滿內(nèi)存的應(yīng)用程序。
例如：你本打算采用 MySQL或 PostgreSQL，但因?yàn)樗鼈儽旧碜詭У念A(yù)定義欄讓你望而卻步。

3.mongodb和redis memcached等其他nosql產(chǎn)品相比哪個(gè)更有優(yōu)勢？

這是三個(gè)場景不同的產(chǎn)品，沒有可比性，每一種非關(guān)系數(shù)據(jù)庫都有它自己的適用場景，都有它自己的獨(dú)特優(yōu)勢。
mongodb是文檔型的非關(guān)系型數(shù)據(jù)庫，其優(yōu)勢在于查詢功能比較強(qiáng)大，能存儲海量數(shù)據(jù)。
memcached和redis比較接近。它們都是內(nèi)存型數(shù)據(jù)庫，數(shù)據(jù)保存在內(nèi)存中，通過tcp直接存取，優(yōu)勢是速度快，并發(fā)高，缺點(diǎn)是數(shù)據(jù)類型有限，查詢功能不強(qiáng)，一般用作緩存。


4.大家覺得mongodb和redis ，mencached 等其他nosql產(chǎn)品會融合嗎？因?yàn)榇蠹叶际莕osql方面的產(chǎn)品，功能相似，應(yīng)用場景都差不多。如果不會融合，說說為何不會融合的理由。

本人覺得不會融合。它們被開發(fā)出來是各自針對特定的領(lǐng)域和場景進(jìn)行設(shè)計(jì)的，它們各自都有自身的優(yōu)勢和缺點(diǎn)，不具可比性。
不會開發(fā)出一個(gè)功能齊全，可以適用于所有場景的一個(gè)產(chǎn)品，過分請求完美的產(chǎn)品必定是失敗的產(chǎn)品，只要針對特定場景完美解決的就是成功的產(chǎn)品。
在項(xiàng)目應(yīng)用中各個(gè)產(chǎn)品的組合使用是正確的選擇，各個(gè)nosql產(chǎn)品組合使用，nosql也可以和傳統(tǒng)數(shù)據(jù)庫組合使用，發(fā)揮每個(gè)產(chǎn)品的最大價(jià)值。
同樣，我們可以想象一下關(guān)系型數(shù)據(jù)庫為什么沒有出現(xiàn)一個(gè)融合的產(chǎn)品呢？

5.學(xué)習(xí)mongodb和學(xué)習(xí)redis，mencached哪個(gè)更有優(yōu)勢？

可以對這些都進(jìn)行了解，但是還是要根據(jù)實(shí)際使用過程中的場景來決定選型。
mongodb為代表的nosql應(yīng)該是傳統(tǒng)數(shù)據(jù)庫的有益的補(bǔ)充，較適合web端快速開發(fā)。
redis 和 memcache 都是好的緩存方案，各有各的優(yōu)缺點(diǎn)著作權(quán)歸作者所有。
redis 是分布式的數(shù)據(jù)結(jié)構(gòu)服務(wù)器，功能上覆蓋了memcached, 可以代替memcached.
當(dāng)然memcached也有優(yōu)勢，memcached是多線程的，這樣可以充分利用多核能力。redis是單核，要想在那么多數(shù)據(jù)結(jié)構(gòu)基礎(chǔ)上支持多線程，光加鎖就會讓人瘋掉，性能也會下降。