HBASE APPLICATION ARCHETYPES REDUX2 (Part 2 of 2)
(This is the second of a two-part post. The first part an be found at this spot).
DOCUMENT
Using a technique called key-flattening, a document can be shredded by storing each value in the document according to the path from the root to the name of the element containing the value. HDocDB uses this approach.
| Column Family: default | |||
| Row Key | Column:
|
Column:
|
… |
|
|
|
… | |
The document can also be stored as a binary value, in which case support for Medium Objects (MOBs) can be used if the documents are large. This approach is described in the book Architecting HBase Applications.
| Column Family: default | |
| Row Key | Column: body |
| |
GRAPH
There are many ways to store a graph in HBase. One method is to use an adjacency list, where each vertex stores its neighbors in the same row. This is the approach taken in JanusGraph.
| Column Family: default | ||||||
| Row Key | Column: |
Column: |
… | Column:
|
Column:
|
… |
| |
… |
|
|
… | ||
In the table above, the edge key is actually comprised of a number of parts, including the label, direction, edge ID, and adjacent vertex ID.
Alternatively, a separate table to represent edges can be used, in which case the incident vertices are stored in the same row as an edge. This may scale better if the adjacency list is large, such as in a social network. This is the approach taken in both Zen and HGraphDB.
| Column Family: default | |||
| Row Key | Column:
|
Column:
|
… |
|
|
|
… | |
| Column Family: default | |||||
| Row Key | Column: fromVertex | Column: toVertex | Column:
|
Column:
|
… |
| |
|
|
… | ||
When storing edges in a separate table, additional index tables must be used to provide efficient access to the incident edges of a vertex. For example, the full list of tables in HGraphDB can be viewed here.
QUEUE
A queue can be modeled by using a row key comprised of the consumer ID and a counter. Both Cask and Box implement queues in this manner.
| Column Family: default | ||
| Row Key | Column: metadata | Column: body |
| |
||
Cask also uses coprocessors for efficient scan filtering and queue trimming, and Apache Tephra for transactional queue processing.
METRICS
The Metrics archetype is a variant of the Entity archetype in which the column values are counters or some other aggregate.
| Column Family: default | |||
| Row Key | Column:
|
Column:
|
… |
|
|
|
… | |
HGraphDB is actually a combination of the Graph and Metrics archetypes, as arbitrary counters can be stored on either vertices or edges.
(This is the second of a two-part article. The first part can be found over here).