資料庫垂直分區

㈠ 資料庫中表分割和表分區的區別是什麼

個人認為理論上使用表分割在性能上應該和建立表分區查不多，但是，表分割對於所有的資料庫都適用，而表分區只能用於oracle這樣的特定的資料庫；表分區屬於資料庫物理設計，表分割屬於邏輯設計。
表分區：
表分區是ORACLE對於非常大的表進行優化的一種有效方法, 是非常有效的一種手段, 在很多情況下,比你說的表分割更有效,比如,有一個代碼表,使用分區表把100萬紀錄分在10個分區中(ID 每從1到10萬為一個分區),那樣寫查詢語句的時候,只要給出查詢條件中所需要的代碼,ORACLE自動會定位到對應的分區進行查詢,大大降低的查詢時間. 而採用表分割,那必須先根據查詢的代碼指定所要查詢的表,才能找到相應的紀錄. 而且,如果有下面這樣的語句,查詢的條件是跨分區的:
SELECT * FROM MYTABLE WHERE ID BETWEEN 99000 AND 10111;
在分區表中是非常容易實現的,ORACLE會自動在兩個分區中查詢;而採用表分割的話是否必須寫成兩個查詢語句在UNION ALL。
事實上,大型的資料庫都有對大表的特殊處理方式(類似於分區表),如果太強調可移植性而放棄這些最重要的特性的話,那性能很可能受到很大的影響.
即便是oracle資料庫，當數據量很大時，用分表比用表分區要快些，尤其是在表用到group by求和等操作。
我也認為表分區要好一些，也就是一般說來的分區表，對這些表操作起來有很多強大的功能，說他強大主要是體現在對與表中有海量數據的情況之下的，試問大家一個其中有1億條記錄的表你是否會經常的將其移植到其他資料庫系統當中去呢？
表分區基於物理存儲，還有就是基於分區的索引可以使用，很不錯的，當然，這些都是在海量數據情況之下的比較，但是如果真要是數據量不大的情況下比較，我想要比較分區表和表分割就沒什麼意思了。
表分區的效果對硬體有所依賴，而且效果恐怕不如諸位想像中那麼好。我做過一點測試，很失望。
而表分割的效率提升在很多時候（不是所有時候）是很明顯的。
當然這都是在巨型表的前提下討論，縮小表和索引的規模有利於提高效率，這正是分割表的特點。
表分割：
1、水平分割：根據一列或多列數據的值把數據行放到兩個獨立的表中。
水平分割通常在下面的情況下使用:A 表很大，分割後可以降低在查詢時需要讀的數據和索引的頁數，同時也降低了索引的層數，提高查詢速度。B 表中的數據本來就有獨立性，例如表中分別記錄各個地區的數據或不同時期的數據，特別是有些數據常用，而另外一些數據不常用。C需要把數據存放到多個介質上。
例如法規表law就可以分成兩個表active－law和 inactive－law。activea－authors表中的內容是正生效的法規，是經常使用的，而inactive－law表則使已經作廢的法規，不常被查詢。水平分割會給應用增加復雜度，它通常在查詢時需要多個表名，查詢所有數據需要union操作。在許多資料庫應用中，這種復雜性會超過它帶來的優點，因為只要索引關鍵字不大，則在索引用於查詢時，表中增加兩到三倍數據量，查詢時也就增加讀一個索引層的磁碟次數。
2、垂直分割：把主碼和一些列放到一個表，然後把主碼和另外的列放到另一個表中。
如果一個表中某些列常用，而另外一些列不常用，則可以採用垂直分割，另外垂直分割可以使得數據行變小，一個數據頁就能存放更多的數據，在查詢時就會減少I/O 次數。其缺點是需要管理冗餘列，查詢所有數據需要join操作。

㈡ 多項選擇 在資料庫邏輯設計中，關於水平分區和垂直分區的描述，正確的是_____。

