笔记《Hbase 权威指南》

• 为何要用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打交道？