hbase-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From st...@apache.org
Subject svn commit: r1416675 - in /hbase/trunk/src/docbkx: book.xml developer.xml
Date Mon, 03 Dec 2012 21:30:16 GMT
Author: stack
Date: Mon Dec  3 21:30:14 2012
New Revision: 1416675

URL: http://svn.apache.org/viewvc?rev=1416675&view=rev
Log:
HBASE-7264 Improve Snappy installation documentation

Modified:
    hbase/trunk/src/docbkx/book.xml
    hbase/trunk/src/docbkx/developer.xml

Modified: hbase/trunk/src/docbkx/book.xml
URL: http://svn.apache.org/viewvc/hbase/trunk/src/docbkx/book.xml?rev=1416675&r1=1416674&r2=1416675&view=diff
==============================================================================
--- hbase/trunk/src/docbkx/book.xml (original)
+++ hbase/trunk/src/docbkx/book.xml Mon Dec  3 21:30:14 2012
@@ -761,14 +761,14 @@ System.out.println("md5 digest as string
     ... (note:  the lead byte is listed to the right as a comment.)  Given that the first
split is a '0' and the last split is an 'f',
     everything is great, right?  Not so fast.
     </para>
-    <para>The problem is that all the data is going to pile up in the first 2 regions
and the last region thus creating a "lumpy" (and 
-    possibly "hot") region problem.  To understand why, refer to an  <link xlink:href="http://www.asciitable.com">ASCII
Table</link>.  
+    <para>The problem is that all the data is going to pile up in the first 2 regions
and the last region thus creating a "lumpy" (and
+    possibly "hot") region problem.  To understand why, refer to an  <link xlink:href="http://www.asciitable.com">ASCII
Table</link>.
     '0' is byte 48, and 'f' is byte 102, but there is a huge gap in byte values (bytes 58
to 96) that will <emphasis>never appear in this
-    keyspace</emphasis> because the only values are [0-9] and [a-f].  Thus, the middle
regions regions will 
+    keyspace</emphasis> because the only values are [0-9] and [a-f].  Thus, the middle
regions regions will
     never be used.  To make pre-spliting work with this example keyspace, a custom definition
of splits (i.e., and not relying on the
-    built-in split method) is required.   
+    built-in split method) is required.
     </para>
-    <para>Lesson #1:  Pre-splitting tables is generally a best practice, but you need
to pre-split them in such a way that all the 
+    <para>Lesson #1:  Pre-splitting tables is generally a best practice, but you need
to pre-split them in such a way that all the
     regions are accessible in the keyspace.  While this example demonstrated the problem
with a hex-key keyspace, the same problem can happen
      with <emphasis>any</emphasis> keyspace.  Know your data.
     </para>
@@ -971,19 +971,19 @@ public static byte[][] getHexSplits(Stri
       </para>
       <para>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.  But there
is also a middle path between these two
-      options, and that is "Rows as Columns." 
+      options, and that is "Rows as Columns."
       </para>
     </section>
     <section xml:id="schema.smackdown.rowsascols"><title>Rows as Columns</title>
       <para>The middle path between Rows vs. Columns is packing data that would be
a separate row into columns, for certain rows.
       OpenTSDB is the best example of this case where a single row represents a defined time-range,
and then discrete events are treated as
-      columns.  This approach is often more complex, and may require the additional complexity
of re-writing your data, but has the 
-      advantage of being I/O efficient.  For an overview of this approach, see 
-      <link xlink:href="http://www.cloudera.com/content/cloudera/en/resources/library/hbasecon/video-hbasecon-2012-lessons-learned-from-opentsdb.html">Lessons
Learned from OpenTSDB</link> 
+      columns.  This approach is often more complex, and may require the additional complexity
of re-writing your data, but has the
+      advantage of being I/O efficient.  For an overview of this approach, see
+      <link xlink:href="http://www.cloudera.com/content/cloudera/en/resources/library/hbasecon/video-hbasecon-2012-lessons-learned-from-opentsdb.html">Lessons
Learned from OpenTSDB</link>
       from HBaseCon2012.
       </para>
     </section>
-    
+
   </section>
   <section xml:id="schema.ops"><title>Operational and Performance Configuration
Options</title>
     <para>See the Performance section <xref linkend="perf.schema"/> for more
information operational and performance
@@ -3060,20 +3060,20 @@ hbase> describe 't1'</programlisting>
         copied at the right place. Native libraries need to be installed under ${HBASE_HOME}/lib/native/Linux-amd64-64
or
         ${HBASE_HOME}/lib/native/Linux-i386-32 depending on your server architecture.
     </para>
-        
+
     <para>
-        You will find the snappy library file under the .libs directory from your Snappy
build (For example 
+        You will find the snappy library file under the .libs directory from your Snappy
build (For example
         /home/hbase/snappy-1.0.5/.libs/). The file is called libsnappy.so.1.x.x where 1.x.x
is the version of the snappy
         code you are building. You can either copy this file into your hbase directory under
libsnappy.so name, or simply
         create a symbolic link to it.
     </para>
-        
+
     <para>
         The second file you need is the hadoop native library. You will find this file in
your hadoop installation directory
         under lib/native/Linux-amd64-64/ or lib/native/Linux-i386-32/. The file you are looking
for is libhadoop.so.1.x.x.
         Again, you can simply copy this file or link to it, under the name libhadoop.so.
     </para>
-        
+
     <para>
         At the end of the installation, you should have both libsnappy.so and libhadoop.so
links or files present into
         lib/native/Linux-amd64-64 or into lib/native/Linux-i386-32

Modified: hbase/trunk/src/docbkx/developer.xml
URL: http://svn.apache.org/viewvc/hbase/trunk/src/docbkx/developer.xml?rev=1416675&r1=1416674&r2=1416675&view=diff
==============================================================================
--- hbase/trunk/src/docbkx/developer.xml (original)
+++ hbase/trunk/src/docbkx/developer.xml Mon Dec  3 21:30:14 2012
@@ -157,7 +157,7 @@ mvn clean package -DskipTests
       <section xml:id="build.snappy">
         <title>Building in snappy compression support</title>
         <para>Pass <code>-Dsnappy</code> to trigger the snappy maven profile
for building
-            snappy native libs into hbase.</para>
+            snappy native libs into hbase.  See also <xref linkend="snappy.compression"
/></para>
       </section>
 
       <section xml:id="build.tgz">



Mime
View raw message