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/01/31 21:42:04 UTC
svn commit: r1563252 [6/6] - in /incubator/phoenix: ./ site/publish/
site/publish/language/ site/source/ site/source/src/ site/source/src/site/
site/source/src/site/bin/ site/source/src/site/markdown/
site/source/src/site/resources/ site/source/src/sit...
Added: incubator/phoenix/site/source/src/site/markdown/phoenix_on_emr.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/phoenix_on_emr.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/phoenix_on_emr.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/phoenix_on_emr.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,43 @@
+# Phoenix on Amazon EMR
+
+Follow these steps to deploy HBase with Phoenix on Amazon's Elastic MapReduce (EMR).
+
+### 1. Amazon EMR Configuration
+
+1. Create a free/paid [EMR account](https://portal.aws.amazon.com/gp/aws/developer/registration/index.html)
+2. [Download](http://aws.amazon.com/developertools/2264) the latest CLI from and follow the setup instructions [here](http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-cli-install.html).
+
+_Note: Step 2 is a multi-step process in which you would install ruby, gem, create credentials file and create a S3 bucket._
+
+### 2. Deploy HBase with Phoenix on EMR using Web Console
+
+##### Using Web Console
+
+Go to _Elastic MapReduce > Create Cluster_ and follow the steps listed below:
+
+
+
+1. Type your cluster name
+2. Set _AMI version_ to _3.0.1_
+3. From _Additional Application_ drop down, select HBase and add.
+4. In _Core_ text box, enter the number of HBase region server(s) you want configured for your cluster
+5. Add a _custom action bootstrap_ from dropdown and specify S3 location: ``s3://beta.elasticmapreduce/bootstrap-actions/phoenix/install-phoenix-bootstrap.sh`` and click add.
+6. Click _Create Cluster_
+
+##### Using CLI
+
+Instead of using _Web Console_, you may use following _CLI_ command to deploy _HBase_ with _Phoenix_:
+
+ ```
+./elastic-mapreduce --create --instance-type c1.xlarge --name
+PHOENIX_2.2_install --ami-version 3.0.1 --hbase --alive --bootstrap-action
+"s3://beta.elasticmapreduce/bootstrap-actions/phoenix/install-phoenix-bootstrap.sh"
+```
+
+### 3. Usage
+
+_SSH_ to the _EMR Master_ and CD to _/home/hadoop/hbase/lib/phoenix/bin_
+
+Create test data: ``./performance localhost 1000000 ``
+
+SQL CLI: ``./sqlline localhost``
Added: incubator/phoenix/site/source/src/site/markdown/recent.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/recent.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/recent.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/recent.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,20 @@
+# New Features
+
+As items are implemented from our road map, they are moved here to track the progress we've made:
+
+1. **Joins**. Join support through hash joins (where one side of the query is small enough to fit into memory). **Available in our master branch and will be in our 3.0 release**
+2. **[Views](http://phoenix.incubator.apache.org/views.html)**. Allows the creation of multiple tables using the same physical HBase table. **Available in master branch and will be in our 3.0 release**
+3. **[Multi-tenancy](http://phoenix.incubator.apache.org/multi_tenancy.html)**. Allows independent views to be created by different tenants on a per-connection basis that all share the same physical HBase table. **Available in master branchand will be available in our 3.0 release**
+2. **[Sequences](http://phoenix.incubator.apache.org/sequences.html)**. Support for CREATE/DROP SEQUENCE, NEXT VALUE FOR, and CURRENT VALUE FOR has been implemented. **Available in our master branch and will be available in our 3.0 release**
+4. **ARRAY support**. ARRAY support through the standard SQL syntax. **Available in our master branch and will be available in our 3.0 release**
+1. **[Secondary Indexes](secondary_indexing.html)**. Allows users to create indexes over mutable or immutable data through a new `CREATE INDEX` DDL command. Behind the scenes, Phoenix creates a separate HBase table with a different row key for the index. At query time, Phoenix takes care of choosing the best table to use based on how much of the row key can be formed. We support getting at the uncommitted <code>List<KeyValue></code> for both the data and the index tables to allow an HFile to be built without needing an HBase connection using the "connectionless" of our JDBC driver.
+2. **Row Value Constructors**. A standard SQL construct to efficiently locate the row at or after a composite key value. Enables a query-more capability to efficiently step through your data and optimizes IN list of composite key values to be point gets.
+3. **[Map-reduce-based CSV Bulk Loader](mr_dataload.html)** Builds Phoenix-compliant HFiles and load them into HBase.
+2. **Aggregation Enhancements**. <code>COUNT DISTINCT</code>, <code>PERCENTILE</code>, and <code>STDDEV</code> are now supported.
+4. **Type Additions**. The <code>FLOAT</code>, <code>DOUBLE</code>, <code>TINYINT</code>, and <code>SMALLINT</code> are now supported.
+2. **IN/OR/LIKE Optimizations**. When an IN (or the equivalent OR) and a LIKE appears in a query using the leading row key columns, compile it into a skip scanning filter to more efficiently retrieve the query results.
+3. **Support ASC/DESC declaration of primary key columns**. Allow a primary key column to be declared as ascending (the default) or descending such that the row key order can match the desired sort order (thus preventing an extra sort).
+3. **Salting Row Key**. To prevent hot spotting on writes, the row key may be *"salted"* by inserting a leading byte into the row key which is a mod over N buckets of the hash of the entire row key. This ensures even distribution of writes when the row key is a monotonically increasing value (often a timestamp representing the current time).
+4. **TopN Queries**. Support a query that returns the top N rows, through support for ORDER BY when used in conjunction with TopN.
+6. **Dynamic Columns**. For some use cases, it's difficult to model a schema up front. You may have columns that you'd like to specify only at query time. This is possible in HBase, in that every row (and column family) contains a map of values with keys that can be specified at run time. So, we'd like to support that.
+7. **Phoenix package for the Apache Bigtop distribution**. See [BIGTOP-993](http://issues.apache.org/jira/browse/BIGTOP-993) for more information.
Added: incubator/phoenix/site/source/src/site/markdown/roadmap.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/roadmap.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/roadmap.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/roadmap.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,36 @@
+# Roadmap
+
+#### Note: Issues on Github would be converted to JIRAs soon.
+
+Our roadmap is driven by our user community. Below, in prioritized order, is the current plan for Phoenix:
+
+1. **Hash Joins**. Provide the ability to join together multiple tables, through a phased approach:
+ <br/>**[Equi-join](https://github.com/forcedotcom/phoenix/issues/20)**. Support left, right, inner, outer equi-joins where one side of the join is small enough to fit into memory. **Available in master branch**
+ <br/>**[Semi/anti-join](https://github.com/forcedotcom/phoenix/issues/36)**. Support correlated sub queries for exists and in where one side of the join is small enough to fit into memory.
+2. **[Views](http://phoenix.incubator.apache.org/views.html)**. Allows the creation of multiple tables using the same physical HBase table. **Available in master branch**
+3. **[Multi-tenancy](http://phoenix.incubator.apache.org/multi_tenancy.html)**. Allows independent views to be created by different tenants on a per-connection basis that all share the same physical HBase table. **Available in master branch**
+4. **[Sequences](http://phoenix.incubator.apache.org/sequences.html)**. Support the atomic increment of sequence values through the CREATE SEQUENCE and the NEXT VALUE FOR statements.
+5. **Type Enhancements**. Additional work includes support for [DEFAULT declaration](https://github.com/forcedotcom/phoenix/issues/345) when creating a table, for [ARRAY](https://github.com/forcedotcom/phoenix/issues/178) (**available in master branch**), [STRUCT](https://github.com/forcedotcom/phoenix/issues/346), and [JSON](https://github.com/forcedotcom/phoenix/issues/497) data types.
+6. **Third Party Integration**. There are a number of open source projects with which interop with Phoenix could be added or improved:
+ <br/> **[Flume sink](https://github.com/forcedotcom/phoenix/issues/225)**. Support a Flume sink that writes Phoenix-compliant HBase data. **Available in master branch**
+ <br/> **[Hue integration](https://github.com/forcedotcom/phoenix/issues/224)**. Add Phoenix as an HBase service layer in Hue.
+ <br/> **[Pentaho Mondrian support](https://github.com/forcedotcom/phoenix/issues/512)**. Allow Phoenix to be used as the JDBC driver for Pentaho Mondrian. **This effort is pretty far along already, with the Pentaho FoodMart demo running through Phoenix now**
+ <br/> **[Cleanup Pig support](https://github.com/forcedotcom/phoenix/issues/499)** . Commonize the functions we use across Map-reduce and Pig processing. We should also upgrade our pom to reference the 0.12 version of Pig and map our DECIMAL type to their new decimal type.
+ <br/> **[Improve Map-reduce integration](https://github.com/forcedotcom/phoenix/issues/556)**. It's possible that we could provide a processing model where the map and reduce functions can invoke Phoenix queries (though this needs some more thought).
+7. **[Derived Tables](https://github.com/forcedotcom/phoenix/issues/5)**. Allow a <code>SELECT</code> clause to be used in the FROM clause to define a derived table. This would include support for pipelining queries when necessary.
+8. **[Functional Indexes](https://github.com/forcedotcom/phoenix/issues/383)**. Enables an index to contain the evaluation of an expression as opposed to just a column value.
+9. **[Monitoring and Management](https://github.com/forcedotcom/phoenix/issues/46)**. Provide visibility into cpu, physical io, logical io, wait time, blocking time, and transmission time spent for each thread of execution across the HBase cluster, within coprocessors, and within the client-side thread pools for each query. On top of this, we should exposing things like active sessions and currently running queries. The [EXPLAIN PLAN](http://forcedotcom.github.io/phoenix/#explain) gives an idea of how a query will be executed, but we need more information to help users debug and tune their queries.
+10. **[Parent/child Join](https://github.com/forcedotcom/phoenix/issues/19)**. Unlike with standard relational databases, HBase allows you the flexibility of dynamically creating as many key values in a row as you'd like. Phoenix could leverage this by providing a way to model child rows inside of a parent row. The child row would be comprised of the set of key values whose column qualifier is prefixed with a known name and appended with the primary key of the child row. Phoenix could hide all this complexity, and allow querying over the nested children through joining to the parent row. Essentially, this would be an optimization of the general join case, but could support cases where both sides of the join are bigger than would fit into memory.
+ <br/> **[Intra-row secondary indexes](https://github.com/forcedotcom/phoenix/issues/585)**. Once we support putting multiple "virtual" rows inside of a HBase row as prefixed KeyValues, we can support intra-row secondary indexes without much more effort.
++12. **[Port to HBase 0.96](https://github.com/forcedotcom/phoenix/issues/349)**. Currently Phoenix only works on the 0.94 branch of HBase. The latest branch of HBase is now 0.96, which has many breaking, non backward compatible changes (for example requiring that EndPoint coprocessors use protobufs). Ideally, we should create a shim that'll allow Phoenix to work with both 0.94 and 0.96, but barring that, we should have a branch of Phoenix that works under 0.96. Additional work includes replacing our type system with the new HBase type system in 0.96, but that would be significantly more work.
+5. **Security Features**. A number of existing HBase security features in 0.94 could be leverage and new security features being added to 0.98 could be leveraged in the future.
+ <br/> **[Support GRANT and REVOKE](https://github.com/forcedotcom/phoenix/issues/541)**. Support the standard GRANT and REVOKE SQL commands through an HBase AccessController.
+ <br/> **[Surface support for encryption] (https://github.com/forcedotcom/phoenix/issues/542)**. In HBase 0.98, transparent encryption will be possible. We should surface this in Phoenix.
+ <br/> **[Support Cell-level security](https://github.com/forcedotcom/phoenix/issues/553)**. In HBase 0.98, it will be possible to apply labels at a per-cell granularity. We should surface this in Phoenix.
+7. **Cost-based Optimizer**. Once secondary indexing and joins are implemented, we'll need to [collect and maintains stats](https://github.com/forcedotcom/phoenix/issues/64) and [drive query optimization decisions based on them](https://github.com/forcedotcom/phoenix/issues/49) to produce the most efficient query plan.
+8. **[Query over Multiple Row Versions](https://github.com/forcedotcom/phoenix/issues/459)**. Expose the time dimension of rows through a built-in function to allow aggregation and trending over multiple row versions.
+8. **[OLAP Extensions](https://github.com/forcedotcom/phoenix/issues/23)**. Support the `WINDOW`, `PARTITION OVER`, `RANK`, etc. functionality.
+10. **[Table Sampling](https://github.com/forcedotcom/phoenix/issues/22)**. Support the <code>TABLESAMPLE</code> clause by implementing a filter that uses the guideposts established by stats gathering to only return n rows per region.
+13. **Nested-loop Join**. Support joins where both sides are big enough that they wouldn't fit into memory. As projects like [Apache Drill](http://incubator.apache.org/drill/) progress, the need for this may lessen, since these systems will be able to decompose the query and perform the join efficiently without Phoenix needing to as described [here](http://www.hbasecon.com/sessions/apache-drill-a-community-driven-initiative-to-deliver-ansi-sql-capabilities-for-apache-hbase-1210pm-1230pm/).
+11. **Schema Evolution**. Phoenix supports adding and removing columns through the [ALTER TABLE] (language/index.html#alter_table) DDL command, but changing the data type of, or renaming, an existing column is not yet supported.
+12. **[Transactions](https://github.com/forcedotcom/phoenix/issues/269?source=cc)**. Support transactions by integrating a system that controls time stamps like [OMID](https://github.com/yahoo/omid). For some ideas on how this might be done, see [here](https://github.com/forcedotcom/phoenix/issues/269).
Added: incubator/phoenix/site/source/src/site/markdown/salted.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/salted.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/salted.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/salted.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,25 @@
+# Salted Tables
+
+HBase sequential write may suffer from region server hotspotting if your row key is monotonically increasing. Salting the row key provides a way to mitigate the problem. Details of the method would be found on [this link](http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/).
+
+Phoenix provides a way to transparently salt the row key with a salting byte for a particular table. You need to specify this in table creation time by specifying a table property "SALT_BUCKETS" with a value from 1 to 256. Like this:
+
+CREATE TABLE table (a_key VARCHAR PRIMARY KEY, a_col VARCHAR) SALT_BUCKETS = 20;
+
+There are some cautions and difference in behavior you should be aware about when using a salted table.
+
+### Sequential Scan
+Since salting table would not store the data sequentially, a strict sequential scan would not return all the data in the natural sorted fashion. Clauses that currently would force a sequential scan, for example, clauses with LIMIT, would likely to return items that are different from a normal table.
+
+### Splitting
+If no split points are specified for the table, the salted table would be pre-split on salt bytes boundaries to ensure load distribution among region servers even during the initial phase of the table. If users are to provide split points manually, users need to include a salt byte in the split points they provide.
+
+### Row Key Ordering
+Pre-spliting also ensures that all entries in the region server all starts with the same salt byte, and therefore are stored in a sorted manner. When doing a parallel scan across all region servers, we can take advantage of this properties to perform a merge sort of the client side. The resulting scan would still be return sequentially as if it is from a normal table.
+
+This Rowkey order scan can be turned on by setting the <code>phoenix.query.rowKeyOrderSaltedTable</code> config property to <code>true</code> in your hbase-sites.xml. When set, we disallow user specified split points on salted table to ensure that each bucket will only contains entries with the same salt byte. When this property is turned on, the salted table would behave just like a normal table and would return items in rowkey order for scans.
+
+### Performance
+Using salted table with pre-split would help uniformly distribute write workload across all the region servers, thus improves the write performance. Our own [performance evaluation](performance.html#Salting) shows that a salted table achieves 80% write throughput increases over non-salted table.
+
+Reading from salted table can also reap benefits from the more uniform distribution of data. Our [performance evaluation](performance.html#Salting) shows much improved read performances on read queries with salted table over non-salted table when we focus our query on a subset of the data.
Added: incubator/phoenix/site/source/src/site/markdown/secondary_indexing.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/secondary_indexing.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/secondary_indexing.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/secondary_indexing.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,152 @@
+# Secondary Indexing
+
+Secondary indexes are an orthogonal way to access data from its primary access path. In HBase, you have a single index that is lexicographically sorted on
+the primary row key. Access to records in any way other than through the primary row requires scanning over potentially all the rows in the table to test them against your filter. With secondary indexing, the columns you index form an alternate row key to allow point lookups and range scans along this new axis. Phoenix is particularly powerful in that we provide _covered_ indexes - we do not need to go back to the primary table once we have found the index entry. Instead, we bundle the data we care about right in the index rows, saving read-time overhead.
+
+Phoenix supports two main forms of indexing: mutable and immutable indexing. They are useful in different scenarios and have their own failure profiles and performance characteristics. Both indexes are 'global' indexes - they live on their own tables and are copies of primary table data, which Phoenix ensures remain in-sync.
+
+# Mutable Indexing
+
+Often, the rows you are inserting are changing - pretty much any time you are not doing time-series data. In this case, use mutable indexing to ensure that your index is properly maintained as your data changes.
+
+All the performance penalties for indexes occur at write time. We intercept the primary table updates on write ([DELETE](language/index.html#delete), [UPSERT VALUES](language/index.html#upsert_values) and [UPSERT SELECT](language/index.html#upsert_select)), build the index update and then sent any necessary updates to all interested index tables. At read time, Phoenix will select the index table to use that will produce the fastest query time and directly scan it just like any other HBase table.
+
+## Example
+
+Given the schema shown here:
+
+ CREATE TABLE my_table (k VARCHAR PRIMARY KEY, v1 VARCHAR, v2 BIGINT);
+you'd create an index on the v1 column like this:
+
+ CREATE INDEX my_index ON my_table (v1);
+A table may contain any number of indexes, but note that your write speed will drop as you add additional indexes.
+
+We can also include columns from the data table in the index apart from the indexed columns. This allows an index to be used more frequently, as it will only be used if all columns referenced in the query are contained by it.
+
+ CREATE INDEX my_index ON my_table (v1) INCLUDE (v2);
+In addition, multiple columns may be indexed and their values may be stored in ascending or descending order.
+
+ CREATE INDEX my_index ON my_table (v2 DESC, v1) INCLUDE (v3);
+Finally, just like with the <code>CREATE TABLE</code> statement, the <code>CREATE INDEX</code> statement may pass through properties to apply to the underlying HBase table, including the ability to salt it:
+
+ CREATE INDEX my_index ON my_table (v2 DESC, v1) INCLUDE (v3)
+ SALT_BUCKETS=10, DATA_BLOCK_ENCODING='NONE';
+Note that if the primary table is salted, then the index is automatically salted in the same way. In addition, the MAX_FILESIZE for the index is adjusted down, relative to the size of the primary versus index table. For more on salting see [here](salted.html).
+
+# Immutable Indexing
+
+Immutable indexing targets use cases that are _write once_, _append only_; this is common in time-series data, where you log once, but read multiple times. In this case, the indexing is managed entirely on the client - either we successfully write all the primary and index data or we return a failure to the client. Since once written, rows are never updated, no incremental index maintenance is required. This reduces the overhead of secondary indexing at write time. However, keep in mind that immutable indexing are only applicable in a limited set of use cases.
+
+## Example
+
+To use immutable indexing, supply an <code>IMMUTABLE_ROWS=true</code> property when you create your table like this:
+
+ CREATE TABLE my_table (k VARCHAR PRIMARY KEY, v VARCHAR) IMMUTABLE_ROWS=true;
+
+Other than that, all of the previous examples are identical for immutable indexing.
+
+If you have an existing table that you'd like to switch from immutable indexing to mutable indexing, use the <code>ALTER TABLE</code> command as show below:
+
+ ALTER TABLE my_table SET IMMUTABLE_ROWS=false;
+For the complete syntax, see our [Language Reference Guide](language/index.html#create_index).
+
+## Data Guarantees and Failure Management
+
+On successful return to the client, all data is guaranteed to be written to all interested indexes and the primary table. For each individual data row, updates are an all-or-nothing, with a small gap of being behind. From the perspective of a single client, it either thinks all-or-none of the update worked.
+
+We maintain index update durability by adding the index updates to the Write-Ahead-Log (WAL) entry of the primary table row. Only after the WAL entry is successfully synced to disk do we attempt to make the index/primary table updates. We write the index updates in parallel by default, leading to very high throughput. If the server crashes while we are writing the index updates, we replay the all the index updates to the index tables in the WAL recovery process and rely on the idempotence of the updates to ensure correctness. Therefore, index tables are only every a single edit ahead of the primary table.
+
+Its important to note several points:
+ * We _do not provide full transactions_ so you could see the index table out of sync with the primary table.
+ * As noted above, this is ok as we are only a very small bit ahead and out of sync for very short periods
+ * Each data row and its index row(s) are guaranteed to to be written or lost - we never see partial updates
+ * All data is first written to index tables before the primary table
+
+### Singular Write Path
+
+There is a single write path that guarantees the failure properties. All writes to the HRegion get intercepted by our coprocessor. We then build the index updates based on the pending update (or updates, in the case of the batch). These update are then appended to the WAL entry for the original update.
+
+If we get any failure up to this point, we return the failure to the client and no data is persisted or made visible to the client.
+
+Once the WAL is written, we ensure that the index and primary table data will become visible, even in the case of a failure.
+ * If the server does _not_ crash, we just insert the index updates to their respective tables.
+ * If the server _does_ crash, we then replay the index updates with the usual WAL replay mechanism
+ ** If any of the index updates fails, we then fail the server, ensuring we get the WAL replay of the updates later.
+
+### Failure Policy
+
+In the event that the region server handling the data updates cannot write to the region server handling the index updates, the index is automatically disabled and will no longer be considered for use in queries (as it will no longer be in sync with the data table). To use it again, it must be manually rebuilt with the following command:
+
+```
+ALTER INDEX my_index ON my_table REBUILD;
+```
+
+If we cannot disable the index, then the server will be immediately aborted. If the abort fails, we call System.exit on the JVM, forcing the server to die. By killing the server, we ensure that the WAL will be replayed on recovery, replaying the index updates to their appropriate tables.
+
+**WARNING: indexing has the potential to bring down your entire cluster very quickly.**
+
+If the index tables are not setup correctly (Phoenix ensures that they are), this failure policy can cause a cascading failure as each region server attempts and fails to write the index update, subsequently killing itself to ensure the visibility concerns outlined above.
+
+## Setup
+
+Only mutable indexing requires special configuration options in the region server to run - phoenix ensures that they are setup correctly when you enable mutable indexing on the table; if the correct properties are not set, you will not be able to turn it on.
+
+You will need to add the following parameters to `hbase-site.xml`:
+```
+<property>
+ <name>hbase.regionserver.wal.codec</name>
+ <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value>
+</property>
+```
+
+This enables custom WAL edits to be written, ensuring proper writing/replay of the index updates. This codec supports the usual host of WALEdit options, most notably WALEdit compression.
+
+## Tuning
+Out the box, indexing is pretty fast. However, to optimize for your particular environment and workload, there are several properties you can tune.
+
+All the following parameters must be set in `hbase-site.xml` - they are true for the entire cluster and all index tables, as well as across all regions on the same server (so, for instance, a single server would not write to too many different index tables at once).
+
+1. index.builder.threads.max
+ * Number of threads to used to build the index update from the primary table update
+ * Increasing this value overcomes the bottleneck of reading the current row state from the underlying HRegion. Tuning this value too high will just bottleneck at the HRegion as it will not be able to handle too many concurrent scan requests as well as general thread-swapping concerns.
+ * **Default: 10**
+
+2. index.builder.threads.keepalivetime
+ * Amount of time in seconds after we expire threads in the builder thread pool.
+ * Unused threads are immediately released after this amount of time and not core threads are retained (though this last is a small concern as tables are expected to sustain a fairly constant write load), but simultaneously allows us to drop threads if we are not seeing the expected load.
+ * **Default: 60**
+
+3. index.writer.threads.max
+ * Number of threads to use when writing to the target index tables.
+ * The first level of parallelization, on a per-table basis - it should roughly correspond to the number of index tables
+ * **Default: 10**
+
+4. index.writer.threads.keepalivetime
+ * Amount of time in seconds after we expire threads in the writer thread pool.
+ * Unused threads are immediately released after this amount of time and not core threads are retained (though this last is a small concern as tables are expected to sustain a fairly constant write load), but simultaneously allows us to drop threads if we are not seeing the expected load.
+ * **Default: 60**
+
+5. hbase.htable.threads.max
+ * Number of threads each index HTable can use for writes.
+ * Increasing this allows more concurrent index updates (for instance across batches), leading to high overall throughput.
+ * **Default: 2,147,483,647**
+
+6. hbase.htable.threads.keepalivetime
+ * Amount of time in seconds after we expire threads in the HTable's thread pool.
+ * Using the "direct handoff" approach, new threads will only be created if it is necessary and will grow unbounded. This could be bad but HTables only create as many Runnables as there are region servers; therefore, it also scales when new region servers are added.
+ * **Default: 60**
+
+7. index.tablefactory.cache.size
+ * Number of index HTables we should keep in cache.
+ * Increasing this number ensures that we do not need to recreate an HTable for each attempt to write to an index table. Conversely, you could see memory pressure if this value is set too high.
+ * **Default: 10**
+
+# Performance
+We track secondary index performance via our [performance framework](http://phoenix-bin.github.io/client/performance/latest.htm). This is a generic test of performance based on defaults - your results will vary based on hardware specs as well as you individual configuration.
+
+That said, we have seen secondary indexing (both immutable and mutable) go as quickly as < 2x the regular write path on a small, (3 node) desktop-based cluster. This is actually a phenomenal as we have to write to multiple tables as well as build the index update.
+
+# Presentations
+There have been several presentations given on how secondary indexing works in Phoenix that have a more indepth look at how indexing works (with pretty pictures!):
+ * [San Francisco HBase Meetup](http://files.meetup.com/1350427/PhoenixIndexing-SF-HUG_09-26-13.pptx) - Sept. 26, 2013
+ * [Los Anglees HBase Meetup](http://www.slideshare.net/jesse_yates/phoenix-secondary-indexing-la-hug-sept-9th-2013) - Sept, 4th, 2013
Added: incubator/phoenix/site/source/src/site/markdown/sequences.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/sequences.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/sequences.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/sequences.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,47 @@
+# Sequences
+
+Sequences are a standard SQL feature that allow for generating monotonically increasing numbers typically used to form an ID. To create a sequence, use the following command:
+
+ CREATE SEQUENCE my_schema.my_sequence;
+
+This will start the sequence from 1, increment by 1 each time, and cache on your session the default number of sequence values based on the phoenix.sequence.cacheSize config parameter. The specification of a sequence schema is optional. Caching sequence values on your session improves performance, as we don't need to ask the server for more sequence values until we run out of cached values. The tradeoff is that you may end up with gaps in your sequence values when other sessions also use the same sequence.
+
+All of these parameters can be overridden when the sequence is created like this:
+
+ CREATE SEQUENCE my_schema.my_sequence START WITH 100 INCREMENT BY 2 CACHE 50;
+
+Sequences are incremented using the NEXT VALUE FOR <sequence_name> expression in an UPSERT VALUES, UPSERT SELECT, or SELECT statement as shown below:
+
+ UPSERT VALUES INTO my_table(id, col1, col2)
+ VALUES( NEXT VALUE FOR my_schema.my_sequence, 'foo', 'bar');
+
+This will allocate a BIGINT based on the next value from the sequence (beginning with the START WITH value and incrementing from there based on the INCREMENT BY amount).
+
+When used in an UPSERT SELECT or SELECT statement, each row returned by the statement would have a unique value associated with it. For example:
+
+ UPSERT INTO my_table(id, col1, col2)
+ SELECT NEXT VALUE FOR my_schema.my_sequence, 'foo', 'bar' FROM my_other_table;
+
+would allocate a new sequence value for each row returned from the SELECT expression. A sequence is only increment once for a given statement, so multiple references to the same sequence by NEXT VALUE FOR produce the same value. For example, in the following statement, my_table.col1 and my_table.col2 would end up with the same value:
+
+ UPSERT VALUES INTO my_table(col1, col2)
+ VALUES( NEXT VALUE FOR my_schema.my_sequence, NEXT VALUE FOR my_schema.my_sequence);
+
+You may also access the last sequence value allocated using a CURRENT VALUE FOR expression as shown below:
+
+ SELECT CURRENT VALUE FOR my_schema.my_sequence, col1, col2 FROM my_table;
+
+This would evaluate to the last sequence value allocated from the previous NEXT VALUE FOR expression for your session (i.e. all connections on the same JVM for the same client machine). If no NEXT VALUE FOR expression had been previously called, this would produce an exception. If in a given statement a CURRENT VALUE FOR expression is used together with a NEXT VALUE FOR expression for the same sequence, then both would evaluate to the value produced by the NEXT VALUE FOR expression.
+
+The NEXT VALUE FOR and CURRENT VALUE FOR expressions may only be used as SELECT expressions or in the UPSERT VALUES statement. Use in WHERE, GROUP BY, HAVING, or ORDER BY will produce an exception. In addition, they cannot be used as the argument to an aggregate function.
+
+To drop a sequence, issue the following command:
+
+ DROP SEQUENCE my_schema.my_sequence;
+
+To discover all sequences that have been created, you may query the SYSTEM.SEQUENCE table as shown here:
+
+ SELECT sequence_schema, sequence_name, start_with, increment_by, cache_size FROM SYSTEM."SEQUENCE";
+
+Note that only read-only access to the SYSTEM.SEQUENCE table is supported.
+
Added: incubator/phoenix/site/source/src/site/markdown/skip_scan.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/skip_scan.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/skip_scan.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/skip_scan.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,22 @@
+# Skip Scan
+
+Phoenix uses Skip Scan for intra-row scanning which allows for [significant performance improvement](performance.html#Skip-Scan) over Range Scan when rows are retrieved based on a given set of keys.
+
+The Skip Scan leverages <code>SEEK_NEXT_USING_HINT</code> of HBase Filter. It stores information about what set of keys/ranges of keys are being searched for in each column. It then takes a key (passed to it during filter evaluation), and figures out if it's in one of the combinations or range or not. If not, it figures out to which next highest key to jump.
+
+Input to the <code>SkipScanFilter</code> is a <code>List<List<KeyRange>></code> where the top level list represents each column in the row key (i.e. each primary key part), and the inner list represents ORed together byte array boundaries.
+
+
+Consider the following query:
+
+ SELECT * from T
+ WHERE ((KEY1 >='a' AND KEY1 <= 'b') OR (KEY1 > 'c' AND KEY1 <= 'e'))
+ AND KEY2 IN (1, 2)
+
+The <code>List<List<KeyRange>></code> for <code>SkipScanFilter</code> for the above query would be [ [ [ a - b ], [ d - e ] ], [ 1, 2 ] ] where [ [ a - b ], [ d - e ] ] is the range for <code>KEY1</code> and [ 1, 2 ] keys for <code>KEY2</code>.
+
+The following diagram illustrates graphically how the skip scan is able to jump around the key space:
+
+
+
+
Added: incubator/phoenix/site/source/src/site/markdown/source.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/source.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/source.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/source.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,13 @@
+# Source Repository
+
+Apache Phoenix source is available on Apache Git server:
+
+https://git-wip-us.apache.org/repos/asf/incubator-phoenix.git
+
+<hr/>
+
+Mirror on Github: https://github.com/apache/incubator-phoenix
+
+<hr/>
+
+Related: [Using > Building](building.html)
Added: 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=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/tuning.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/tuning.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,128 @@
+# Configuration and Tuning
+
+Phoenix provides many different knobs and dials to configure and tune the system to run more optimally on your cluster. The configuration is done through a series of Phoenix-specific properties specified for the most part in your client-side <code>hbase-site.xml</code> file. In addition to these properties, there are of course all the <a href="http://hbase.apache.org/book/config.files.html" target="_blank">HBase configuration</a> properties with the most important ones documented <a href="http://hbase.apache.org/book/important_configurations.html" target="_blank">here</a>. This blog will focus on the Phoenix-specific properties and touch on some important considerations to maximize Phoenix and HBase performance.<br />
+<br />
+The table below outlines the full set of Phoenix-specific configuration properties and their defaults. Of these, we'll talk in depth about some of the most important ones below.<br />
+<br />
+<table border="1">
+ <tbody>
+<tr><td><b>Property</b></td><td><b>Description</b></td><td><b>Default
+</b></td></tr>
+<tr><td><small>phoenix.query.timeoutMs</small></td><td style="text-align: left;">Number of milliseconds
+ after which a query will timeout on the client. Default is 10 min.</td><td>600000
+</td></tr>
+<tr><td><small>phoenix.query.keepAliveMs</small></td><td style="text-align: left;">When the number of
+ threads is greater than the core in the client side thread pool
+ executor, this is the maximum time in milliseconds that excess idle
+ threads will wait for a new tasks before
+terminating. Default is 60 sec.</td><td>60000</td></tr>
+<tr><td><small>phoenix.query.threadPoolSize</small></td><td style="text-align: left;">Number of threads
+ in client side thread pool executor. As the number of machines/cores
+ in the cluster grows, this value should be
+increased.</td><td>128</td></tr>
+<tr><td><small>phoenix.query.queueSize</small></td><td>Max queue depth
+of the
+ bounded round robin backing the client side thread pool executor,
+ beyond which an attempt to queue additional work is
+ rejected by throwing an exception. If zero, a SynchronousQueue is used
+ instead of the bounded round robin queue.</td><td>500</td></tr>
+<tr><td><small>phoenix.query.spoolThresholdBytes</small></td><td style="text-align: left;">Threshold
+ size in bytes after which results from parallelly executed
+ query results are spooled to disk. Default is 20 mb.</td><td>20971520</td></tr>
+<tr><td><small>phoenix.query.maxSpoolToDiskBytes</small></td><td style="text-align: left;">Threshold
+ size in bytes upto which results from parallelly executed
+ query results are spooled to disk above which the query will fail. Default is 1 gb.</td><td>1024000000</td></tr>
+<tr><td><small>phoenix.query.maxGlobalMemoryPercentage</small></td><td style="text-align: left;">Percentage of total heap memory (i.e. Runtime.getRuntime().totalMemory()) that all threads may use. Only course grain memory usage is tracked, mainly accounting for memory usage in the intermediate map built during group by aggregation. When this limit is reached the clients block attempting to get more memory, essentially throttling memory usage. Defaults to 50%</td><td>50</td></tr>
+<tr><td><small>phoenix.query.maxGlobalMemoryWaitMs</small></td><td style="text-align: left;">Maximum
+ amount of time that a client will block while waiting for more memory
+ to become available. After this amount of time, an
+<code>InsufficientMemoryException</code> is
+ thrown. Default is 10 sec.</td><td>10000</td></tr>
+<tr><td><small>phoenix.query.maxTenantMemoryPercentage</small></td><td style="text-align: left;">Maximum
+ percentage of <code>phoenix.query.maxGlobalMemoryPercentage</code> that
+any one tenant is allowed to consume. After this percentage, an
+<code>InsufficientMemoryException</code> is
+ thrown. Default is 100%</td><td>100</td></tr>
+<tr><td><small>phoenix.query.targetConcurrency</small></td><td style="text-align: left;">Target concurrent
+ threads to use for a query. It serves as a soft limit on the number of
+ scans into which a query may be split. The value should not exceed the hard limit imposed by<code> phoenix.query.maxConcurrency</code>.</td><td>32</td></tr>
+<tr><td><small>phoenix.query.maxConcurrency</small></td><td style="text-align: left;">Maximum concurrent
+ threads to use for a query. It servers as a hard limit on the number
+ of scans into which a query may be split. A soft limit is imposed by
+<code>phoenix.query.targetConcurrency</code>.</td><td>64</td></tr>
+<tr><td><small>phoenix.query.dateFormat</small></td><td style="text-align: left;">Default pattern to use
+ for conversion of a date to/from a string, whether through the
+ <code>TO_CHAR(<date>)</code> or
+<code>TO_DATE(<date-string>)</code> functions, or through
+<code>resultSet.getString(<date-column>)</code>.</td><td>yyyy-MM-dd HH:mm:ss</td></tr>
+<tr><td><small>phoenix.query.statsUpdateFrequency</small></td><td style="text-align: left;">The frequency
+ in milliseconds at which the stats for each table will be
+updated. Default is 15 min.</td><td>900000</td></tr>
+<tr><td><small>phoenix.query.maxStatsAge</small></td><td>The maximum age of
+ stats in milliseconds after which they will no longer be used (i.e. the stats were not able to be updated in this amount of time and thus are considered too old). Default is 1 day.</td><td>1</td></tr>
+<tr><td><small>phoenix.mutate.maxSize</small></td><td style="text-align: left;">The maximum number of rows
+ that may be batched on the client
+ before a commit or rollback must be called.</td><td>500000</td></tr>
+<tr><td><small>phoenix.mutate.batchSize</small></td><td style="text-align: left;">The number of rows that are batched together and automatically committed during the execution of an
+ <code>UPSERT SELECT</code> or <code>DELETE</code> statement. This property may be
+overridden at connection
+ time by specifying the <code>UpsertBatchSize</code>
+ property value. Note that the connection property value does not affect the batch size used by the coprocessor when these statements are executed completely on the server side.</td><td>1000</td></tr>
+<tr><td><small>phoenix.query.regionBoundaryCacheTTL</small></td><td style="text-align: left;">The time-to-live
+ in milliseconds of the region boundary cache used to guide the split
+ points for query parallelization. Default is 15 sec.</td><td>15000</td></tr>
+<tr><td><small>phoenix.query.maxIntraRegionParallelization</small></td><td style="text-align: left;">The maximum number of threads that will be spawned to process data within a single region during query execution</td><td>64</td></tr>
+<tr><td><small>phoenix.query.rowKeyOrderSaltedTable</small></td><td style="text-align: left;">Whether or not a non aggregate query returns rows in row key order for salted tables. If this option is turned on, split points may not be specified at table create time, but instead the default splits on each salt bucket must be used. Default is true</td><td>true</td></tr></tbody></table>
+<br />
+<h4>
+Parallelization</h4>
+Phoenix breaks up aggregate queries into multiple scans and runs them in parallel through custom aggregating coprocessors to improve performance. Hari Kumar, from Ericsson Labs, did a good job of explaining the performance benefits of parallelization and coprocessors <a href="http://labs.ericsson.com/blog/hbase-performance-tuners" target="_blank">here</a>. One of the most important factors in getting good query performance with Phoenix is to ensure that table splits are well balanced. This includes having regions of equal size as well as an even distribution across region servers. There are open source tools such as <a href="http://www.sentric.ch/blog/hbase-split-visualisation-introducing-hannibal" target="_blank">Hannibal</a> that can help you monitor this. By having an even distribution of data, every thread spawned by the Phoenix client will have an equal amount of work to process, thus reducing the time it takes to get the results back. <br />
+<br />
+The <code>phoenix.query.targetConcurrency</code> and <code>phoenix.query.maxConcurrency</code> control how a query is broken up into multiple scans on the client side. The idea for parallelization of queries is to align the scan boundaries with region boundaries. If rows are not evenly distributed across regions, using this scheme compensates for regions that have more rows than others, by applying tighter splits and therefore spawning off more scans over the overloaded regions.<br />
+<br />
+The split points for parallelization are computed as follows. Let's suppose:<br />
+<ul>
+<li><code>t</code> is the target concurrency</li>
+<li><code>m</code> is the max concurrency</li>
+<li><code>r</code> is the number of regions we need to scan</li>
+</ul>
+<code>if r >= t</code><br />
+ scan using regional boundaries<br />
+<code>else if r/2 > t</code><br />
+ split each region in s splits such that: <code>s = max(x) where s * x < m</code><br />
+<code>else</code><br />
+ split each region in s splits such that: <code>s = max(x) where s * x < t</code><br />
+<br />
+Depending on the number of cores in your client machine and the size of your cluster, the <code>phoenix.query.threadPoolSize</code>, <code>phoenix.query.queueSize</code>,<code> phoenix.query.maxConcurrency</code>, and <code>phoenix.query.targetConcurrency</code> may all be increased to allow more threads to process a query in parallel. This will allow Phoenix to divide up a query into more scans that may then be executed in parallel, thus reducing latency.<br />
+<br />
+This approach is not without its limitations. The primary issue is that Phoenix does not have sufficient information to divide up a region into equal data sizes. If the query results span many regions of data, this is not a problem, since regions are more or less of equal size. However, if a query accesses only a few regions, this can be an issue. The best Phoenix can do is to divide up the key space between the start and end key evenly. If there's any skew in the data, then some scans are bound to bear the brunt of the work. You can adjust <code>phoenix.query.maxIntraRegionParallelization</code> to a smaller number to decrease the number of threads spawned per region if you find that throughput is suffering.<br />
+<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 />
+<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 />
+<br />
+On the DML side of the fence, performance may improve by turning the connection auto commit to on for multi-row mutations such as those that can occur with <code>DELETE</code> and <code>UPSERT SELECT</code>. In this case, if possible, the mutation will be performed completely on the server side without returning data back to the client. However, when performing single row mutations, such as <code>UPSERT VALUES</code>, the opposite is true: auto commit should be off and a reasonable number of rows should be batched together for a single commit to reduce RPC traffic.<br />
+<h3>
+Measuring Performance</h3>
+One way to get a feeling for how to configure these properties is to use the performance.sh shell script provided in the bin directory of the installation tar.<br />
+<br />
+<b>Usage: </b><code>performance.sh <zookeeper> <row count></code><br />
+<b>Example: </b><code>performance.sh localhost 1000000</code><br />
+<br />
+This will create a new table named <code>performance_1000000</code> and upsert 1000000 rows. The schema and data generated is similar to <code>examples/web_stat.sql</code> and <code>examples/web_stat.csv</code>. On the console it will measure the time it takes to:<br />
+<ul>
+<li>upsert these rows</li>
+<li>run queries that perform <code>COUNT</code>, <code>GROUP BY</code>, and <code>WHERE</code> clause filters</li>
+</ul>
+For convenience, an <code>hbase-site.xml</code> file is included in the bin directory and pre-configured to already be on the classpath during script execution.<br />
+<br />
+Here is a screenshot of the performance.sh script in action:<br />
+<div class="separator" style="clear: both; text-align: center;">
+<a href="http://1.bp.blogspot.com/-VhinivNOJmI/URWBGLYTiHI/AAAAAAAAAQU/Dp9lbH2CxYE/s1600/performance_script.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="http://1.bp.blogspot.com/-VhinivNOJmI/URWBGLYTiHI/AAAAAAAAAQU/Dp9lbH2CxYE/s640/performance_script.png" width="497" /></a></div>
+<h3>
+ Conclusion</h3>
+Phoenix has many knobs and dials to tailor the system to your use case. From controlling the level of parallelization, to the size of batches, to the consumption of resource, <i>there's a knob for that</i>. These controls are not without there limitations, however. There's still more work to be done and we'd love to hear your ideas on what you'd like to see made more configurable.<br />
+<br />
Added: incubator/phoenix/site/source/src/site/markdown/views.md
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/markdown/views.md?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/markdown/views.md (added)
+++ incubator/phoenix/site/source/src/site/markdown/views.md Fri Jan 31 20:42:02 2014
@@ -0,0 +1,53 @@
+#Views
+
+The standard SQL view syntax (with some limitations) is now supported by Phoenix to enable multiple virtual tables to all share the same underlying physical HBase table. This is especially important in HBase, as you cannot realistically expect to have more than perhaps up to a hundred physical tables and continue to get reasonable performance from HBase.
+
+For example, given the following table definition that defines a base table to collect product metrics:
+
+ CREATE TABLE product_metrics (
+ metric_type CHAR(1),
+ created_by VARCHAR,
+ created_date DATE,
+ metric_id INTEGER
+ CONSTRAINT pk PRIMARY KEY (metric_type, created_by, created_date, metric_id));
+
+You may define the following view:
+
+ CREATE VIEW mobile_product_metrics (carrier VARCHAR, dropped_calls BIGINT) AS
+ SELECT * FROM product_metrics
+ WHERE metric_type = 'm';
+In this case, the same underlying physical HBase table (i.e. PRODUCT_METRICS) stores all of the data.
+Notice that unlike with standard SQL views, you may define additional columns for your view. The view inherits all of the columns from its base table, in addition to being able to optionally add new KeyValue columns. You may also add these columns after-the-fact with an ALTER TABLE statement.
+
+## Updatable Views
+If your view uses only simple equality expressions in the WHERE clause, you are also allowed to issue DML against the view. These views are termed *updatable views*. For example, in this case you could issue the following UPSERT statement:
+
+ UPSERT INTO mobile_product_metrics(created_by, create_date, metric_id, carrier, dropped_calls)
+ VALUES('John Doe', CURRENT_DATE(), NEXT VALUE FOR metric_seq, 'Verizon', 20);
+
+In this case, the row will be stored in the PRODUCT_METRICS HBase table and the metric_type column value will be inferred to be 'm' since the VIEW defines it as such.
+
+Also, queries done through the view will automatically apply the WHERE clause filter. For example:
+
+ SELECT sum(dropped_calls) FROM mobile_product_metrics WHERE carrier='Verizon'
+
+This would sum all the dropped_calls across all product_metrics with a metric_type of 'm' and a carrier of 'Verizon'.
+
+## Read-only Views
+Views may also be defined with more complex WHERE clauses, but in that case you cannot issue DML against them as you'll get a ReadOnlyException. You are still allowed to query through them and their WHERE clauses will be in effect as with standard SQL views.
+
+As expected, you may create a VIEW on another VIEW as well to further filter the data set. The same rules as above apply: if only simple equality expressions are used in the VIEW and its parent VIEW(s), the new view is updatable as well, otherwise it's read-only.
+
+Note that the previous support for creating a read-only VIEW directly over an HBase table is still supported.
+
+## Indexes on Views
+In addition, you may create an INDEX over a VIEW, just as with a TABLE. This is particularly useful to improve query performance over newly added columns on a VIEW, since it provides a way of doing point lookups based on these column values.
+
+## Limitations
+In our Phoenix 3.0 release, views have the following restrictions:
+
+1. The primary key constraint may not be changed by a VIEW.
+2. A TABLE that has a VIEW may not be dropped, but instead all VIEWs must be dropped first. In the future, we may support the concept of a CASCADE delete.
+2. Single-table only - you may not create a VIEW over multiple, joined tables. This will be supported in a future release.
+3. All columns must be projected into a VIEW (i.e. only the CREATE VIEW ... AS SELECT * syntax is supported). Note, however, you may drop non primary key columns inherited from the base table in a VIEW after it is created through the ALTER TABLE command. Providing a subset of columns and or expressions in the SELECT clause will be supported in a future release.
+
Added: incubator/phoenix/site/source/src/site/resources/css/site.css
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/css/site.css?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/resources/css/site.css (added)
+++ incubator/phoenix/site/source/src/site/resources/css/site.css Fri Jan 31 20:42:02 2014
@@ -0,0 +1,65 @@
+/* You can override this file with your own styles */
+
+@media (min-width: 980px) {
+h1[id]:before,
+h2[id]:before,
+h3[id]:before,
+h4[id]:before,
+h5[id]:before,
+h6[id]:before,
+a[name]:before {
+ display:block;
+ content:"";
+ height:55px;
+ margin:-55px 0 0;
+}
+}
+
+@media (max-width: 979px) {
+h1[id]:before,
+h2[id]:before,
+h3[id]:before,
+h4[id]:before,
+h5[id]:before,
+h6[id]:before,
+a[name]:before {
+ display:block;
+ content:"";
+ height:0px;
+ margin:0px 0 0;
+}
+}
+
+.navbar-fixed-top {
+margin-bottom: 0px;
+}
+
+@media (min-width: 980px) {
+body {
+ padding-top: 40px;
+ padding-bottom: 20px;
+}
+}
+
+.page-header {
+padding-bottom: 0px;
+margin-top: 20px;
+margin-bottom: 10px;
+}
+
+
+@media (max-width: 479px) {
+ .xtoplogo {
+ height: 23px;
+ width: 183px;
+ background:url(../images/topbar-logo-small.png)
+ }
+}
+
+@media (min-width: 480px) {
+ .xtoplogo {
+ height: 23px;
+ width: 360px;
+ background:url(../images/topbar-logo.png)
+ }
+}
Added: incubator/phoenix/site/source/src/site/resources/favicon.ico
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/favicon.ico?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/favicon.ico
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/PhoenixVsHive.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/PhoenixVsHive.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/PhoenixVsHive.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/PhoenixVsImpala.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/PhoenixVsImpala.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/PhoenixVsImpala.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/PhoenixVsOpenTSDB.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/PhoenixVsOpenTSDB.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/PhoenixVsOpenTSDB.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/logo.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/logo.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/logo.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/perf-esscf.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/perf-esscf.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/perf-esscf.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/perf-salted-read.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/perf-salted-read.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/perf-salted-read.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/perf-salted-write.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/perf-salted-write.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/perf-salted-write.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/perf-skipscan.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/perf-skipscan.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/perf-skipscan.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/perf-topn.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/perf-topn.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/perf-topn.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/psql.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/psql.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/psql.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/sqlline.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/sqlline.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/sqlline.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/squirrel.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/squirrel.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/squirrel.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/topbar-logo-small.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/topbar-logo-small.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/topbar-logo-small.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/images/topbar-logo.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/images/topbar-logo.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/images/topbar-logo.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/images/div-d.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/images/div-d.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/language/images/div-d.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/images/div-ke.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/images/div-ke.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/language/images/div-ke.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/images/div-ks.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/images/div-ks.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/language/images/div-ks.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/images/div-le.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/images/div-le.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/language/images/div-le.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/images/div-ls.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/images/div-ls.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/language/images/div-ls.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/images/div-te.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/images/div-te.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/language/images/div-te.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/images/div-ts.png
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/images/div-ts.png?rev=1563252&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/phoenix/site/source/src/site/resources/language/images/div-ts.png
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/phoenix/site/source/src/site/resources/language/stylesheet.css
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/resources/language/stylesheet.css?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/resources/language/stylesheet.css (added)
+++ incubator/phoenix/site/source/src/site/resources/language/stylesheet.css Fri Jan 31 20:42:02 2014
@@ -0,0 +1,139 @@
+
+
+
+table.index {
+ width: 60%;
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border: 0px none;
+ border-collapse: collapse;
+}
+
+td.index {
+ width: 20%;
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border: 0px none;
+ border-collapse: collapse;
+ vertical-align: top;
+}
+
+
+
+code {
+ background-color: #ece9d8;
+ padding: 0px 4px;
+ color: #000000;
+ font-family: "lucida grande", tahoma, verdana, arial, sans-serif;
+ font-size:small;
+ -moz-border-radius: 4px;
+ -webkit-border-radius: 4px;
+ -khtml-border-radius: 4px;
+ border-radius: 4px;
+}
+
+.railroad {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+}
+
+.c {
+ color: #000000;
+ padding: 1px 3px;
+ margin: 0px 0px;
+ border: 2px solid;
+ -moz-border-radius: 0.4em;
+ -webkit-border-radius: 0.4em;
+ -khtml-border-radius: 0.4em;
+ border-radius: 0.4em;
+ background-color: #fff;
+}
+
+.ts {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+ width: 16px;
+ height: 24px;
+ background-image: url(images/div-ts.png);
+ background-size: 16px 512px;
+}
+
+.ls {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+ width: 16px;
+ height: 24px;
+ background-image: url(images/div-ls.png);
+ background-size: 16px 512px;
+}
+
+.ks {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+ width: 16px;
+ height: 24px;
+ background-image: url(images/div-ks.png);
+ background-size: 16px 512px;
+}
+
+.te {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+ width: 16px;
+ height: 24px;
+ background-image: url(images/div-te.png);
+ background-size: 16px 512px;
+}
+
+.le {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+ width: 16px;
+ height: 24px;
+ background-image: url(images/div-le.png);
+ background-size: 16px 512px;
+}
+
+.ke {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+ width: 16px;
+ height: 24px;
+ background-image: url(images/div-ke.png);
+ background-size: 16px 512px;
+}
+
+.d {
+ border: 0px;
+ padding: 0px;
+ margin: 0px;
+ border-collapse: collapse;
+ vertical-align: top;
+ min-width: 16px;
+ height: 24px;
+ background-image: url(images/div-d.png);
+ background-size: 1024px 512px;
+}
Added: incubator/phoenix/site/source/src/site/site.xml
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/site.xml?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/site.xml (added)
+++ incubator/phoenix/site/source/src/site/site.xml Fri Jan 31 20:42:02 2014
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+-->
+
+
+<project name="Apache Phoenix">
+ <skin>
+ <groupId>lt.velykis.maven.skins</groupId>
+ <artifactId>reflow-maven-skin</artifactId>
+ <version>1.0.0</version>
+ </skin>
+
+ <custom>
+ <reflowSkin>
+ <smoothScroll>true</smoothScroll>
+ <bottomNav maxSpan="9" >
+ <column>About</column>
+ <column>Using</column>
+ <column>Reference</column>
+ </bottomNav>
+ <theme>bootswatch-united</theme>
+ <highlightJs>true</highlightJs>
+ <titleTemplate>%2$s | %1$s</titleTemplate>
+ <brand>
+ <name><![CDATA[<div class="xtoplogo"></div>]]></name>
+ <href>index.html</href>
+ </brand>
+ <skinAttribution>false</skinAttribution>
+ <breadcrumbs>true</breadcrumbs>
+ <bottomDescription quote="false">
+ <![CDATA[<form action="https://www.google.com/search" method="get"><input value="phoenix.incubator.apache.org" name="sitesearch" type="hidden"><input placeholder="Search the site…" required="required" style="width:170px;" size="18" name="q" id="query" type="search"></form>]]>
+ </bottomDescription>
+ </reflowSkin>
+ </custom>
+ <body>
+
+ <menu name="About">
+ <item href="http://phoenix.incubator.apache.org/" name="Overview"/>
+ <item href="http://phoenix.incubator.apache.org/recent.html" name="New Features"/>
+ <item href="http://phoenix.incubator.apache.org/roadmap.html" name="Roadmap"/>
+ <item href="http://phoenix.incubator.apache.org/performance.html" name="Performance"/>
+ <item href="http://phoenix.incubator.apache.org/team.html" name="Team"/>
+ <item href="http://phoenix.incubator.apache.org/mailing_list.html" name="Mailing Lists"/>
+ <item href="http://phoenix.incubator.apache.org/source.html" name="Source Repository"/>
+ <item href="http://phoenix.incubator.apache.org/issues.html" name="Issue Tracking"/>
+ <item href="http://phoenix.incubator.apache.org/download.html" name="Download" />
+ <item href="" name=""/>
+ <item href="http://www.apache.org/licenses/" name="License" />
+ <item href="http://www.apache.org/foundation/sponsorship.html" name="Sponsorship" />
+ <item href="http://www.apache.org/foundation/thanks.html" name="Thanks" />
+ <item href="http://www.apache.org/security/" name="Security" />
+
+ </menu>
+ <menu name="Using">
+ <item href="http://phoenix.incubator.apache.org/faq.html" name="F.A.Q."/>
+ <item href="http://phoenix.incubator.apache.org/Phoenix-in-15-minutes-or-less.html" name="Quick Start"/>
+ <item href="http://phoenix.incubator.apache.org/building.html" name="Building"/>
+ <item href="http://phoenix.incubator.apache.org/tuning.html" name="Tuning"/>
+ <item href="" name=""/>
+ <item href="http://phoenix.incubator.apache.org/secondary_indexing.html" name="Secondary Indexes"/>
+ <item href="http://phoenix.incubator.apache.org/views.html" name="Views"/>
+ <item href="http://phoenix.incubator.apache.org/multi-tenancy.html" name="Multi tenancy"/>
+ <item href="http://phoenix.incubator.apache.org/sequences.html" name="Sequences"/>
+ <item href="http://phoenix.incubator.apache.org/salted.html" name="Salted Tables"/>
+ <item href="http://phoenix.incubator.apache.org/paged.html" name="Paged Queries"/>
+ <item href="http://phoenix.incubator.apache.org/dynamic_columns.html" name="Dynamic Columns"/>
+ <item href="http://phoenix.incubator.apache.org/skip_scan.html" name="Skip Scan"/>
+ <item href="http://phoenix.incubator.apache.org/mr_dataload.html" name="Bulk Loading"/>
+ <item href="" name=""/>
+ <item href="http://phoenix.incubator.apache.org/phoenix_on_emr.html" name="Amazon EMR Support"/>
+ <item href="http://phoenix.incubator.apache.org/flume.html" name="Apache Flume Plugin"/>
+
+ </menu>
+ <menu name="Reference">
+ <item href="http://phoenix.incubator.apache.org/language/index.html" name="Grammar"/>
+ <item href="http://phoenix.incubator.apache.org/language/functions.html" name="Functions"/>
+ <item href="http://phoenix.incubator.apache.org/language/datatypes.html" name="Datatypes"/>
+ </menu>
+
+ </body>
+</project>
Added: incubator/phoenix/site/source/src/site/xhtml/language/datatypes.xhtml
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/xhtml/language/datatypes.xhtml?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/xhtml/language/datatypes.xhtml (added)
+++ incubator/phoenix/site/source/src/site/xhtml/language/datatypes.xhtml Fri Jan 31 20:42:02 2014
@@ -0,0 +1,5 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head><link href="stylesheet.css" rel="stylesheet" /></head>
+<body><h1>Data Types</h1></body>update_here</html>
+
Added: incubator/phoenix/site/source/src/site/xhtml/language/functions.xhtml
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/xhtml/language/functions.xhtml?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/xhtml/language/functions.xhtml (added)
+++ incubator/phoenix/site/source/src/site/xhtml/language/functions.xhtml Fri Jan 31 20:42:02 2014
@@ -0,0 +1,5 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head><link href="stylesheet.css" rel="stylesheet" /></head>
+<body><h1>Functions</h1></body>update_here</html>
+
Added: incubator/phoenix/site/source/src/site/xhtml/language/index.xhtml
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/xhtml/language/index.xhtml?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/xhtml/language/index.xhtml (added)
+++ incubator/phoenix/site/source/src/site/xhtml/language/index.xhtml Fri Jan 31 20:42:02 2014
@@ -0,0 +1,5 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head><link href="stylesheet.css" rel="stylesheet" /></head>
+<body><h1>Grammar</h1></body>update_here</html>
+
Added: incubator/phoenix/site/source/src/site/xhtml/team.xhtml
URL: http://svn.apache.org/viewvc/incubator/phoenix/site/source/src/site/xhtml/team.xhtml?rev=1563252&view=auto
==============================================================================
--- incubator/phoenix/site/source/src/site/xhtml/team.xhtml (added)
+++ incubator/phoenix/site/source/src/site/xhtml/team.xhtml Fri Jan 31 20:42:02 2014
@@ -0,0 +1,115 @@
+<html>
+<body>
+<h1>Team</h1>
+<p>The following is a list of mentors and contributors with commit privileges that have directly contributed to the project in one way or another.</p>
+<hr />
+
+ <h4 id="Mentors">Mentors</h4>
+ <table border="0" class="bodyTable table table-striped table-hover">
+ <thead>
+ <tr class="a">
+ <th>Name</th>
+ <th>Company</th>
+ <th>Email</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr class="b">
+ <td width="25%">Lars Hofhansl </td>
+ <td width="25%">Salesforce</td>
+ <td><a class="externalLink" href="mailto:larsh@apache.org">larsh@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Andrew Purtell </td>
+ <td>Intel </td>
+ <td><a class="externalLink" href="mailto:apurtell@apache.org">apurtell@apache.org</a></td>
+ </tr>
+ <tr class="b">
+ <td>Enis Soztutar </td>
+ <td>Hortonworks </td>
+ <td><a class="externalLink" href="mailto:enis@apache.org">enis@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Deveraj Das </td>
+ <td>Hortonworks </td>
+ <td><a class="externalLink" href="mailto:ddas@apache.org">ddas@apache.org</a></td>
+ </tr>
+ <tr class="b">
+ <td>Steven Noels </td>
+ <td>NG Data </td>
+ <td><a class="externalLink" href="mailto:stevenn@apache.org">stevenn@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Michael Stack </td>
+ <td>Cloudera </td>
+ <td><a class="externalLink" href="mailto:stack@apache.org">stack@apache.org</a></td>
+ </tr>
+ </tbody>
+ </table>
+
+<hr/>
+
+ <h4 id="Committers">Committers</h4>
+ <table border="0" class="bodyTable table table-striped table-hover">
+ <thead>
+ <tr class="a">
+ <th>Name</th>
+ <th>Company</th>
+ <th>Email</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr class="b">
+ <td width="25%">James Taylor </td>
+ <td width="25%">Salesforce </td>
+ <td><a class="externalLink" href="mailto:jamestaylor@apache.org">jamestaylor@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Jesse Yates </td>
+ <td>Salesforce</td>
+ <td><a class="externalLink" href="mailto:jyates@apache.org">jyates@apache.org</a></td>
+ </tr>
+ <tr class="b">
+ <td>Eli Levine </td>
+ <td>Salesforce</td>
+ <td><a class="externalLink" href="mailto:elevine@apache.org">elevine@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Simon Toens </td>
+ <td>Salesforce</td>
+ <td><a class="externalLink" href="mailto:stoens@apache.org">stoens@apache.org</a></td>
+ </tr>
+ <tr class="b">
+ <td>Maryann Xue </td>
+ <td>Intel </td>
+ <td><a class="externalLink" href="mailto:maryannxue@apache.org">maryannxue@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Anoop Sam John </td>
+ <td>Intel </td>
+ <td><a class="externalLink" href="mailto:anoopsamjohn@apache.org">anoopsamjohn@apache.org</a></td>
+ </tr>
+ <tr class="b">
+ <td>Ramkrishna Vasudevan </td>
+ <td>Intel </td>
+ <td><a class="externalLink" href="mailto:ramkrishna@apache.org">ramkrishna@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Jeffrey Zhong </td>
+ <td>Hortonworks </td>
+ <td><a class="externalLink" href="mailto:jzhong@apache.org">jzhong@apache.org</a></td>
+ </tr>
+ <tr class="b">
+ <td>Nick Dimiduk </td>
+ <td>Hortonworks </td>
+ <td><a class="externalLink" href="mailto:ndimiduk@apache.org">ndimiduk@apache.org</a></td>
+ </tr>
+ <tr class="a">
+ <td>Mujtaba Chohan </td>
+ <td>Salesforce</td>
+ <td><a class="externalLink" href="mailto:mujtaba@apache.org">mujtaba@apache.org</a></td>
+ </tr>
+ </tbody>
+ </table>
+</body>
+</html>