B 垂直分區是將一個表分段為多個表，每個表包含較少的列,這是垂直分區的基本原理，其他選項錯誤

㈢ mysql 怎樣垂直分區

垂直分區適合因為表多而導致數據量大的情況，將各個模塊應用，相關性小的數據表分開成幾個庫。通過模塊來鏈接對應的資料庫

㈣ 資料庫垂直分表和水平分別到底什麼意思

垂直分表，指的是把主鍵欄位拿出來，分的兩個表都有，然後原表其他欄位根據實際情況，例如查詢頻率，放兩個表中。
水平分表相當於數據存儲拆開，建多個表，每個表欄位完全一樣，存放不同數據，例如按照月份存放

㈤ 為什麼說hbase是一個面向列的資料庫

在說HBase之前，我想再嘮叨幾句。做互聯網應用的哥們兒應該都清楚，互聯網應用這東西，你沒辦法預測你的系統什麼時候會被多少人訪問，你面臨的用戶到底有多少，說不定今天你的用戶還少，明天系統用戶就變多了，結果您的系統應付不過來了了，不幹了，這豈不是咱哥幾個的悲哀，說時髦點就叫「杯具啊」。

其實說白了，這些就是事先沒有認清楚互聯網應用什麼才是最重要的。從系統架構的角度來說，互聯網應用更加看重系統性能以及伸縮性，而傳統企業級應用都是比較看重數據完整性和數據安全性。那麼我們就來說說互聯網應用伸縮性這事兒.對於伸縮性這事兒，哥們兒我也寫了幾篇博文，想看的兄弟可以參考我以前的博文，對於web server,app server的伸縮性，我在這里先不說了，因為這部分的伸縮性相對來說比較容易一點，我主要來回顧一些一個慢慢變大的互聯網應用如何應對資料庫這一層的伸縮。

首先剛開始，人不多，壓力也不大,搞一台資料庫伺服器就搞定了，此時所有的東東都塞進一個Server里，包括web server,app server,db server,但是隨著人越來越多，系統壓力越來越多，這個時候可能你把web server,app server和db server分離了，好歹這樣可以應付一陣子，但是隨著用戶量的不斷增加，你會發現，資料庫這哥們不行了，速度老慢了，有時候還會宕掉，所以這個時候，你得給資料庫這哥們找幾個伴，這個時候Master-Salve就出現了，這個時候有一個Master Server專門負責接收寫操作，另外的幾個Salve Server專門進行讀取，這樣Master這哥們終於不抱怨了，總算讀寫分離了，壓力總算輕點了,這個時候其實主要是對讀取操作進行了水平擴張，通過增加多個Salve來克服查詢時CPU瓶頸。一般這樣下來，你的系統可以應付一定的壓力，但是隨著用戶數量的增多，壓力的不斷增加，你會發現Master server這哥們的寫壓力還是變的太大，沒辦法，這個時候怎麼辦呢？你就得切分啊，俗話說「只有切分了，才會有伸縮性嘛」，所以啊，這個時候只能分庫了，這也是我們常說的資料庫「垂直切分」，比如將一些不關聯的數據存放到不同的庫中，分開部署，這樣終於可以帶走一部分的讀取和寫入壓力了，Master又可以輕松一點了，但是隨著數據的不斷增多，你的資料庫表中的數據又變的非常的大，這樣查詢效率非常低，這個時候就需要進行「水平分區」了，比如通過將User表中的數據按照10W來劃分，這樣每張表不會超過10W了。

綜上所述，一般一個流行的web站點都會經歷一個從單台DB，到主從復制，到垂直分區再到水平分區的痛苦的過程。其實資料庫切分這事兒，看起來原理貌似很簡單，如果真正做起來，我想凡是sharding過資料庫的哥們兒都深受其苦啊。對於資料庫伸縮的文章，哥們兒可以看看後面的參考資料介紹。

