I'm sorry, I'm having trouble following what seems like two XY turns in this conversation. Or it could be that I'm just suffering from sleep debt accumulated over the week.
We suggest the Thrift interface not because of language/interoperability considerations but because the operations supported by the Thrift interface are pretty close to the Java API by design. Also, you connect to it via a persistent TCP connection and requests and responses are streamed across, unlike how REST typically is used. When Ryan talks about MultiGet, this is not scanning. It may be that on the regionservers Gets are internally little scans but on the client this is not the same thing as using a Scanner. MultiGet is like scatter/gather of Gets. The Java API supports it therefore the Thrift API could. > I assume there is no multi-get in REST? Correct, see https://issues.apache.org/jira/browse/HBASE-2390 Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) --- On Fri, 12/17/10, Jack Levin <[email protected]> wrote: > From: Jack Levin <[email protected]> > Subject: Re: question about multi-transaction queries > To: [email protected] > Date: Friday, December 17, 2010, 5:14 PM > So, is scanner a worthwhile method to use to get a bunch of rows > that might be random? > > -Jack > > On Fri, Dec 17, 2010 at 5:06 PM, Ryan Rawson <[email protected]> > wrote: > > > > The multi interface in 0.90 will minimize rpc calls > > from the client to the region server. This isn't exposed > > in the thrift api but would be trivial to do so. > > > > On Dec 17, 2010 4:53 PM, "Jack Levin" <[email protected]> > wrote: > > > So the language in question for a client is not in > > > question. Rather the connector to hbase. The end goal > > > is to be able to say send only 5 GETs to get 1000 > > > records quickly, rather then sending 1000 GETs to get > > > 1000 records slowly. So, besides the raw api > > > functionality via Java, I assume there is no multi-get > > > in REST?
