hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9612) Ability to batch edits destined to different regions
Date Thu, 03 Oct 2013 22:08:44 GMT

    [ https://issues.apache.org/jira/browse/HBASE-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785590#comment-13785590
] 

stack commented on HBASE-9612:
------------------------------

I spent time looking into trying to make [~eclark] less uncomfortable and doing what [~tsuna]
suggested a while back (perhaps off-issue), sorting out the passed in actions into gets and
mutations and then running a multiget for the gets and a multi call for the mutations. Digging
it seemed doable if I made multiget look like multi; AsyncProcess has an executor pool so
I was thinking I could add one executor for the gets and another for the mutations per regionserver.
 As long as I was careful w/ the results/exceptions keeping their indexes running and aligned,
I should be able to match up the returns before giving it all back to the client.

But then I found the multiget has same issue as multirequest in that it only allows a regions'
worth of gets to run at a time against a server.  Trying to fix multiget, I was just reproducing
the new multi model (a 'fixed' multiget would have one or more per-region pbs to hold a set
of Gets).

So, I am going to just remove multiGet.  We only use it in one place inside in the exists(List<Get>)
call.   If you want to do a multiget, you'll do this new 'universal' multi call.

Later, we can come along and add new methods to do multiGet and multiMutation if worth the
effort.

> Ability to batch edits destined to different regions
> ----------------------------------------------------
>
>                 Key: HBASE-9612
>                 URL: https://issues.apache.org/jira/browse/HBASE-9612
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.95.0, 0.95.1, 0.95.2, 0.96.0
>            Reporter: Benoit Sigoure
>            Assignee: stack
>            Priority: Critical
>             Fix For: 0.98.0, 0.96.0
>
>         Attachments: 0001-fix-packaging-by-region-in-MultiServerCallable.patch, 9612.096.v5.txt,
9612revert.txt, 9612v10.txt, 9612v11.txt, 9612v12.txt, 9612v2.txt, 9612v3.txt, 9612v4.txt,
9612v5.txt, 9612v5.txt, 9612v5.txt, 9612v7.txt, 9612v8.096.txt, 9612v8.txt, 9612v9.txt, 9612v9.txt,
9612.wip.txt
>
>
> The old (pre-PB) "multi" and "multiPut" RPCs allowed one to batch edits destined to different
regions.  Seems like we've lost this ability after the switch to protobufs.
> The {{MultiRequest}} only contains one {{RegionSpecifier}}, and a list of {{MultiAction}}.
 The {{MultiAction}} message is contains either a single {{MutationProto}} or a {{Get}} (but
not both – so its name is misleading as there is nothing "multi" about it).  Also it seems
redundant with {{MultiGetRequest}}, I'm not sure what's the point of supporting {{Get}} in
{{MultiAction}}.
> I propose that we change {{MultiRequest}} to be a just a list of {{MultiAction}}, and
{{MultiAction}} will contain the {{RegionSpecifier}}, the {{bool atomic}} and a list of {{MutationProto}}.
 This would be a non-backward compatible protobuf change.
> If we want we can support mixing edits and reads, in which case we'd also add a list
of {{Get}} in {{MultiAction}}, and we'd have support having both that list and the list of
{{MutationProto}} set at the same time.  But this is a bonus and can be done later (in a backward
compatible manner, hence no need to rush on this one).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message