nosql為什么比sql快

因為索引多。同一條個數(shù)據(jù)，NOSQL占用空間是一般SQL數(shù)據(jù)庫的3-5倍。

公司主營業(yè)務：網(wǎng)站設計制作、網(wǎng)站建設、移動網(wǎng)站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)公司是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)公司推出八宿免費做網(wǎng)站回饋大家。

你可以理解成NOSQL默認開啟全字段索引和全文索引什么的。

其實在十萬級以下的數(shù)據(jù)，只要SQL建好索引的情況并不比NOSQL慢。NOSQL主要是用于千萬上億級的時候。

NoSQL應用

而傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，例如：

1、High performance - 對數(shù)據(jù)庫高并發(fā)讀寫的需求

web2.0網(wǎng)站要根據(jù)用戶個性化信息來實時生成動態(tài)頁面和提供動態(tài)信息，所以基本上無法使用動態(tài)頁面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫并發(fā)負載非常高，往往要達到每秒上萬次讀寫請求。關系數(shù)據(jù)庫應付上萬次SQL查詢還勉強頂?shù)米。菓渡先f次SQL寫數(shù)據(jù)請求，硬盤IO就已經(jīng)無法承受了。其實對于普通的BBS網(wǎng)站，往往也存在對高并發(fā)寫請求的需求。

2、Huge Storage - 對海量數(shù)據(jù)的高效率存儲和訪問的需求

對于大型的SNS網(wǎng)站，每天用戶產(chǎn)生海量的用戶動態(tài)，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態(tài)，對于關系數(shù)據(jù)庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動輒數(shù)以億計的帳號，關系數(shù)據(jù)庫也很難應付。

3、High Scalability High Availability- 對數(shù)據(jù)庫的高可擴展性和高可用性的需求

在基于web的架構(gòu)當中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候，你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫不能通過不斷的添加服務器節(jié)點來實現(xiàn)擴展呢？

在上面提到的“三高”需求面前，關系數(shù)據(jù)庫遇到了難以克服的障礙，而對于web2.0網(wǎng)站來說，關系數(shù)據(jù)庫的很多主要特性卻往往無用武之地，例如：

1、數(shù)據(jù)庫事務一致性需求

很多web實時系統(tǒng)并不要求嚴格的數(shù)據(jù)庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數(shù)據(jù)庫事務管理成了數(shù)據(jù)庫高負載下一個沉重的負擔。

2、數(shù)據(jù)庫的寫實時性和讀實時性需求

對關系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對于很多web應用來說，并不要求這么高的實時性。

3、對復雜的SQL查詢，特別是多表關聯(lián)查詢的需求

任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的復雜SQL報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設計角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

因此，關系數(shù)據(jù)庫在這些越來越多的應用場景下顯得不那么合適了，為了解決這類問題的非關系數(shù)據(jù)庫應運而生。

NoSQL 是非關系型數(shù)據(jù)存儲的廣義定義。它打破了長久以來關系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲不需要固定的表結(jié)構(gòu)，通常也不存在連接操作。在大數(shù)據(jù)存取上具備關系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢。該術(shù)語在 2009 年初得到了廣泛認同。

當今的應用體系結(jié)構(gòu)需要數(shù)據(jù)存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現(xiàn)這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現(xiàn)。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。

為什么使用nosql

因為速度快。你上億級數(shù)據(jù)的情況下NOSQL是比普通SQL效率更高，哪怕有索引。畢竟NOSQL的存儲空間使用是普通SQL三倍多?；径加迷谒饕矫媪恕?/p>

如果是全文搜索關鍵字，左右模糊等就更甩SQL幾條街了

sql 與nosql哪個查詢效率更高

nosql速度快，但是完成不了關系數(shù)據(jù)庫的復雜邏輯

sql功能強大，但是效率上有瓶頸

看項目大小取舍

elasticsearch可以代替NoSQL嗎

我們使用Elasticsearch存儲的文檔數(shù)量接近50億（算上1份復制，接近100億文檔），總共10個數(shù)據(jù)節(jié)點和2個元數(shù)據(jù)節(jié)點（48GB內(nèi)存，8核心CPU，ES使用內(nèi)存達到70%），每天的文檔增量大概是3000W條（速度持續(xù)增加中）。目前來看，單個文檔的查詢效率基本處于實時狀態(tài)；對于1到2周的數(shù)據(jù)的聚合統(tǒng)計操作也可以在10秒之內(nèi)返回結(jié)果。

但是，還有提升的空間：

1. 對于查詢單條數(shù)據(jù)的應用場景來說，我們可以使用ES的路由機制，將同一索引內(nèi)的具有相同特征（比如具有相同的userid）的文檔全部存儲于一個節(jié)點上，這樣我們之后的查詢都可以直接定位到這個節(jié)點上，而不用將查詢廣播道所有的節(jié)點上；

2. 隨著數(shù)據(jù)節(jié)點的增加，適當增加分片數(shù)量，提升系統(tǒng)的分布水平，也可以通過分而治之的方式優(yōu)化查詢性能；

個人以為Elasticsearch作為內(nèi)部存儲來說還是不錯的，效率也基本能夠滿足，在某些方面替代傳統(tǒng)DB也是可以的，前提是你的業(yè)務不對操作的事性務有特殊要求；而權(quán)限管理也不用那么細，因為ES的權(quán)限這塊還不完善。由于我們對ES的應用場景僅僅是在于對某段時間內(nèi)的數(shù)據(jù)聚合操作，沒有大量的單文檔請求（比如通過userid來找到一個用戶的文檔，類似于NoSQL的應用場景），所以能否替代NoSQL還需要各位自己的測試。如果讓我選擇的話，我會嘗試使用ES來替代傳統(tǒng)的NoSQL，因為它的橫向擴展機制太方便了。

NoSQL在少量數(shù)據(jù)的存儲上，與傳統(tǒng)關系型數(shù)據(jù)庫相比有什么劣勢嗎？

個人不認為nosql在少量數(shù)據(jù)存儲上有啥優(yōu)勢。nosql主要解決的是auto sharding的問題,你不需要sharding,搞啥nosql. 作者：方圓 鏈接：