Fei DIng,
I think you're making the solution harder than it should be.
To start with, the only think you need to do is use co-processors to keep the
indexes in sync with the underlying table.
The code called from the co-processor will depend on the type of action and the
type of index you ar
Hi Michel,
On Fri, May 18, 2012 at 1:39 AM, Michael Segel 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 efficient
> 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 us
On Wed, May 16, 2012 at 6:43 PM, fding hbase wrote:
>> Not coprocessors in general. The client side support for Endpoints
>> (Exec, etc.) gives the developer the fiction of addressing the cluster
>> as a range of rows, and will parallelize per-region Endpoint
>> invocations, and collect the respon
On Thu, May 17, 2012 at 6:28 AM, Andrew Purtell wrote:
> Are HBase coprocessors explicitly wrong for this use case if the app
> logic
> needs to access multiple regions in a single call?
Not coprocessors in general. The client side support for Endpoints
> (Exec, etc.) gives the developer the
On Wed, May 16, 2012 at 2:40 PM, Dave Revell wrote:
> Many people will probably try to use coprocessors as a way of implementing
> app logic on top of HBase without the headaches of writing a daemon.
> Sometimes client-side approaches are inadvisable; for example, there may be
> several client lan
David,
Its not a question of a daemon, its a question of the problem you are trying to
solve.
Using this as an example.. you are not always going to select data from a given
table always using the same query. So you will not always want to use the index
on column A and then the index on column
Many people will probably try to use coprocessors as a way of implementing
app logic on top of HBase without the headaches of writing a daemon.
Sometimes client-side approaches are inadvisable; for example, there may be
several client languages/runtimes and the app logic should not be
reimplemented
I think we need to look at the base problem that is trying to be solved.
I mean the discussion on the RPC mechanism. but the problem that the OP is
trying to solve is how to use multiple indexes in a 'query'.
Note: I put ' ' around query because its a m/r job or a single thread where the
us
> On May 16, 2012, at 1:12 AM, fding hbase wrote:
>> But sadly, HBase ipc doesn't allow coprocessor chaining mechanism...
>> Someone mentioned on
>> http://grokbase.com/t/hbase/user/116hrhhf8m/coprocessor-failure-question-and-examples
>> :
>>
>> If a RegionObserver issues RPC to another table from
Ok...
I think you need to step away from your solution and take a look at the problem
from a different perspective.
From my limited understanding of Co-processors, this doesn't fit well in what
you want to do.
I don't believe that you want to run a M/R query within a Co-processor.
In short, i
Hi Michel,
Thanks for your reply. I believe your idea works both in theory and
practice. But the problem I worried about does not
lie on the memory usage, but on the network performance. If I query all the
indexed rows from index tables and pull all
of them to client and push them to the temp tabl
Sorry for the delay... Had a full day yesterday...
In a nut shell... Tough nut to crack. I can give you a solution which you can
probably enhance...
At the start, ignore coProcessors for now...
So what end up doing is the following.
General solution... N indexes..
Create a temp table in HBase
Hi Michel,
I indexed each column within a column family of a table, so we can query a
row with specific column value.
By multi-index I mean using multiple indexes at the same time on a single
query. That looks like a SQL select
with two *where* clauses of two indexed columns.
The row key of index
Need a little clarification...
You said that you need to do multi-index queries.
Did you mean to say multiple people running queries at the same time, or did
you mean you wanted to do multi-key indexes where the key is a multi-key part.
Or did you mean that you really wanted to use multiple ind
Hi all,
Is it possible to use table scanner (different from the host table region)
or
execute coprocessor of another table, in the endpoint coprocessor?
It looks like chaining coprocessors. But I found a possible deadlock!
Can anyone help me with this?
In my testing environment I deployed the 0.9
16 matches
Mail list logo