好了，從上面的那一堆廢話中，我們也發現資料庫存儲水平擴張scale out是多麼痛苦的一件事情，不過幸好技術在進步，業界的其它弟兄也在努力，09年這一年出現了非常多的NoSQL資料庫，更准確的應該說是No relation資料庫，這些資料庫多數都會對非結構化的數據提供透明的水平擴張能力，大大減輕了哥們兒設計時候的壓力。下面我就拿Hbase這分布式列存儲系統來說說。

一 Hbase是個啥東東？
在說Hase是個啥傢伙之前，首先我們來看看兩個概念，面向行存儲和面向列存儲。面向行存儲，我相信大夥兒應該都清楚，我們熟悉的RDBMS就是此種類型的，面向行存儲的資料庫主要適合於事務性要求嚴格場合，或者說面向行存儲的存儲系統適合OLTP，但是根據CAP理論，傳統的RDBMS，為了實現強一致性，通過嚴格的ACID事務來進行同步，這就造成了系統的可用性和伸縮性方面大大折扣，而目前的很多NoSQL產品，包括Hbase，它們都是一種最終一致性的系統，它們為了高的可用性犧牲了一部分的一致性。好像，我上面說了面向列存儲，那麼到底什麼是面向列存儲呢？Hbase,Casandra,Bigtable都屬於面向列存儲的分布式存儲系統。看到這里，如果您不明白Hbase是個啥東東，不要緊，我再總結一下下：

Hbase是一個面向列存儲的分布式存儲系統，它的優點在於可以實現高性能的並發讀寫操作，同時Hbase還會對數據進行透明的切分，這樣就使得存儲本身具有了水平伸縮性。

二 Hbase數據模型
HBase,Cassandra的數據模型非常類似，他們的思想都是來源於Google的Bigtable，因此這三者的數據模型非常類似，唯一不同的就是Cassandra具有Super cloumn family的概念，而Hbase目前我沒發現。好了，廢話少說，我們來看看Hbase的數據模型到底是個啥東東。

在Hbase裡面有以下兩個主要的概念，Row key,Column Family，我們首先來看看Column family,Column family中文又名「列族」，Column family是在系統啟動之前預先定義好的，每一個Column Family都可以根據「限定符」有多個column.下面我們來舉個例子就會非常的清晰了。

假如系統中有一個User表，如果按照傳統的RDBMS的話，User表中的列是固定的，比如schema 定義了name,age,sex等屬性，User的屬性是不能動態增加的。但是如果採用列存儲系統，比如Hbase，那麼我們可以定義User表，然後定義info 列族，User的數據可以分為：info:name = zhangsan,info:age=30,info:sex=male等，如果後來你又想增加另外的屬性，這樣很方便只需要info:newProperty就可以了。

也許前面的這個例子還不夠清晰，我們再舉個例子來解釋一下，熟悉SNS的朋友，應該都知道有好友Feed，一般設計Feed，我們都是按照「某人在某時做了標題為某某的事情」，但是同時一般我們也會預留一下關鍵字，比如有時候feed也許需要url，feed需要image屬性等，這樣來說，feed本身的屬性是不確定的，因此如果採用傳統的關系資料庫將非常麻煩，況且關系資料庫會造成一些為null的單元浪費，而列存儲就不會出現這個問題，在Hbase里，如果每一個column 單元沒有值，那麼是佔用空間的。下面我們通過兩張圖來形象的表示這種關系：

上圖是傳統的RDBMS設計的Feed表，我們可以看出feed有多少列是固定的，不能增加，並且為null的列浪費了空間。但是我們再看看下圖，下圖為Hbase，Cassandra,Bigtable的數據模型圖，從下圖可以看出，Feed表的列可以動態的增加，並且為空的列是不存儲的，這就大大節約了空間，關鍵是Feed這東西隨著系統的運行，各種各樣的Feed會出現，我們事先沒辦法預測有多少種Feed，那麼我們也就沒有辦法確定Feed表有多少列，因此Hbase,Cassandra,Bigtable的基於列存儲的數據模型就非常適合此場景。說到這里，採用Hbase的這種方式，還有一個非常重要的好處就是Feed會自動切分，當Feed表中的數據超過某一個閥值以後，Hbase會自動為我們切分數據，這樣的話，查詢就具有了伸縮性，而再加上Hbase的弱事務性的特性，對Hbase的寫入操作也將變得非常快。

