SQL到NOSQL的思維轉變的具體分析

　　1, 索引支持。關系型數據庫創立之初沒有想到今天的互聯網應用對可擴展性提出如此高的要求，因此，設計時主要考慮的是簡化用戶的工作，SQL語言的產生促成數據庫接口的標準化，從而形成了Oracle這樣的數據庫公司并帶動了上下游產業鏈的發展。關系型數據庫在單機存儲引擎支持索引，比如Mysql的Innodb存儲引擎需要支持索引，而NOSQL系統的單機存儲引擎是純粹的，只需要支持基于主鍵的隨機讀取和范圍查詢。NOSQL系統在系統層面提供對索引的支持，比如有一個用戶表，主鍵為user_id，每個用戶有很多屬性，包括用戶名，照片ID(photo_id)，照片URL，在NOSQL系統中如果需要對photo_id建立索引，可以維護一張分布式表，表的主鍵為

　　2, 事務并發處理。關系型數據庫有一整套的關于事務并發處理的理論，比如鎖的粒度是表級，頁級還是行級，多版本并發控制機制MVCC，事務的隔離級別，死鎖檢測，回滾，等等。然而，互聯網應用大多數的特點都是多讀少些，比如讀和寫的比例是10 : 1，并且很少有復雜事務需求，因此，一般可以采用更為簡單的copy-on-write技術：單線程寫，多線程讀，寫的時候執行copy-on-write，寫不影響讀服務。NOSQL系統這樣的假設簡化了系統的設計，減少了很多操作的overhead，提高了性能。

　　3, 動態還是靜態的數據結構。關系型數據庫的存儲引擎總是一顆磁盤B+樹，為了提高性能，可能需要有insert buffer聚合寫，query cache緩存讀，經常需要實現類似Linux page cache的緩存管理機制。數據庫中的讀和寫是互相影響的，寫操作也因為時不時需要將數據flush到磁盤而性能不高。簡而言之，關系型數據庫存儲引擎的數據結構是通用的動態更新的B+樹，然而，在NOSQL系統中，比如Bigtable中采用SSTable + MemTable的數據結構，數據先寫入到內存的MemTable，達到一定大小或者超過一定時間才會dump到磁盤生成SSTable文件，SSTable是只讀的。如果說關系型數據庫存儲引擎的數據結構是一顆動態的B+樹，那么SSTable就是一個排好序的有序數組。很明顯，實現一個有序數據比實現一個動態B+樹且包含復雜的并發控制機制要簡單高效地多。

　　4, Join操作。關系型數據庫需要在存儲引擎層面支持Join，而NOSQL系統一般根據應用來決定Join實現的方式。舉個例子，有兩張表：用戶表和商品表，每個用戶下可能有若干個商品，用戶表的主鍵為

　　關系型數據庫的性能瓶頸往往不在SQL語句解析上，而是在于需要支持完備的SQL特性?；ヂ摼W公司面臨的問題是應用對性能和可擴展性要求很高，并且DBA和開發工程師水平比較高，可以通過犧牲一些接口友好性來換取更好的性能。NOSQL系統的一些設計，比如通過寬表實現Join操作，互聯網公司的DBA和開發工程師也做過，NOSQL系統只是加強了這種約束。從長遠來看，可以總結一套約束集合，并且定義一個SQL子集，只需要支持這個SQL子集就可以在不犧牲可擴展性的前提下支持比如90%以上的互聯網應用。我想，NOSQL技術發展到這一步的時候就算是比較成熟了，這也是我們最終想做的事情。我們在設計和使用NOSQL系統的時候也可以適當轉化一下思維，如下：

　　1, 更大的數據量。很多人在使用Mysql的過程遇到記錄條數超過一定值，比如2000W的時候，數據庫性能開始下降，這個值的得出往往需要經過大量的測試。然而，大多數的NOSQL系統可擴展性都比較好，能夠支持更大的數據量，因此也可以采用一些空間換時間的做法，比如通過寬表的方式實現Join。

　　2, 性能預估更加容易。關系型數據庫由于復雜的并發控制，insert buffer及類似page cache的讀寫優化機制，性能估算相對較難，很多時候需要憑借經驗或者經過測試才能得出系統的性能。然后，NOSQL系統由于存儲引擎實現，并發控制機制等相對簡單，可以通過硬件的性能指標在系統設計之處大致預估系統的性能，性能預估可操作性相對更強

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com