nosql現在很火很時髦，大家言必稱nosql，彷彿關係型資料庫已成陳舊落後的代名詞。
但依我看，真正理解nosql的還不多，在實際專案中用過的應該就更少了。
我也還不理解，更沒怎麼應用過，所以現在要努力學習。
在學習過程中，常看到有吹噓nosql相比較關係型資料庫而言，有乙個優點是：易擴充套件。
這怎麼理解呢？絕大部分的資料都沒怎麼講，一味唾沫橫飛地說：易擴充套件、高效能，高可用。。。
我看了一點mongodb官網的文件，再結合自己的理解，解讀如下：
nosql的易擴充套件性：
關係型資料庫的表之間，具有關聯性，查詢的時候往往需要join，因此所有的表需要存放在同一臺伺服器裡。所以有人說（**的資料庫專家），目前的關係型資料庫本質上是乙個單機系統，而不是分布式的。
但nosql就不同了：
1、表之間並沒有什麼關係（？），放哪都一樣，特別適合分布式儲存。
2、根據cap理論，分布式系統中，一致性，可用性，分割槽容錯性三者至多只能滿足其二，nosql犧牲了一致性，各個副本之間，僅追求的是最終一致性，這樣也有利於分布式儲存。
所以說它有好的擴充套件性（橫向擴充套件）。
架構 擴充套件性
擴充套件選和伸縮性 擴充套件性 指對現有系統影響最小的情況下，系統功能可持續擴充套件或提公升的能力。表現在系統基礎設施穩定不需要經常變更，應用之間較少依賴和耦合，對需求變更可以敏捷響應。它是系統架構設計層面的開閉原則 對擴充套件開放，對修改關閉 架構設計考慮未來功能擴充套件，當系統增加新功能時，不需...
CSS可擴充套件性
今日在寫pc官網的時候，一直對於html css的結構編寫完全按照自己的思維方式，今天把 交給老大的時候，被他指出很多編寫 的錯誤性，比如 結構，標籤的使用，語義化，css的可擴充套件性，由於 主要還是需要做seo優化，所以在標籤使用上也有些不合理之處，給了我一些建議，自己記錄以下 1 在html標...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...