到現在為止，NoSQL運動給資料庫系統留下什麼寶貴的思想？

01-14

NoSQL運動應該說是已經進入了尾聲，有必要回顧NoSQL運動給我們帶來了哪些有價值的思想，對於資料庫、NewSQL和分散式系領域什麼啟示，以及被借鑒的具體的技術。

關係型資料庫是在完全不知道應用將會如何存儲/查詢數據的情況下，設計的數據存儲/查詢/統計通用解決方案。

而所謂的NoSQL運動，是人們慢慢發現，他們沒有什麼不可預測的查詢和統計需求，只是想找個地方存狀態而已。這時候關係型資料庫就不再是最優解了，當在設計軟體的過程中，可以完全確定數據的存儲方式，以及查詢行為，就可以放棄關係型資料庫改用K-V來存儲可以提高效率，減少不必要的限制。

現在關係型資料庫現在還活得好好的，oracle依然賣那麼貴。因為複雜的需求總是有的，不可預知的查詢和統計是不可避免的。

怎麼就尾聲了？Nosql強盜團伙生生從關係型資料庫一統天下的局面里撕下一大塊肉，這些年Nosql提供了前所未有的scalability能力和可用性，在超大並發情況下，我個人經驗是基於Nosql的系統比基於關係型資料庫痛苦少些。在Nosql架構中，不同節點之間不「share」數據，每個節點只要管自己那一畝三分地就好，你可以非常容易的把數據分布到成千上萬的伺服器上，讀和寫都更容易搞，一小部分節點「壞」了，也不容易讓你的服務完全跪了，你也比較容易替換，各種姿勢做rolling restart。Mysql當然也能sharding，提供的功能是一樣一樣的，不過你分開之後這個sql查詢可就受限制了，要不代價更大。

有人說MongoDB，Cassandra有問題。MongoDB提供了非常rich的數據模型，還有secondary index，這是好事，但也一定程度造成了它的replica就沒那麼好，和mysql的master/slave模型很像，很多問題都是停電或者重啟後，mongodb master/slave切換造成的，嚴重影響了可用性。 Cassandra的可用性就好很多，的確量大了也出問題，不過真到了那個量，你用Mysql也得優化，要不也得跪，我覺得只會跪的更早，很多一線互聯網公司（比如說fb，阿里）對Mysql都有自己獨到的使用方式，不是我瞧不起人，一般人用mysql，量一大就跪。

現在我們來看Mysql等，自動sharding或者說auto-scale是有各種解決方案了，不過這是落後一步的，MongoDB等nosql是提前三到五年就玩的轉了。這些年，Nosql團伙是逼著Mysql和Oracle在scalebility方面不斷改革。

另一方面，也出現了Newsql這個這種方案，鑒於Nosql分散式存儲的優勢，newsql的底層還是Nosql那種，頂層又要和sql兼容，那中間就需要一個對用戶透明的自動sharding層。這玩意能做到多好，如何優化，就具體項目具體對待了。

從系統設計方面來說，新近的互聯網項目，就算你要用mysql（其實我個人也推薦過一些小公司，根據自己團隊的情況，就直接使用mysql來代替過於fancy的nosql資料庫，簡單實用，招人容易），但也是按照Nosql的很多思路去設計表結構，要不你在sharding方面就會舉步維艱，等數據量和訪問量一大，你這系統就得扔了。

最寶貴的思想就是慎用縮寫。

中國起碼有一半嘴上天天掛著NoSQL的人，腦子裡，說起來都是 No SQL。

其實他是 Not Only SQL 的縮寫。

個人來說，最大的經驗是：產品好固然重要，生態決定一切

這個生態包括已有系統構架，運維複雜程度，開發人員是否容易找，文檔是否豐富等多個方面。

SQL生態在上面幾個方面可以秒殺任何NoSQL生態，開發上手的容易程度都是不容置疑的。

