HBASE-4571. book.xml, adding Schema Design Smackdown section.

git-svn-id: https://svn.apache.org/repos/asf/hbase/trunk@1181307 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Doug Meil 2011-10-11 00:15:52 +00:00
parent 5364f98a32
commit 6d68cece01

View File

@ -593,6 +593,27 @@ admin.enableTable(table);
</para>
</section>
</section>
<section xml:id="schema.smackdown"><title>Schema Design Smackdown</title>
<para>This section will describe common schema design questions that appear on the dist-list. These are
general guidelines and not laws - each application must consider it's own needs.
</para>
<section xml:id="schema.smackdown.rowsversions"><title>Rows vs. Versions</title>
<para>A common question is whether one should prefer rows or HBase's built-in-versioning. The context is typically where there are
"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.
</para>
<para>Winner: Rows (generally speaking).
</para>
</section>
<section xml:id="schema.smackdown.rowscols"><title>Rows vs. Columns</title>
<para>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.
</para>
<para>Winner: Rows (generally speaking). To be clear, this guideline is in the context is in extremely wide cases, not where
one needs to store a few dozen or hundred columns.
</para>
</section>
</section>
</chapter>