• 為什么要用Hbase
  - Hbase的誕生是因為現有的關系型數據庫已經無法在硬件上滿足瘋狂增長的數據了，而且因為需要實時的數據提取Memcached也無法滿足
  - Hbase適合于無結構或半結構化數據，適合于schema變動的情況
  - Hbase天生適合以時間軸做查詢
• Werner Vogels，可以關注一下他的博客（Amazon的CTO）
• 分布式計算系統的CAP定理：
  在理論計算機科學中, CAP定理（CAP theorem）, 又被稱作 布魯爾定理（Brewer's theorem）, 它指出對於一個分布式計算系統來說，不可能同時滿足以下三點:

  - 一致性(Consistency) (所有節點在同一時間具有相同的數據)

  - 可用性(Availability) (保證每個請求不管成功或者失敗都有響應)

  - 分隔容忍(Partition tolerance) (系統中任意信息的丟失或失敗不會影響系統的繼續運作)

• Eventually consistent http://www.allthingsdistributed.com/2007/12/eventually_consistent.html
• NoSQL與關系型數據庫并非二元（即非此即彼），你需要從以下幾個方面來看下你的數據場景進而決定是否需要使用象HBASE這樣的NOSQL數據庫
  - Data model: 數據訪問方式是怎樣，是非結構化、半結構化，列式存儲，還是文件式存儲？你的數據的schema是如何演進的
  - Storage model: 是in-memory的還是一直持久化的？RDBMS基本都是數據持久化的，不過你可能就需要一個in-memory的數據庫，仍然要看你的數據訪問方式是怎樣的。
  - Consistency model：是嚴格一致性還是最終一致性? 為了可用性/存儲方式或是網絡傳統速度，你愿意放棄多少的數據一致性？see here 《Lessons from giant-scale services 》
  - Physical model：是否分布式數據庫？
  - Read/write performance：讀寫速度，必須很清楚明白你的數據的讀寫方式，是少寫多讀，一次寫入多次讀，還是需要頻繁修改？
  - Secondary indexes：二級索引，你知道你的數據使用場景需要或未來會需要哪些二級索引嗎？
  - Failure handling：錯誤處理機制，容災/錯處理
  - Compression：壓縮算法能壓縮物理空間比到10:1甚至更高，尤其適用于大數據的情況
  - Load balancing
  - Atomic read-modify-write：Having these compare and swap (CAS) or check and set operations available can reduce client-side complexity，即是使用樂觀鎖還是悲觀鎖，樂觀鎖即非阻塞式
  擴展閱讀： 《一種高效無鎖內存隊列的實現》《無鎖隊列的實現》
  - Locking, waits and deadlocks：你的數據場景中對死鎖，等待等的設計
• 垂直分布：指的增加內存CPU/CORE等，是一種擴展性較差的需要投入大量資金的分布方式，不適合于大數據了。

• Denormalization, Duplication, and Intelligent Keys (DDI)

• 關于HBase URL Shortener示例的一些擴展閱讀：
  https://github.com/michiard/CLOUDS-LAB/tree/master/hbase-lab

• The support for sparse, wide tables and column-oriented design often eliminates the need to normalize data and, in the process, the costly? JOINoperations needed to aggregatethe data at query time. Use of intelligent keys gives you fine-grained control over how—and where—data is stored. Partial key lookups are possible, and when combined with compound keys, they have the same properties as leading, left-edge indexes. Designing the schemas properly enables you to grow the data from 10 entries to 10 million entries, while still retaining the same write and read performance.

  稀疏 sparse,wide tables，是反范式的

• 這一篇可以看

• bigtable: 丟棄傳統的RDBMS的CRU特性，追求更高效適應水平分布擴展需求的支持數據段掃描及全表掃描的分布式數據庫

• HBASE元素：ROW,ROWKEY,COLUMN,COLUMN FAMILY,CELL

• HBASE的自然排序：HBASE是以lexicographically排序的即詞典式的排序，按字節碼排序

