• 嵌入式的JDBC驱动，实现了大部分的java.sql接口，包括元数据API 
• 可以通过多部行键或是键/值单元对列进行建模 
• 完善的查询支持，可以使用多个谓词以及优化的扫描键 
• DDL支持：通过CREATE TABLE、DROP TABLE及ALTER TABLE来添加/删除列 
• 版本化的模式仓库：当写入数据时，快照查询会使用恰当的模式 
• DML支持：用于逐行插入的UPSERT VALUES、用于相同或不同表之间大量数据传输的UPSERT SELECT、用于删除行的DELETE 
• 通过客户端的批处理实现的有限的事务支持 
• 单表——还没有连接，同时二级索引也在开发当中 
• 紧跟ANSI SQL标准，HIVE不完全支持SQL92，而Phoenix 接近ANSI SQL-2003

• Phoenix 2.x - HBase 0.94.x
• Phoenix 3.x - HBase 0.94.x
• Phoenix 4.x - HBase 0.98.1+

 　　　create table test (mykey integer not null primary key, mycolumn varchar); upsert into test values (1,‘Hello‘); upsert into test values (2,‘World!‘); select * from test;

 　　　import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.PreparedStatement; import java.sql.Statement; public class TestJava { public static void main(String[] args) throws SQLException { Statement stmt = null; ResultSet rset = null; Connection con = DriverManager.getConnection("jdbc:phoenix:[zk_host]"); // 已通过Shell建立 //stmt = con.createStatement(); //stmt.executeUpdate("create table test (mykey integer not null primary key, mycolumn varchar)"); //stmt.executeUpdate("upsert into test values (1,‘Hello‘)"); //stmt.executeUpdate("upsert into test values (2,‘World!‘)"); //con.commit(); PreparedStatement statement = con.prepareStatement("select * from test"); rset = statement.executeQuery(); while (rset.next()) { System.out.println(rset.getString("mycolumn")); } statement.close(); con.close(); } }

• 在Phoenix中DDL/DML是忽略大小写的，而表名和列名是区分大小写的；
• CREATE VIEW风险较小，但是readonly无法新增修改数据；
• CREATE TABLE风险较大，一旦表结构与HBase原有表不一致，原表将会被新表覆盖，造成数据丢失；
• 映射表创建后，遗留数据无法查询，新增修改后的数据才可见

　　　　　　CREATE TABLE my_table (k VARCHAR PRIMARY KEY, v1 VARCHAR, v2 BIGINT);

　　　　　　CREATE INDEX my_index ON my_table (v1);

　　　　　　CREATE INDEX my_index ON my_table (v1) INCLUDE (v2);

  　　　　　CREATE TABLE my_table (k VARCHAR PRIMARY KEY, v VARCHAR) IMMUTABLE_ROWS=true;

　　　　注意：只有当查询cloumns完全匹配索引时，基于索引的查询才能生效。例如：
　　　　create table usertable (id varchar primary key, firstname varchar, lastname varchar); 
　　　　create index idx_name on usertable (firstname);

　　　　查询语句：
　　　　select id, firstname, lastname from usertable where firstname = ‘foo‘;
　　　　由于索引只有firstname，而查询cloumns还包括了lastname，因此上述查询索引并未生效，可将索引调整如下：
　　　　create index idx_name on usertable (firstname) include (lastname);

3）Sequences

　　创建序列

　　　　CREATE SEQUENCE my_sequence;
　　　　CREATE SEQUENCE my_sequence START WITH -1000;
　　　　CREATE SEQUENCE my_sequence INCREMENT BY 10;
　　　　CREATE SEQUENCE my_schema.my_sequence START 0 CACHE 10;

　　插入数据

　　　　UPSERT INTO my_schema(MYKEY, MYCOLUMN) VALUES( NEXT VALUE FOR my_schema.my_sequence, ‘foo‘); 

　　删除序列
　　　　DROP SEQUENCE my_sequence;
　　　　DROP SEQUENCE IF EXISTS my_schema.my_sequence;

　　4）Salted Tables

　　在使用连续的row key时，避免RegionServer出现Hotspotting是HBase使用过程中的通用问题。详细描述及解决方案参考http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/。 其问题大致可描述为：HBase按照row key的字典序的形式存储记录，这可以非常快速的通过raw key定位数据，以及数据的startkey和endkey范围。在很多应用场景中，很多时候采用自增或自减的序列作为HBase的row key，比如001，002，003……或者499，498，…… 在这种情况下，下一个序列必须由当前序列和步长计算得出，那么如果Region由很多个RegionServer提供服务，这是没有问题的。但很显然在HBase的架构中，一个Region只有一个RegionServer提供服务。因此，当一个Region达到它预先设置的一个最大范围时，将分裂成为两个较小的Region，并由两个RegionServer接管，无论怎样分裂对Region的写入负载总是落在某一个RegionServer的主机上，若需要全局序列实现自增，显然就失去了集群负载均衡的作用，下图是一个负载情况：

找到了问题原因，那么解决方案就相对容易一下，例如可以salt row keys with a prefix，即为row key做一些添加剂，如增加前缀：

new_row_key = (++index % BUCKETS_NUMBER) + original_key

这里简单的根据数据的原始自增或自减的记录或者ID作为index，对需要分片的bucket去余进行划分，得到一个新的row key：

那么HBase集群相对之前的负载将会大有改善，如下图所示：

Phoenix中以Salted Table的方式支持上述接近方案，可以做如下定义，其中SALT_BUCKETS是1~256的自然数：

CREATE TABLE table (a_key VARCHAR PRIMARY KEY, a_col VARCHAR) SALT_BUCKETS = 20;

　　5）Configuration and Tuning

　　Apache Phoenix作为HBase的一个连接驱动，在客户端做了很多定制优化。因此，应用程序可以对Client端的hbase-site.xml进行参数调优。详细属性说明参考：http://phoenix.incubator.apache.org/tuning.html
　　这里以bin/psql.py客户端脚本执行调优为例，修改$PHOENIX/phoenix-assembly/target目录下的phoenix-4.0.0-incubating-client.jar的hbase-default.xml文件，增加如下内容以实现将客户端默认缓存从100MB调整为1GB：

　　phoenix.query.maxServerCacheBytes
　　1024000000