上面說了Column family，那麼我之前說的Row key是啥東東，其實你可以理解row key為RDBMS中的某一個行的主鍵，但是因為Hbase不支持條件查詢以及Order by等查詢，因此Row key的設計就要根據你系統的查詢需求來設計了額。我還拿剛才那個Feed的列子來說，我們一般是查詢某個人最新的一些Feed，因此我們Feed的Row key可以有以下三個部分構成<userId><timestamp><feedId>，這樣以來當我們要查詢某個人的最進的Feed就可以指定Start Rowkey為<userId><0><0>，End Rowkey為<userId><Long.MAX_VALUE><Long.MAX_VALUE>來查詢了，同時因為Hbase中的記錄是按照rowkey來排序的，這樣就使得查詢變得非常快。

三 Hbase的優缺點
1 列的可以動態增加，並且列為空就不存儲數據,節省存儲空間.

2 Hbase自動切分數據，使得數據存儲自動具有水平scalability.

3 Hbase可以提供高並發讀寫操作的支持

Hbase的缺點：

1 不能支持條件查詢，只支持按照Row key來查詢.

2 暫時不能支持Master server的故障切換,當Master宕機後,整個存儲系統就會掛掉.

四.補充
1.數據類型，HBase只有簡單的字元類型，所有的類型都是交由用戶自己處理，它只保存字元串。而關系資料庫有豐富的類型和存儲方式。
2.數據操作：HBase只有很簡單的插入、查詢、刪除、清空等操作，表和表之間是分離的，沒有復雜的表和表之間的關系，而傳統資料庫通常有各式各樣的函數和連接操作。
3.存儲模式：HBase是基於列存儲的，每個列族都由幾個文件保存，不同的列族的文件時分離的。而傳統的關系型資料庫是基於表格結構和行模式保存的
4.數據維護，HBase的更新操作不應該叫更新，它實際上是插入了新的數據，而傳統資料庫是替換修改
5.可伸縮性，Hbase這類分布式資料庫就是為了這個目的而開發出來的，所以它能夠輕松增加或減少硬體的數量，並且對錯誤的兼容性比較高。而傳統資料庫通常需要增加中間層才能實現類似的功能

㈥ chs是什麼意思

CHS，是FDISK在分區期間所需磁碟信息。

CHS定址模式：

1、 CHS定址模式將硬碟劃分為磁頭（Heads）、柱面(Cylinder)、扇區(Sector)。

磁頭(Heads)：每張磁片的正反兩面各有一個磁頭，一個磁頭對應一張磁片的一個面。因此，用第幾磁 頭就可以表示數據在哪個磁面。

柱面(Cylinder)：所有磁片中半徑相同的同心磁軌構成「柱面"，意思是這一系列的磁軌垂直疊在一起，就形成一個柱面的形狀。簡單地理解，柱面數=磁軌數。

扇區(Sector)：將磁軌劃分為若干個小的區段，就是扇區。雖然很小，但實際是一個扇子的形狀，故稱為扇區。每個扇區的容量為512位元組。

2、 知道了磁頭數、柱面數、扇區數，就可以很容易地確定數據保存在硬碟的哪個位置。也很容易確定硬碟的容量，其計算公式是：

硬碟容量=磁頭數×柱面數×扇區數×512位元組

3、LARGE定址模式把柱面數除以整數倍、磁頭數乘以整數倍而得到的邏輯磁頭/柱面/扇區參數進行定址，所以表示的已不是硬碟中的物理位置，而是邏輯位置。LBA定址模式是直接以扇區為單位進行定址的，不再用磁頭/柱面/扇區三種單位來進行定址。

