Author: elserj
Date: Fri Apr  4 22:17:42 2014
New Revision: 1584928

URL: http://svn.apache.org/r1584928
Log:
Primarily grammar fixes

Modified:
    accumulo/site/trunk/content/release_notes/1.6.0.mdtext

Modified: accumulo/site/trunk/content/release_notes/1.6.0.mdtext
URL: 
http://svn.apache.org/viewvc/accumulo/site/trunk/content/release_notes/1.6.0.mdtext?rev=1584928&r1=1584927&r2=1584928&view=diff
==============================================================================
--- accumulo/site/trunk/content/release_notes/1.6.0.mdtext (original)
+++ accumulo/site/trunk/content/release_notes/1.6.0.mdtext Fri Apr  4 22:17:42 
2014
@@ -26,13 +26,13 @@ This document is a work in progress.
 
 ### Multiple namenode support
 
-BigTable's design allow's for its internal metadata to automatically spread 
across multiple nodes.  Accumulo has followed this design and scales very well 
as a result.  There is one impediment to scaling though, and this is the HDFS 
namenode.  There are two problems with the namenode when it comes to scaling.  
First, the namenode stores all of its filesystem metadata in memory on a single 
machine.  This introduces an upper bound on the number of files Accumulo can 
have.  Second, there is an upper bound on the number of file operations per 
second that a single namenode can support.  For example a namenode can only 
support a few thousand delete or create file request per second.  
+[BigTable's][1] design allows for its internal metadata to automatically 
spread across multiple nodes.  Accumulo has followed this design and scales 
very well as a result.  There is one impediment to scaling though, and this is 
the HDFS namenode.  There are two problems with the namenode when it comes to 
scaling.  First, the namenode stores all of its filesystem metadata in memory 
on a single machine.  This introduces an upper bound on the number of files 
Accumulo can have.  Second, there is an upper bound on the number of file 
operations per second that a single namenode can support.  For example, a 
namenode can only support a few thousand delete or create file request per 
second.  
 
-To overcome this bottleneck support for multiple namenodes was added under 
[ACCUMULO-118][ACCUMULO-118].  This change allows Accumulo to store its files 
across multiple namenodes.  To use this feature place comma separated list of 
namenode URIs in the new instance.volumes configuration property.  Modify this 
setting after a successful upgrade.
+To overcome this bottleneck, support for multiple namenodes was added under 
[ACCUMULO-118][ACCUMULO-118].  This change allows Accumulo to store its files 
across multiple namenodes.  To use this feature, place comma separated list of 
namenode URIs in the new *instance.volumes* configuration property in 
accumulo-site.xml.  When upgrading to 1.6.0 and multiple namenode support is 
desired, modify this setting **only** after a successful upgrade.
 
 ### Table namespaces
 
-Administering an Accumulo instance with lots of tables is cumbersome.  To ease 
this [ACCUMULO-802][ACCUMULO-802] introduced table namespaces which allow 
tables to be grouped.  This allows configuration and permission changes to made 
to a namespace, which will apply to all of its tables.  Example use cases are 
... TODO
+Administering an Accumulo instance with many tables is cumbersome.  To ease 
this, [ACCUMULO-802][ACCUMULO-802] introduced table namespaces which allow 
tables to be grouped into logical collections.  This allows configuration and 
permission changes to made to a namespace, which will apply to all of its 
tables.  Example use cases are ... TODO
 
 ### Conditional Mutations
 
@@ -50,11 +50,11 @@ Support for encrypting Accumulo's persis
 
 ### Pluggable compaction strategies
 
-One of the key elements of the Big Table design is use of the Log Structured 
Merge Tree (LSMT) concept.  This entails sorting data in memory, writing out 
sorted files, and then later merging multiple sorted files into a single file.  
 These automatic merges happen in the background and Accumulo decides when to 
merge files based comparing relative sizes of files to a compaction ratio.  
Adjusting the compaction ratio is the only way a user can control this process. 
 [ACCUMULO-1451][ACCUMULO-1451] introduces pluggable compaction strategies 
which allow users to choose when and what files to compact.  
[ACCUMULO-1808][ACCUMULO-1808] adds a compaction strategy the prevents 
compaction of files over a configurable size.
+One of the key elements of the [BigTable][1] design is use of the [Log 
Structured Merge Tree][2].  This entails sorting data in memory, writing out 
sorted files, and then later merging multiple sorted files into a single file.  
 These automatic merges happen in the background and Accumulo decides when to 
merge files based comparing relative sizes of files to a compaction ratio.  
Adjusting the compaction ratio is the only way a user can control this process. 
 [ACCUMULO-1451][ACCUMULO-1451] introduces pluggable compaction strategies 
which allow users to choose when and what files to compact.  
[ACCUMULO-1808][ACCUMULO-1808] adds a compaction strategy the prevents 
compaction of files over a configurable size.
 
 ### Lexicoders
 
-Accumulo only sorts data lexicographically.  Getting something like a pair of 
(<string>,<integer>) to sort correctly in Accumulo is tricky.  Its tricky 
because you only want to compare the integers if the strings are equal.  Its 
possible to make this sort properly in Accumulo if the data is encoded 
properly, but that's the tricky part.  To make this easier 
[ACCUMULO-1336][ACCUMULO-1336] added Lexicoders to the Accumulo API.  
Lexicoders provide an easy way to serialize data so that it sorts properly 
lexicographically.  Below is a simple example.
+Accumulo only sorts data lexicographically.  Getting something like a pair of 
(*String*,*Integer*) to sort correctly in Accumulo is tricky.  It's tricky 
because you only want to compare the integers if the strings are equal.  It's 
possible to make this sort properly in Accumulo if the data is encoded 
properly, but can be difficult.  To make this easier 
[ACCUMULO-1336][ACCUMULO-1336] added Lexicoders to the Accumulo API.  
Lexicoders provide an easy way to serialize data so that it sorts properly 
lexicographically.  Below is a simple example.
 
        PairLexicoder plex = new PairLexicoder(new StringLexicoder(), new 
IntegerLexicoder());
        byte[] ba1 = plex.encode(new ComparablePair<String, Integer>("b",1));
@@ -236,3 +236,7 @@ and, in HDFS High-Availability instances
 [ACCUMULO-2495]: https://issues.apache.org/jira/browse/ACCUMULO-2495 "OOM 
exception didn't bring down tserver"
 [ACCUMULO-2519]: https://issues.apache.org/jira/browse/ACCUMULO-2519 "FATE 
operation failed across upgrade"
 [ACCUMULO-2590]: https://issues.apache.org/jira/browse/ACCUMULO-2590 "Update 
public API in readme to clarify what's included"
+
+
+  [1]: http://research.google.com/archive/bigtable.html
+  [2]: 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.44.2782&rep=rep1&type=pdf
\ No newline at end of file


Reply via email to