You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@phoenix.apache.org by mu...@apache.org on 2014/03/12 20:01:10 UTC
svn commit: r1576857 - in /incubator/phoenix/site: publish/flume.html
publish/multi-tenancy.html publish/tuning.html
source/src/site/markdown/flume.md source/src/site/markdown/multi-tenancy.md
source/src/site/markdown/tuning.md
Author: mujtaba
Date: Wed Mar 12 19:01:10 2014
New Revision: 1576857
URL: http://svn.apache.org/r1576857
Log:
Updated JIRA links
Modified:
incubator/phoenix/site/publish/flume.html
incubator/phoenix/site/publish/multi-tenancy.html
incubator/phoenix/site/publish/tuning.html
incubator/phoenix/site/source/src/site/markdown/flume.md
incubator/phoenix/site/source/src/site/markdown/multi-tenancy.md
incubator/phoenix/site/source/src/site/markdown/tuning.md
Modified: incubator/phoenix/site/publish/flume.html
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/publish/flume.html?rev=1576857&r1=1576856&r2=1576857&view=diff
==============================================================================
--- incubator/phoenix/site/publish/flume.html (original)
+++ incubator/phoenix/site/publish/flume.html Wed Mar 12 19:01:10 2014
@@ -201,7 +201,7 @@
</tr>
</tbody>
</table>
- <p>For an example configuration for ingesting Apache access logs onto Phoenix, see <a class="externalLink" href="https://github.com/forcedotcom/phoenix/blob/master/src/main/config/apache-access-logs.properties">this</a> property file. Here we are using UUID as a row key generator for the primary key. </p>
+ <p>For an example configuration for ingesting Apache access logs onto Phoenix, see <a class="externalLink" href="https://git-wip-us.apache.org/repos/asf?p=incubator-phoenix.git;a=blob_plain;f=config/apache-access-logs.properties;hb=master">this</a> property file. Here we are using UUID as a row key generator for the primary key. </p>
</div>
<div class="section">
<h4 id="Starting_the_agent:">Starting the agent:</h4>
Modified: incubator/phoenix/site/publish/multi-tenancy.html
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/publish/multi-tenancy.html?rev=1576857&r1=1576856&r2=1576857&view=diff
==============================================================================
--- incubator/phoenix/site/publish/multi-tenancy.html (original)
+++ incubator/phoenix/site/publish/multi-tenancy.html Wed Mar 12 19:01:10 2014
@@ -119,7 +119,7 @@
<div class="page-header">
<h1>Multi tenancy</h1>
</div>
-<p>Support for multi-tenancy is built on top of the concepts of a <a class="externalLink" href="https://github.com/forcedotcom/phoenix/wiki/Views">VIEW</a> in Phoenix. Users create a logical tenant-specific table as a VIEW and query and update it just like with regular Phoenix tables. Data in these tenant-specific tables resides in a shared, regular Phoenix table (and thus in a shared HBase table) that is declared at table creation time to support multi-tenancy. All tenant-specific Phoenix tables whose data resides in the same physical HBase table have the same primary key structure but each tenantâs table can contain any number of non-PK columns unique to it. The main advantages afforded by this feature are:</p>
+<p>Support for multi-tenancy is built on top of the concepts of a <a href="views.html">VIEW</a> in Phoenix. Users create a logical tenant-specific table as a VIEW and query and update it just like with regular Phoenix tables. Data in these tenant-specific tables resides in a shared, regular Phoenix table (and thus in a shared HBase table) that is declared at table creation time to support multi-tenancy. All tenant-specific Phoenix tables whose data resides in the same physical HBase table have the same primary key structure but each tenantâs table can contain any number of non-PK columns unique to it. The main advantages afforded by this feature are:</p>
<ol style="list-style-type: decimal">
<li>It implements physical tenant data isolation, including automatically constraining tenants to only work with data that âbelongsâ to the each tenant.</li>
<li>It prevents a proliferation of HBase tables, minimizing operational complexity.</li>
@@ -164,7 +164,7 @@ SELECT * FROM base.event
WHERE event_type='L';
</pre>
</div>
- <p>Just like any other Phoenix view, whether or not this view is updatable is based on the rules explained <a class="externalLink" href="https://github.com/forcedotcom/phoenix/wiki/Views#wiki-updatable-views">here</a>. In addition, indexes may be added to tenant-specific tables just like with regular tables.</p>
+ <p>Just like any other Phoenix view, whether or not this view is updatable is based on the rules explained <a href="views.html#Updatable_Views">here</a>. In addition, indexes may be added to tenant-specific tables just like with regular tables.</p>
</div>
<div class="section">
<h3 id="Tenant_Data_Isolation">Tenant Data Isolation</h3>
Modified: incubator/phoenix/site/publish/tuning.html
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/publish/tuning.html?rev=1576857&r1=1576856&r2=1576857&view=diff
==============================================================================
--- incubator/phoenix/site/publish/tuning.html (original)
+++ incubator/phoenix/site/publish/tuning.html Wed Mar 12 19:01:10 2014
@@ -266,7 +266,7 @@
<br /> For example, letâs say a row key is comprised of a five digit zip code in California, declared as a CHAR(5). Phoenix only knows that the column has 5 characters. In theory, the byte array could vary from five 0x01 bytes to five 0xff bytes (or what ever is the largest valid UTF-8 encoded single byte character). While in actuality, the range is from 90001 to 96162. Since Phoenix doesnât know this, itâll divide up the region based on the theoretical range and all of the work will end up being done by the single thread that has the range encompassing the actual data. The same thing will occur with a DATE column, since the theoretical range is from 1970 to 2038, while in actuality the date is probably +/- a year from the current date. Even if Phoenix uses better defaults for the start and end range rather than the theoretical min and max, it would not usually help - thereâs just too much variability across domains.
<br />
<br /> One solution to this problem is to maintain statistics for a table to feed into the parallelization process to ensure an even data distribution. This is the solution weâre working on, as described in more detail in this
- <a class="externalLink" href="https://github.com/forcedotcom/phoenix/issues/49" target="_blank">issue</a>.
+ <a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-180" target="_blank">issue</a>.
<br />
</div>
<div class="section">
Modified: incubator/phoenix/site/source/src/site/markdown/flume.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/flume.md?rev=1576857&r1=1576856&r2=1576857&view=diff
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/flume.md (original)
+++ incubator/phoenix/site/source/src/site/markdown/flume.md Wed Mar 12 19:01:10 2014
@@ -30,7 +30,7 @@ serializer.headers | |Heade
serializer.rowkeyType | |A custom row key generator . Can be one of timestamp,date,uuid,random and nanotimestamp. This should be configured in cases where we need a custom row key value to be auto generated and set for the primary key column.
-For an example configuration for ingesting Apache access logs onto Phoenix, see [this](https://github.com/forcedotcom/phoenix/blob/master/src/main/config/apache-access-logs.properties) property file. Here we are using UUID as a row key generator for the primary key.
+For an example configuration for ingesting Apache access logs onto Phoenix, see [this](https://git-wip-us.apache.org/repos/asf?p=incubator-phoenix.git;a=blob_plain;f=config/apache-access-logs.properties;hb=master) property file. Here we are using UUID as a row key generator for the primary key.
#### Starting the agent:
$ bin/flume-ng agent -f conf/flume-conf.properties -c ./conf -n agent
Modified: incubator/phoenix/site/source/src/site/markdown/multi-tenancy.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/multi-tenancy.md?rev=1576857&r1=1576856&r2=1576857&view=diff
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/multi-tenancy.md (original)
+++ incubator/phoenix/site/source/src/site/markdown/multi-tenancy.md Wed Mar 12 19:01:10 2014
@@ -1,6 +1,6 @@
# Multi tenancy
-Support for multi-tenancy is built on top of the concepts of a [VIEW](https://github.com/forcedotcom/phoenix/wiki/Views) in Phoenix. Users create a logical tenant-specific table as a VIEW and query and update it just like with regular Phoenix tables. Data in these tenant-specific tables resides in a shared, regular Phoenix table (and thus in a shared HBase table) that is declared at table creation time to support multi-tenancy. All tenant-specific Phoenix tables whose data resides in the same physical HBase table have the same primary key structure but each tenantâs table can contain any number of non-PK columns unique to it. The main advantages afforded by this feature are:
+Support for multi-tenancy is built on top of the concepts of a [VIEW](views.html) in Phoenix. Users create a logical tenant-specific table as a VIEW and query and update it just like with regular Phoenix tables. Data in these tenant-specific tables resides in a shared, regular Phoenix table (and thus in a shared HBase table) that is declared at table creation time to support multi-tenancy. All tenant-specific Phoenix tables whose data resides in the same physical HBase table have the same primary key structure but each tenantâs table can contain any number of non-PK columns unique to it. The main advantages afforded by this feature are:
1. It implements physical tenant data isolation, including automatically constraining tenants to only work with data that âbelongsâ to the each tenant.
2. It prevents a proliferation of HBase tables, minimizing operational complexity.
@@ -40,7 +40,7 @@ Alternately, a WHERE clause may be speci
SELECT * FROM base.event
WHERE event_type='L';
-Just like any other Phoenix view, whether or not this view is updatable is based on the rules explained [here](https://github.com/forcedotcom/phoenix/wiki/Views#wiki-updatable-views). In addition, indexes may be added to tenant-specific tables just like with regular tables.
+Just like any other Phoenix view, whether or not this view is updatable is based on the rules explained [here](views.html#Updatable_Views). In addition, indexes may be added to tenant-specific tables just like with regular tables.
### Tenant Data Isolation
Any DML or query that is performed on a tenant-specific table is automatically constrained to only operate on the tenantâs data. For the upsert operation, this means that Phoenix automatically populates the tenantId column with the tenantâs id specified at connection-time. For querying and delete, a where clause is transparently added to constrain the operations to only see data belonging to the current tenant.
Modified: incubator/phoenix/site/source/src/site/markdown/tuning.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/tuning.md?rev=1576857&r1=1576856&r2=1576857&view=diff
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/tuning.md (original)
+++ incubator/phoenix/site/source/src/site/markdown/tuning.md Wed Mar 12 19:01:10 2014
@@ -99,7 +99,7 @@ This approach is not without its limitat
<br />
For example, let's say a row key is comprised of a five digit zip code in California, declared as a CHAR(5). Phoenix only knows that the column has 5 characters. In theory, the byte array could vary from five 0x01 bytes to five 0xff bytes (or what ever is the largest valid UTF-8 encoded single byte character). While in actuality, the range is from 90001 to 96162. Since Phoenix doesn't know this, it'll divide up the region based on the theoretical range and all of the work will end up being done by the single thread that has the range encompassing the actual data. The same thing will occur with a DATE column, since the theoretical range is from 1970 to 2038, while in actuality the date is probably +/- a year from the current date. Even if Phoenix uses better defaults for the start and end range rather than the theoretical min and max, it would not usually help - there's just too much variability across domains.<br />
<br />
-One solution to this problem is to maintain statistics for a table to feed into the parallelization process to ensure an even data distribution. This is the solution we're working on, as described in more detail in this <a href="https://github.com/forcedotcom/phoenix/issues/49" target="_blank">issue</a>.<br />
+One solution to this problem is to maintain statistics for a table to feed into the parallelization process to ensure an even data distribution. This is the solution we're working on, as described in more detail in this <a href="https://issues.apache.org/jira/browse/PHOENIX-180" target="_blank">issue</a>.<br />
<h4>
Batching</h4>
An important HBase configuration property <code>hbase.client.scanner.caching</code> controls scanner caching, that is how many rows are returned from the server in a single round trip when a scan is performed. Although this is less important for aggregate queries, since the Phoenix coprocessors are performing the aggregation instead of returning all the data back to the client, it is important for non aggregate queries. If unset, Phoenix defaults this property to 1000.<br />