• HBASE是支持二級索引的！但BIG TABLE不支持。

• HBASE的COLUMN FAMILY須預先定義并且最好不應經常變成，數量上也最好要少于10個，不要太多（思考：難道是因為是sparse, wide，所以最好不要有太多空白列?），不過一個column family你盡管可以擁有上百萬的column，因為它們占用的是行而非列。Timestamp可由系統指定也可由用戶指定。
  

• Predicate deletion => Log-structured Merge-Tree/LSM

• HFile是按column family存儲的，即一個column family占用一個HFile，為了更容易in-memory store

• HBASE和BIGTABLE的“正統”用法是WEB TABLE啊.. 專用于爬蟲的，比如保存anchor, content等
  

• HBASE中的REGION相當于自動分片（auto - sharding）

  For HBase and modern hardware, the number would be more like 10 to 1,000 regions per server, but each between 1 GB and 2 GB in size
  RegionServer管理近千個regions，理論上每個row只存在于一個region（問，如果一個row超過了一個region，如何處理的? 我們是不是不應該設計這樣的rowkey先？）

• Single-row transaction：一行的數據是事務性原子性的，無跨行原子性

• Map-Reduce可將HBASE數據轉化為inputFormat和outputFormat

• HFile有block，block又致使必須得有block index lookup，這個index保存在內存中(in-memory block index)

• Zookeeper是Chubby for bigtable的對應物，
  
  It offers filesystem-like access with directories and files (called? znodes) that distributed systems can use to negotiate ownership, register services, or watch for updates. Every region server creates its own ephemeral node in ZooKeeper, which the master, in turn, uses to discover available servers. They are also used to track server failures or network partitions.
  

• master (HMaster) 會做
  - Zookeeper (問：Zookeeper和HMaster分別做什么？書中P26語焉不詳）
  - 負載均衡管理
  - 監控和管理schema changes, metadata operations，如表/列族的創建等
  - Zookeeper仍然使用heartbeating機制

• Region server
  - 做region split (sharding）
  - 做region管理

• Client直接與regions交互讀寫數據，region server并不參與

• 這兒完全不懂（P27): 涉及到表掃描算法

  Table scans run in linear time and row key lookups or mutations are performed in logarithmic order—or, in extreme cases, even constant order (using Bloom filters). Designing the schema in a way to completely avoid explicit locking, combined with row-level atomicity, gives you the ability to scale your system without any notable effect on read or write performance.

• 何謂read-modify-write? wiki
  In computer science, read–modify–write is a class of atomic operations such as test-and-set, fetch-and-add, and compare-and-swap which both read a memory location and write a new value into it simultaneously, either with a completely new value or some function of the previous value. These operations prevent race conditions in multi-threaded applications. Typically they are used to implement mutexes or semaphores. These atomic operations are also heavily used in non-blocking synchronization.

3.疑惑:

• 如果手動建二級索引表，如何保證數據的即時性? 建多個表，比如USERID，如何應付后期JOIN表格？難道要用MAP-REDUCE來完成？
• HBASE的稀疏性是如何體現的呢？
• 壓縮算法是怎樣的呢？
• 合并中到底做了哪些事情呢？
• LSM這一節（即P25說明部分沒看明白，還要FUTHER READINGS）
• Zookeeper的quorum到底是干嘛的，為什么讓我配置在slave上
• 這一句不懂：In addition, it provides push-down predicates, that is, filters, reducing data transferred over the network. 在第一章最后提到了說hbase提供一種push-down predicate，push-down: cause to come or go down，即使數據減少的斷言。這個有些不懂，不知道是不是指的就是配置只取出部分的數據，并能將不滿足配置有效時間的數據刪除或過濾掉。

4.思考:

• Denormalization, Duplication, and Intelligent Keys (DDI)
• 讀<BIG TABLE>
• APPEND? 物理存儲上的表現？
• 如果和MEM STORE打交道？

總結

以上是生活随笔為你收集整理的笔记《Hbase 权威指南》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。