Hbase #1 | Overview

    1. Database  Comments

Introduction


21. Conceptual View

  • Cells in this table that appear to be empty do not take space, or in fact exist, in HBase. This is what makes HBase “sparse.”

  • A tabular view is not the only possible way to look at data in HBase, or even the most accurate. The following represents the same information as a multi-dimensional map. This is only a mock-up for illustrative purposes and may not be strictly accurate.

| Row Key           | Time Stamp | ColumnFamily `contents`    | ColumnFamily `anchor`         | ColumnFamily `people`      |
| ----------------- | ---------- | -------------------------- | ----------------------------- | -------------------------- |
| "com.cnn.www"     | t9         |                            | anchor:cnnsi.com = "CNN"      |                            |
| "com.cnn.www"     | t8         |                            | anchor:my.look.ca = "CNN.com" |                            |
| "com.cnn.www"     | t6         | contents:html = "<html>…​"  |                               |                            |
| "com.cnn.www"     | t5         | contents:html = "<html>…​"  |                               |                            |
| "com.cnn.www"     | t3         | contents:html = "<html>…​"  |                               |                            |
| "com.example.www" | t5         | contents:html = "<html>…​"  |                               | people:author = "John Doe" |


{
  "com.cnn.www": {
    contents: {
      t6: contents:html: "<html>..."
      t5: contents:html: "<html>..."
      t3: contents:html: "<html>..."
    }
    anchor: {
      t9: anchor:cnnsi.com = "CNN"
      t8: anchor:my.look.ca = "CNN.com"
    }
    people: {}
  }
  "com.example.www": {
    contents: {
      t5: contents:html: "<html>..."
    }
    anchor: {}
    people: {
      t5: people:author: "John Doe"
    }
  }
}

35. Table Schema Rules of Thumb

  • There are many different data sets, with different access patterns and service-level expectations. Therefore, these rules of thumb are only an overview.
    • Aim to have regions sized between 10 and 50 GB.
    • Aim to have cells no larger than 10 MB, or 50 MB if you use mob. Otherwise, consider storing your cell data in HDFS and store a pointer to the data in HBase.
    • A typical schema has between 1 and 3 column families per table. HBase tables should not be designed to mimic RDBMS tables.
    • Around 50-100 regions is a good number for a table with 1 or 2 column families. Remember that a region is a contiguous segment of a column family.
    • Keep your column family names as short as possible. The column family names are stored for every value (ignoring prefix encoding). They should not be self-documenting and descriptive like in a typical RDBMS.
    • If you are storing time-based machine data or logging information, and the row key is based on device ID or service ID plus time, you can end up with a pattern where older data regions never have additional writes beyond a certain age. In this type of situation, you end up with a small number of active regions and a large number of older regions which have no new writes. For these situations, you can tolerate a larger number of regions because your resource consumption is driven by the active regions only.
    • If only one column family is busy with writes, only that column family accomulates memory. Be aware of write patterns when allocating resources.