對於NoSQL生態，這幾個方面考慮完備之後，我個人有限的知識體系裡面暫時只有Redis和Elasticsearch (後者嚴格說來都不算資料庫）可以達到上面幾個標準。其他動不動上Zookeeper的資料庫你們好意思說你們好入門，為了介紹那你們我得專門寫一章節介紹怎麼配置zookeeper，這樣很浪費知道嗎？

看過太多的實戰例子，開始急吼吼的上NoSQL，後來發現原來只需要做一下secondary indexing或者sharding，以前的SQL資料庫能繼續跑的風生水起。有些非谷歌搜索引擎公司內部一個功能部門就有5個以上的自主開發的特殊應用場景專用鍵值資料庫，人家有錢知道嗎？畢竟，大數據是有錢人的遊戲，有錢可以用月球當硬碟，沒錢就好好調參數啦

給我帶來了無盡的災難，特別是15年公司代理英國開發商的賽車聯盟，英國佬居然用的資料庫是mongodb，老是事務不一致，噁心死了

當然慶幸的是，第一輪公測就黃了

NoSQL壓根就不是SQL型資料庫之後才出現的東西，SQL的出現本身就是對幾十年前的NoSQL的革新。

壓根就不是什麼新鮮玩意和技術，只是分散式系統火了之後NoSQL在某些特定場合使用比SQL合適而已。而且分散式系統也不是非得用nosql不可，看看facebook是怎麼用 mysql玩出花來的.

進入了尾聲是什麼意思？我發現國內特別喜歡什麼互聯網下半場之類的說辭，這都nosql尾聲了....

MongoDB這兩年出的問題少么....?

firebase這種解決方案有幾個複雜系統在用?

說 NoSQL 運動尾聲並不那麼確切。一方面，關係型資料庫一直堅挺，說去 IOE 也是換成 MySQL 或者 PostgreSQL 而不是 NoSQL。NoSQL 方面（問題看不出來 NoSQL 已成主流的意思，姑且認為說 NoSQL 要完），以 HBase 為例，從 HBase 的 github 頁面來看，好吧， Ted Yu 的名字確實不新鮮，但那些數字並沒有給人日薄西山的感覺。從用戶方面看，國內 BAT、小米、華為、網易、京東、滴滴、攜程、新浪、知乎等大大小小的公司都有部署 HBase，集群規模幾百、幾千、上萬台不等，承載的包括用戶畫像、安全風控、訂單存儲、交通軌跡、推薦搜索等業務（HBaseCon Asia 2017 觀察）。

回頭來說，資料庫終究是要滿足數據的管理和存儲的需求，NoSQL 因關係模型當初不能很好地適應海量數據存儲和管理而生，它去掉了關係型特性，支持分散式存儲，甚至自動分片，擴展和並發能力強，在庫表結構簡單的互聯網業務上表現很好。然而業務需求複雜之後，遵循 CAP 理論和 BASE 原則的NoSQL，對 ACID 和 SQL 支持不佳等短板讓人不能忍，它需要用戶精通數據存儲引擎，事務又是渣渣。所以 Google F1、TiDB 之類的 NewSQL 出來了，支持分散式、高容錯、基於雲的集群架構，支持關係數據模型，支持使用 SQL 語句來查詢數據。當然，NewSQL 是很不好搞的。

其實，關係型資料庫在海量數據存儲和查詢方面做了不少的探索，業務拆分、分庫分表已經不是什麼新聞。但在一些需求簡單的場景下，關係庫性能還是不如 NoSQL。正確的廢話，就是還需要根據業務場景來選擇。

利益相關：網易雲在 RDS之外，也提供 MongoDB、Redis 等雲服務。

nosql為了擴展性作了優化的限制, 不提供join,sort,conut等操作，提供基於分區分布，最終一致的全局二級索引，這些在大數據量下本來就需要從新設計的，db搞不定。但對於介面形式以及單分區下的事務，nosql應吸拿sql的優式，所以有了newsql。

越發覺得現在的資料庫更重要的功能是存儲，而不是關係。也不知道是不是理解有偏差，希望大佬們指點。

NoSQL 並沒有像標題所 imply 的一樣死掉了，它不是留下了什麼，而是正在改變我們對數據存儲和業務建模的觀念。但這個進程顯得不快，主要是兩方面的原因，一是多年來大量開發者對於關係數據的理解和使用造成大家對於採用 NoSQL 順利而流暢的進行建模還顯得很陌生；二是 NoSQL 社區本身的問題，主要集中在數據一致性問題上。就我們公司本身的經驗來說，採用的是我們自研的 NoSQL 資料庫，極大提高了系統吞吐性能，建模方面也顯得非常的直接簡潔。我們公司已經全面採用 NoSQL 而不會再在關係資料庫上下功夫。

殺雞焉用牛刀

石頭砸也是可以的……

題主提到的NoSQL運動這個名詞最早出現在2010年CSDN上的兩篇文章

NOSQL運動：一場技術多元化的演進-CSDN.NET

CouchDB退出，NoSQL運動開始分崩離析？-CSDN.NET

這種叫法實際上更多的是帶有一些調侃的韻味，並不正宗。任何一種資料庫的作用都要放到業務場景下去談才有意義。

比如redis，現在很多系統中都會用來做數據緩存，減少業務主庫的查詢量，防止業務庫被穿透。

mongodb可以用在關係性不強，但是欄位層級較多的業務場景。比如：

{

"a":{"m":1,"n":{"o":2}},

"b":3

}

下面這個層層嵌套的json結構如果存儲在mysql中就比較麻煩，而存儲在mongodb中無論是查詢還是插入都簡單了很多。

但是nosql也有他的局限，在這裡我舉兩個不適合nosql資料庫的場景：

1.對事務要求較高的場景。

2.多表關聯查詢大數據量統計。

mysql並沒有那麼好，nosql用起來真是簡單

不存在nosql運動 mysql 一直都可以做nosql 使用 nosql 為什麼火本質是因為 1. mysql資料缺乏 2.行業故意壟斷了關鍵技術 3.代碼龐大，不是資料庫相關開發工作看不懂，就算要看也無從下手 5. 多線程代碼坑多需要具備良好資料庫原理，分散式，網路編程，存儲引擎 c 數據結構很紮實基礎 6.沒有mysql 開源相關精簡極致帶完整注釋代碼（比如陳碩 muduo linux c++ 多線程編程） 7. 大部分人基礎差不懂mysql 原理總覺得慢，喜歡信仰斗單機 8. 覺得mysql，拆表拆庫設計架構難度集群主從不好用寫sql 又臭又長。

nosql 對newsql 沒啥借鑒的