Return-Path: X-Original-To: apmail-gora-commits-archive@www.apache.org Delivered-To: apmail-gora-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D0B4C10B4B for ; Wed, 12 Feb 2014 18:00:02 +0000 (UTC) Received: (qmail 57614 invoked by uid 500); 12 Feb 2014 18:00:02 -0000 Delivered-To: apmail-gora-commits-archive@gora.apache.org Received: (qmail 57584 invoked by uid 500); 12 Feb 2014 18:00:02 -0000 Mailing-List: contact commits-help@gora.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@gora.apache.org Delivered-To: mailing list commits@gora.apache.org Received: (qmail 57575 invoked by uid 99); 12 Feb 2014 18:00:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Feb 2014 18:00:02 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Feb 2014 17:59:58 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 2AC152388994 for ; Wed, 12 Feb 2014 17:59:37 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r897649 - in /websites/staging/gora/trunk/content: ./ current/gora-hbase.html Date: Wed, 12 Feb 2014 17:59:37 -0000 To: commits@gora.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20140212175937.2AC152388994@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: buildbot Date: Wed Feb 12 17:59:36 2014 New Revision: 897649 Log: Staging update by buildbot for gora Modified: websites/staging/gora/trunk/content/ (props changed) websites/staging/gora/trunk/content/current/gora-hbase.html Propchange: websites/staging/gora/trunk/content/ ------------------------------------------------------------------------------ --- cms:source-revision (original) +++ cms:source-revision Wed Feb 12 17:59:36 2014 @@ -1 +1 @@ -1567625 +1567702 Modified: websites/staging/gora/trunk/content/current/gora-hbase.html ============================================================================== --- websites/staging/gora/trunk/content/current/gora-hbase.html (original) +++ websites/staging/gora/trunk/content/current/gora-hbase.html Wed Feb 12 17:59:36 2014 @@ -159,28 +159,29 @@ module enables HBase documentation. - blockCache: an LRU cache that contains three levels of block priority to allow for scan-resistance and in-memory ColumnFamilies. Please see HBase documentation. - blockSize: The blocksize can be configured for each ColumnFamily in a table, and this defaults to 64k. Larger cell values require larger blocksizes. There is an inverse relationship between blocksize and the resulting StoreFile indexes (i.e., if the blocksize is doubled then the resulting indexes should be roughly halved). Please see HBase documentation. - bloomFilter: Bloom Filters can be enabled per-ColumnFamily. We use HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) to enable blooms per Column Family. Default = NONE for no bloom filters. If ROW, the hash of the row will be added to the bloom on each insert. If ROWCOL, the hash of the row + column family name + column family qualifier will be added to the bloom on each key insert. Please see HBase documentation. - maxVersions: The maximum number of row versions to store is configured per column family via HColumnDescriptor. The default for max versions is 3. This is an important parameter because HBase does not overwrite row values, but rather stores different values per row by time (and qualifier). Excess versions are removed during major compaction's. The number of max versions may need to be increased or decreased depending on application needs. Please see HBase documentation. - timeToLive: ColumnFamilies can set a TTL length in seconds, and HBase will automatically delete rows once the expiration time is reached. This applies to all versions of a row - even the current one. The TTL time encoded in the HBase for the row is specified in UTC. Please see HBase documentation. - inMemory: ColumnFamilies can optionally be defined as in-memory. Data is still persisted to disk, just like any other ColumnFamily. In-memory blocks have the highest priority in the Block Cache, but it is not a guarantee that the entire table will be in memory. Please see HBase documentation. -2. Specification of persistent fields which values should map to; - the Persistent class name e.g. org.apache.gora.examples.generated.Employee, - the keyClass e.g. java.lang.String which specifies the keys which map to the field -values, - the Table e.g. Employee which matches to the above Table definition, - finally fields which are to be persisted into HBase need to be configured such that they +gora-orm mapping configuration, namely;

+
    +
  1. The table element; where we specify:
    2. +
  2. the HBase table name e.g. Employee,
    3. +
  3. the type and definition of families we wish to create within HBase. In this case we create one family which could have a combination of any of the following characteristics;
    4. +
  4. name: family name e.g. info
    5. +
  5. compression: the compression option to use in HBase. Please see HBase documentation.
    6. +
  6. blockCache: an LRU cache that contains three levels of block priority to allow for scan-resistance and in-memory ColumnFamilies. Please see HBase documentation.
    7. +
  7. blockSize: The blocksize can be configured for each ColumnFamily in a table, and this defaults to 64k. Larger cell values require larger blocksizes. There is an inverse relationship between blocksize and the resulting StoreFile indexes (i.e., if the blocksize is doubled then the resulting indexes should be roughly halved). Please see HBase documentation.
    8. +
  8. bloomFilter: Bloom Filters can be enabled per-ColumnFamily. We use HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) to enable blooms per Column Family. Default = NONE for no bloom filters. If ROW, the hash of the row will be added to the bloom on each insert. If ROWCOL, the hash of the row + column family name + column family qualifier will be added to the bloom on each key insert. Please see HBase documentation.
    9. +
  9. maxVersions: The maximum number of row versions to store is configured per column family via HColumnDescriptor. The default for max versions is 3. This is an important parameter because HBase does not overwrite row values, but rather stores different values per row by time (and qualifier). Excess versions are removed during major compaction's. The number of max versions may need to be increased or decreased depending on application needs. Please see HBase documentation.
    10. +
  10. timeToLive: ColumnFamilies can set a TTL length in seconds, and HBase will automatically delete rows once the expiration time is reached. This applies to all versions of a row - even the current one. The TTL time encoded in the HBase for the row is specified in UTC. Please see HBase documentation.
    11. +
  11. inMemory: ColumnFamilies can optionally be defined as in-memory. Data is still persisted to disk, just like any other ColumnFamily. In-memory blocks have the highest priority in the Block Cache, but it is not a guarantee that the entire table will be in memory. Please see HBase documentation.
    12. +
  12. Specification of persistent fields which values should map to;
    13. +
  13. the Persistent class name e.g. org.apache.gora.examples.generated.Employee,
    14. +
  14. the keyClass e.g. java.lang.String which specifies the keys which map to the field +values,
    15. +
  15. the Table e.g. Employee which matches to the above Table definition,
    16. +
  16. finally fields which are to be persisted into HBase need to be configured such that they receive a name e.g. (name, dateOfBirth, ssn and salary respectively), the column family to which they belong e.g. (all info in this case) and an additional qualifier, which enables -more granular control over the data to be persisted into HBase.

    +more granular control over the data to be persisted into HBase.
    17. +