diff --git a/src/docbkx/book.xml b/src/docbkx/book.xml index 0368718fb31..afa2c047deb 100644 --- a/src/docbkx/book.xml +++ b/src/docbkx/book.xml @@ -602,14 +602,14 @@ admin.enableTable(table); "a lot" of versions of a row to be retained (e.g., where it is significantly above the HBase default of 3 max versions). The rows-approach would require storing a timstamp in some portion of the rowkey so that they would not overwite with each successive update. - Winner: Rows (generally speaking). + Preference: Rows (generally speaking).
Rows vs. Columns Another common question is whether one should prefer rows or columns. The context is typically in extreme cases of wide tables, such as having 1 row with 1 million attributes, or 1 million rows with 1 columns apiece. - Winner: Rows (generally speaking). To be clear, this guideline is in the context is in extremely wide cases, not in the + Preference: Rows (generally speaking). To be clear, this guideline is in the context is in extremely wide cases, not in the standard use-case where one needs to store a few dozen or hundred columns.
@@ -681,12 +681,6 @@ admin.enableTable(table); - - Cluster Replication - See Cluster Replication. - - - Data Model In short, applications store data into an HBase table. diff --git a/src/docbkx/ops_mgt.xml b/src/docbkx/ops_mgt.xml index 1101ed88f35..ce445d67778 100644 --- a/src/docbkx/ops_mgt.xml +++ b/src/docbkx/ops_mgt.xml @@ -251,6 +251,13 @@ false TODO + +
+ Cluster Replication + See Cluster Replication. + +
+
HBase Backup There are two broad strategies for performing HBase backups: backing up with a full cluster shutdown, and backing up on a live cluster.