其實說白了，這些都是事先沒有認清的最重要的東西。從系統架構來看，互聯網應用更註重系統性能和可擴展性，傳統企業應用更註重數據完整性和數據安全性。然後再來說說互聯網應用的可擴展性。為了可擴展性，我還寫了幾篇博文。想看的兄弟可以參考我之前的博文。對於web server，app server的可擴展性，這裏暫時不談，因為這部分可擴展性相對容易。我將主要回顧壹個緩慢增長的互聯網應用程序如何響應數據庫層的可伸縮性。
首先，剛開始的時候，人不多，壓力也不大。只需設置壹個數據庫服務器。這時候所有東西都塞進壹個服務器，包括web服務器，app服務器，db服務器。但是人越來越多，系統壓力越來越大。此時，您可以將Web服務器、應用服務器和數據庫服務器分開。至少可以應付壹段時間，但是隨著用戶越來越多，妳會發現數據庫哥們快不行了，速度總是很慢，有時候還會掉下來，所以這個時候，妳就要給數據庫哥們找壹些夥伴了。這時，主人出現了。此時，壹個主服務器負責接收寫操作，其他幾個從服務器專用於讀操作。就這樣，大師終於不抱怨了，終於把閱讀和寫作分開了，終於緩解了壓力。此時主要是橫向擴展讀取操作，通過添加多個從機克服CPU瓶頸。壹般妳的系統可以應付壹定的壓力，但是隨著用戶數量的增加，壓力越來越大，妳會發現主服務器的寫壓力還是太大，沒有辦法。這時候我該怎麽辦？妳要拆分，俗話說“只有拆分才有伸縮性”，所以這個時候，妳只能拆分數據庫，也就是我們常說的數據庫“垂直拆分”，比如把壹些不相關的數據存儲在不同的數據庫中，分別部署，這樣妳終於可以帶走壹部分讀寫壓力，高手可以稍微放松壹下，但是隨著數據的不斷增加，妳的數據庫表中的數據就變得千差萬別了。這樣查詢效率很低。這時候就需要“橫向分區”了，比如把用戶表中的數據按照10W劃分，這樣每個表就不會超過10W。
綜上所述，壹個流行的網站會經歷壹個從單DB到主從復制，到垂直分區，再到水平分區的痛苦過程。其實數據庫分段的原理看起來很簡單。如果真的做到了，我想所有在分片中有過數據庫的哥們都會大受其害。關於數據庫擴展的文章，哥們可以看看後面的資源介紹。
好吧，從上面的廢話中，我們也發現把規模擴大到數據庫存儲層面之外是多麽痛苦的事情，不過好在技術在進步，業內其他兄弟也在努力。在2009年，有很多NoSQL數據庫，或者更準確地說，沒有關系數據庫。這些數據庫大多會為非結構化數據提供透明的橫向擴展能力，大大減輕友商的設計壓力。我就把Hbase當做壹個分布式列存儲系統吧。
什麽是Hbase？
在說Hase是誰之前，我們先來看兩個概念，面向行存儲和面向列存儲。面向行的存儲，相信大家都應該知道，我們熟悉的RDBMS就是這種類型。面向行存儲的數據庫主要適用於事務性要求嚴格的場合，或者面向行存儲的存儲系統適用於OLTP。然而，根據CAP理論，為了實現強壹致性，傳統的RDBMS通過嚴格的ACID事務進行同步，這大大降低了系統的可用性和可擴展性。目前，許多NoSQL產品，包括Hbase，最終都是壹致的系統，它們為了高可用性犧牲了壹些壹致性。好像上面說的是列向存儲，那麽到底什麽是列向存儲呢？Hbase、Cassandra、Bigtable都屬於面向列存儲的分布式存儲系統。看到這裏，如果妳不明白Hbase是什麽，沒關系，我再總結壹下:
Hbase是壹個面向列存儲的分布式存儲系統。它的優點是可以實現高性能的並發讀寫操作，同時Hbase可以透明的劃分數據，使得存儲本身具有橫向可擴展性。
雙基數數據模型
Hbase和Cassandra的數據模型非常相似，它們的思想都來源於Google的Bigtable，所以三者的數據模型非常相似。唯壹不同的是，Cassandra有超級雲族的概念，但HBase至今未被發現。好了，廢話少說，我們來看看Hbase的數據模型是什麽。
Hbase中有兩個主要概念，Rowkey和Column family。我們來看看柱族，中文也叫“柱族”。ColumnFamily是在系統啟動前預定義的，每個ColumnFamily根據“限定符”可以有多個列。我們舉個例子說的很清楚。
如果系統中有用戶表，按照傳統的RDBMS，用戶表中的列是固定的。例如，模式定義了姓名、年齡和性別等屬性，用戶的屬性不能動態增加。但是，如果采用列存儲系統，比如Hbase，那麽我們可以定義用戶表，然後定義info列族。用戶的數據可以分為:info:姓名=張三，info:年齡= 30，info:性別=男等。如果以後想添加另壹個屬性，只需要info:newProperty就很方便了。
也許前面的例子還不夠清楚。我們再舉壹個例子來說明。熟悉SNS的朋友應該都知道有好友的feeds。壹般我們會根據“某人某段時間做了標題為XXX的事情”來設計feeds，但同時也會預留關鍵詞。例如，有時候提要可能需要url，提要需要圖像屬性。這樣，提要本身的屬性是不確定的，使用傳統的關系數據庫會很麻煩。而且關系數據庫會浪費壹些空單元，列存儲不會有這個問題。在Hbase中，如果每個列單元都沒有值，就會占用空間。讓我們通過兩張圖片生動地展示這種關系:
上圖是傳統RDBMS設計的Feed表。我們可以看到提要中有多少列是固定的，不能添加，空列浪費了空間。但是我們來看看下圖，是Hbase，Cassandra，Bigtable的數據模型圖。從下圖可以看出，Feed表的列可以動態增加，空列不存儲，大大節省了空間。關鍵是隨著系統的運行，會出現各種各樣的feed，我們無法提前預測有多少feed。然後沒有辦法確定Feed表有多少列，所以基於Hbase、Cassandra、Bigtable Bigtable的列存儲的數據模型非常適合這種場景。說到這裏，使用Hbase的另壹個非常重要的優勢就是提要會自動分段。當Feed表中的數據超過壹定閾值時，Hbase會自動為我們分段數據。這樣壹來，查詢將是可伸縮的，再加上Hbase的弱事務特性，對Hbase的寫操作將變得非常快。
上面提到了列族，那麽我之前提到的行鍵是什麽呢？其實妳可以理解為行鍵是RDBMS中壹行的主鍵，但是由於Hbase不支持條件查詢和Order by之類的查詢，所以行鍵的設計要根據妳系統的查詢需求來設計。我也拿剛才飼料的專欄來舉例。通常，我們查詢某人的最新提要，因此提要的行鍵可以由以下三部分組成< userId & gt& lt時間戳& gt& ltfeedId & gt這樣，當我們想要查詢某人的最高級提要時，我們可以將Start Rowkey指定為
三種Hbase的優缺點
1列可以動態增加，如果該列為空，則不存儲任何數據，節省存儲空間。
2 Hbase自動分區數據，使數據存儲自動橫向擴展。
3 Hbase可以提供對高並發讀寫操作的支持。
Hbase的缺點:
1不能支持條件查詢，只能按行鍵查詢。
暫時不支持主服務器的故障轉移。當Master停機時，整個存儲系統將掛起。
四。補充
1.數據類型，HBase只有簡單的字符類型，所有類型都是用戶自己處理的，它只保存字符串。關系數據庫有豐富的類型和存儲方法。
2.數據操作:HBase只有插入、查詢、刪除、清空等簡單操作，表與表是分離的，表與表之間沒有復雜的關系，而傳統數據庫通常有各種功能和連接操作。
3.存儲方式:HBase基於列存儲，每個列族由幾個文件保存，不同列族的文件是分開的。傳統的關系數據庫是基於表結構和行模式的。
4.數據維護，HBase的更新操作不應該叫更新，它實際上是插入新的數據，而傳統的數據庫是被替換和修改的。
5.可伸縮性，分布式數據庫如Hbase就是為此而開發的，所以它可以很容易地增加或減少硬件的數量，並且高度兼容錯誤。然而，傳統數據庫通常需要添加壹個中間層來實現類似的功能。