Can't say I blame you, as it's a bit abstract. At Salesforce, we use it to
support query-more, where you want to be able to page through your data.
Without this feature, you have no way of establishing your "prior" position
to be able to get the next batch. This allows the client to jump right back
where they left off, with the query compiling down to setting a start row
on the scan, assuming you're navigating along your primary key or secondary
index axis (i.e. your row value constructor and order by match your primary
key constraint or your secondary indexed columns).
A second use case is if you have a composite primary key and you have a set
of say 1000 rows out of a billion for which you'd like to query. Using the
the IN syntax I outlined here:
https://github.com/forcedotcom/phoenix/wiki/Row-Value-Constructors, you can
now do this is a single query and it'll be super fast (i.e. as fast or
faster than a batched get).
On Mon, Oct 28, 2013 at 11:14 AM, Asaf Mesika <[EMAIL PROTECTED]> wrote:
> I couldn't get the Row Value Constructor feature.
> Do you perhaps have a real world use case to demonstrate this?
> On Friday, October 25, 2013, James Taylor wrote:
> > The Phoenix team is pleased to announce the immediate availability of
> > Phoenix 2.1 .
> > More than 20 individuals contributed to the release. Here are some of the
> > new features
> > now available:
> > * Secondary Indexing  to create and automatically maintain global
> > indexes over your
> > primary table.
> > - Queries automatically use an index when more efficient, turning your
> > full table scans
> > into point and range scans.
> > - Multiple columns may be indexed in ascending or descending sort
> > - Additional primary table columns may be included in the index to
> > a covered
> > index.
> > - Available in two flavors:
> > o Server-side index maintenance for mutable data.
> > o Client-side index maintenance optimized for write-once,
> > append-only use cases.
> > * 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
> > - Optimizes IN list of composite key values to be point gets.
> > * Map-reduce based CSV Bulk Loader  to build Phoenix-compliant HFiles
> > and load
> > them into HBase.
> > * MD5 hash and INVERT built-in functions
> > Phoenix 2.1 requires HBase 0.94.4 or above, with 0.94.10 or above
> > for mutable secondary indexing. For the best performance, we recommend
> > HBase 0.94.12 or above.
> > Regards,
> > James
> > @JamesPlusPlus
> > http://phoenix-hbase.blogspot.com/
> >  https://github.com/forcedotcom/phoenix/wiki/Download
> >  https://github.com/forcedotcom/phoenix/wiki/Secondary-Indexing
> >  https://github.com/forcedotcom/phoenix/wiki/Row-Value-Constructors
> >