Hi Michel, On Fri, May 18, 2012 at 1:39 AM, Michael Segel <[email protected]>wrote:
> > You should not let just any user run coprocessors on the server. That's > madness. > > > > Best regards, > > > > - Andy > > Fei Ding, > > I'm a little confused. > Are you trying to solve the problem of querying data efficiently from a > table, or are you trying to find an example of where and when to use > co-processors? > > I'm trying to solve the problem of querying data efficiently. Coprocessor is one of the possible solutions that I've tried. > You actually have an interesting problem that isn't easily solved in > relational databases, but I don't think its an appropriate problem if you > want to stress the use of coprocessors. > > Yes with Indexes you want to use coprocessors as a way to keep the index > in synch with the underlying table. > > However beyond that... the solution is really best run as a M/R job. > > Considering that HBase has two different access methods. One is as part of > M/R jobs, the other is a client/server model. If you wanted to, you could > create a service/engine/app that would allow you to efficiently query and > return result sets from your database, as well as manage indexes. > In part, coprocessors make this a lot easier. > I'm not using the coprocessors to maintain index tables, but using extended client to do this. > > If you consider the general flow of my solution earlier in this thread, > you now have a really great way to implement this. > > Note: we're really talking about allowing someone to query data from a > table using multiple indexes and index types. Think alternate table > (key/value pair) , Lucene/SOLR, and GeoSpatial. > > You could even bench mark it against an Oracle implementation, and > probably smoke it. > You could also do efficient joins between tables. > > So yeah, I would encourage you to work on your initial problem... ;-) > > Alternate table is also one of the possible solutions, however, it's not that easy too. I'm still working on it. ;-) -- Best Regards! Fei Ding [email protected]