但為了保持與CHS模式的兼容，通過邏輯變換演算法，可以轉換為磁頭/柱面/扇區三種參數來表示，但表示的也和LARGE定址模式一樣，已不是硬碟中的物理位置，而是邏輯位置了。

(6)資料庫垂直分區擴展閱讀

分區主要有兩種形式：

水平分區（Horizontal Partitioning）

這種形式分區是對表的行進行分區，通過這樣的方式不同分組裡面的物理列分割的數據集得以組合，從而進行個體分割（單分區）或集體分割（1個或多個分區）。所有在表中定義的列在每個數據集中都能找到，所以表的特性依然得以保持。

舉個簡單例子：一個包含十年發票記錄的表可以被分區為十個不同的分區，每個分區包含的是其中一年的記錄。（朋奕註：這里具體使用的分區方式我們後面再說，可以先說一點，一定要通過某個屬性列來分割，譬如這里使用的列就是年份）

垂直分區（Vertical Partitioning）

這種分區方式一般來說是通過對表的垂直劃分來減少目標表的寬度，使某些特定的列被劃分到特定的分區，每個分區都包含了其中的列所對應的行。

舉個簡單例子：一個包含了大text和BLOB列的表，這些text和BLOB列又不經常被訪問，這時候就要把這些不經常使用的text和BLOB了劃分到另一個分區，在保證它們數據相關性的同時還能提高訪問速度。

在資料庫供應商開始在他們的資料庫引擎中建立分區（主要是水平分區）時，DBA和建模者必須設計好表的物理分區結構，不要保存冗餘的數據（不同表中同時都包含父表中的數據）或相互聯結成一個邏輯父對象（通常是視圖）。這種做法會使水平分區的大部分功能失效，有時候也會對垂直分區產生影響。

㈦ 資料庫水平分庫和垂直分庫有什麼區別

TiDB 社區（AskTUG）

對於傳統資料庫，無論是水平還是垂直分庫，都是很繁瑣，耗時耗力的工作，TiDB 作為 NewSQL 資料庫，根據自身特性，完美解決該問題

• 水平彈性擴展

  通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。

• 分布式事務

  TiDB 100% 支持標準的 ACID 事務。

㈧ 資料庫分區的分類

分區主要有兩種形式：//這里一定要注意行和列的概念（row是行，column是列）
水平分區（Horizontal Partitioning）
這種形式分區是對表的行進行分區，通過這樣的方式不同分組裡面的物理列分割的數據集得以組合，從而進行個體分割（單分區）或集體分割（1個或多個分區）。所有在表中定義的列在每個數據集中都能找到，所以表的特性依然得以保持。
舉個簡單例子：一個包含十年發票記錄的表可以被分區為十個不同的分區，每個分區包含的是其中一年的記錄。（朋奕註：這里具體使用的分區方式我們後面再說，可以先說一點，一定要通過某個屬性列來分割，譬如這里使用的列就是年份）
垂直分區（Vertical Partitioning）
這種分區方式一般來說是通過對表的垂直劃分來減少目標表的寬度，使某些特定的列被劃分到特定的分區，每個分區都包含了其中的列所對應的行。
舉個簡單例子：一個包含了大text和BLOB列的表，這些text和BLOB列又不經常被訪問，這時候就要把這些不經常使用的text和BLOB了劃分到另一個分區，在保證它們數據相關性的同時還能提高訪問速度。
在資料庫供應商開始在他們的資料庫引擎中建立分區（主要是水平分區）時，DBA和建模者必須設計好表的物理分區結構，不要保存冗餘的數據（不同表中同時都包含父表中的數據）或相互聯結成一個邏輯父對象（通常是視圖）。這種做法會使水平分區的大部分功能失效，有時候也會對垂直分區產生影響。