incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Incubator Wiki] Update of "PhoenixProposal" by James.Taylor
Date Sat, 16 Nov 2013 05:33:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The "PhoenixProposal" page has been changed by James.Taylor:

  Our proposed Phoenix effort aligns closely with Apache HBase. The HBase project perimeter
is denoted by a simple byte-array based Create, Read, Update, Delete and Scan APIs with no
current plans to extend beyond this bounds. Phoenix complements this with a higher level API
in SQL with which many are already familiar. At first glance, it may seem that Phoenix should
just be folded into HBase as a new module. However, the focus of the two projects will be
quite different, especially as Phoenix matures. With secondary indexing and joins just having
been introduced into Phoenix, the next big frontier will be to implement a cost-based query
optimizer. This is the heart-and-soul of most relational databases and can can take a lifetime
to get right.
  HBase is focused on being a scalable data store agnostic to types and schema.  Phoenix would
layer typing, and relational facilities on top of this scalable store. By keeping Apache HBase
and Phoenix separate, both may evolve independently and at different rates. Though the focus
of the two projects is different, the relationship between them is very positive and mutually
beneficial. New features in HBase will be leveraged in Phoenix as it makes sense to surface
these in a SQL paradigm. In addition, Phoenix may drive new features in HBase, as evidenced
by the new type system recently introduced into HBase. This will enable better interoperability
between Apache Hive, standalone HBase uses case, and Phoenix by defining a standard serialization
+ Phoenix can be divided into a front end and a back end. The front end is delivered as a
JDBC driver and contains, among other things, the SQL parser and query planner. The front
end is currently written for the HBase client API but could be extended to support other data
stores in the Apache family.
+ The back end is, currently, HBase specific components for pushing as much work to the server
as possible. However, if there were sufficient interest to build them, contributions to Phoenix
of new back ends for other data stores in the Apache family would be feasible. 
  Other projects exists that perform SQL over HBase data (such as Apache Hive), however these
products do not provide the same low latency query capabilities as Phoenix. Instead, they
are more oriented around maximizing throughput for batched operations. Phoenix opens the door
to a completely new set of use cases for Apache HBase that demand a more interactive user

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message