[jira] [Created] (HBASE-11303) [0.89] Adding separate hosts to a cluster in non disruptive way
Adela Maznikar created HBASE-11303: -- Summary: [0.89] Adding separate hosts to a cluster in non disruptive way Key: HBASE-11303 URL: https://issues.apache.org/jira/browse/HBASE-11303 Project: HBase Issue Type: Improvement Components: Region Assignment Affects Versions: 0.89-fb Reporter: Adela Maznikar Similarly to expandRack we need a way to expand a cluster with specific hosts in a non disruptive way. The solution will go through each table and will change a tertiary location of some of the regions to use some of the new machines that we want to add. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11254) [0.89-fb] Improve retry logic in HTableMultiplexer.HTableFlushWorker
Adela Maznikar created HBASE-11254: -- Summary: [0.89-fb] Improve retry logic in HTableMultiplexer.HTableFlushWorker Key: HBASE-11254 URL: https://issues.apache.org/jira/browse/HBASE-11254 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Adela Maznikar Assignee: Adela Maznikar Fix For: 0.89-fb The failed puts in HTableMultiplexer.HTableFlushWorker are immediately resubmitted in the original queue. This queue is being flushed every 100ms (default configuration) and the maximal retry of a failed put is by default 10 times (client configurable). That leaves us with ~1 second to complete a Put (with default configuration). We can improve this by gradually increasing the time for retrying, each time when the put fails. (example: first time retry after 100ms, then after 200ms, 400ms, etc). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11035) [0.89-fb] Online configuration change for regionobservers
Adela Maznikar created HBASE-11035: -- Summary: [0.89-fb] Online configuration change for regionobservers Key: HBASE-11035 URL: https://issues.apache.org/jira/browse/HBASE-11035 Project: HBase Issue Type: Improvement Components: Coprocessors Reporter: Adela Maznikar Assignee: Adela Maznikar Fix For: 0.89-fb We can use online configuration change to specify the active list of coprocessors in CoprocessorHost (RegionCoprocessorHost). That way we don't need to close regions when we want to add/remove new coprocessors (regionobservers) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10975) [89-fb] HTableMultiplexer to use executor
[ https://issues.apache.org/jira/browse/HBASE-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-10975. Resolution: Fixed > [89-fb] HTableMultiplexer to use executor > - > > Key: HBASE-10975 > URL: https://issues.apache.org/jira/browse/HBASE-10975 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > Attachments: HTableMultiplexer_executor.patch > > > HtableMultiplexer is creating manually HTableFlushWorker thread for each > regionserver. Changing this to use ScheduledExecutorService. Also this will > help us get rid of the Thread.sleep() in HTableFlushWorker.run() and make > the code smaller and easier to read. > Add a unit test which will spawn 10 client threads which will do 10k puts > each concurrently and check that when we do get() we get the data back. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-10975) [89-fb] HTableMultiplexer to use executor
[ https://issues.apache.org/jira/browse/HBASE-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10975: --- Attachment: HTableMultiplexer_executor.patch > [89-fb] HTableMultiplexer to use executor > - > > Key: HBASE-10975 > URL: https://issues.apache.org/jira/browse/HBASE-10975 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > Attachments: HTableMultiplexer_executor.patch > > > HtableMultiplexer is creating manually HTableFlushWorker thread for each > regionserver. Changing this to use ScheduledExecutorService. Also this will > help us get rid of the Thread.sleep() in HTableFlushWorker.run() and make > the code smaller and easier to read. > Add a unit test which will spawn 10 client threads which will do 10k puts > each concurrently and check that when we do get() we get the data back. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-10975) [89-fb] HTableMultiplexer to use executor
[ https://issues.apache.org/jira/browse/HBASE-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10975: --- Status: Patch Available (was: Open) > [89-fb] HTableMultiplexer to use executor > - > > Key: HBASE-10975 > URL: https://issues.apache.org/jira/browse/HBASE-10975 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > > HtableMultiplexer is creating manually HTableFlushWorker thread for each > regionserver. Changing this to use ScheduledExecutorService. Also this will > help us get rid of the Thread.sleep() in HTableFlushWorker.run() and make > the code smaller and easier to read. > Add a unit test which will spawn 10 client threads which will do 10k puts > each concurrently and check that when we do get() we get the data back. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-10975) [89-fb] HTableMultiplexer to use executor
[ https://issues.apache.org/jira/browse/HBASE-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10975: --- Status: Open (was: Patch Available) > [89-fb] HTableMultiplexer to use executor > - > > Key: HBASE-10975 > URL: https://issues.apache.org/jira/browse/HBASE-10975 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > > HtableMultiplexer is creating manually HTableFlushWorker thread for each > regionserver. Changing this to use ScheduledExecutorService. Also this will > help us get rid of the Thread.sleep() in HTableFlushWorker.run() and make > the code smaller and easier to read. > Add a unit test which will spawn 10 client threads which will do 10k puts > each concurrently and check that when we do get() we get the data back. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-10975) [89-fb] HTableMultiplexer to use executor
[ https://issues.apache.org/jira/browse/HBASE-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10975: --- Summary: [89-fb] HTableMultiplexer to use executor (was: [89-fb] HTableMultplexer to use executor) > [89-fb] HTableMultiplexer to use executor > - > > Key: HBASE-10975 > URL: https://issues.apache.org/jira/browse/HBASE-10975 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > > HtableMultiplexer is creating manually HTableFlushWorker thread for each > regionserver. Changing this to use ScheduledExecutorService. Also this will > help us get rid of the Thread.sleep() in HTableFlushWorker.run() and make > the code smaller and easier to read. > Add a unit test which will spawn 10 client threads which will do 10k puts > each concurrently and check that when we do get() we get the data back. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-10975) [89-fb] HTableMultplexer to use executor
[ https://issues.apache.org/jira/browse/HBASE-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10975: --- Description: HtableMultiplexer is creating manually HTableFlushWorker thread for each regionserver. Changing this to use ScheduledExecutorService. Also this will help us get rid of the Thread.sleep() in HTableFlushWorker.run() and make the code smaller and easier to read. Add a unit test which will spawn 10 client threads which will do 10k puts each concurrently and check that when we do get() we get the data back. was: HtableMultiplexer is creating manually HTableFlushWorker thread for each regionserver. Changing this to use ScheduledExecutorService. Also this will help us get rid of the sleep methods in HTableFlushWorker.run() and make the code smaller and easier to read. Add a unit test which will spawn 10 client threads which will do 10k puts each concurrently and check that when we do get() we get the data back. > [89-fb] HTableMultplexer to use executor > > > Key: HBASE-10975 > URL: https://issues.apache.org/jira/browse/HBASE-10975 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > > HtableMultiplexer is creating manually HTableFlushWorker thread for each > regionserver. Changing this to use ScheduledExecutorService. Also this will > help us get rid of the Thread.sleep() in HTableFlushWorker.run() and make > the code smaller and easier to read. > Add a unit test which will spawn 10 client threads which will do 10k puts > each concurrently and check that when we do get() we get the data back. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10975) [89-fb] HTableMultplexer to use executor
Adela Maznikar created HBASE-10975: -- Summary: [89-fb] HTableMultplexer to use executor Key: HBASE-10975 URL: https://issues.apache.org/jira/browse/HBASE-10975 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Adela Maznikar Assignee: Adela Maznikar Priority: Minor Fix For: 0.89-fb HtableMultiplexer is creating manually HTableFlushWorker thread for each regionserver. Changing this to use ScheduledExecutorService. Also this will help us get rid of the sleep methods in HTableFlushWorker.run() and make the code smaller and easier to read. Add a unit test which will spawn 10 client threads which will do 10k puts each concurrently and check that when we do get() we get the data back. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10939) [89-fb] Adding a rack in HBase in online fashion
[ https://issues.apache.org/jira/browse/HBASE-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-10939. Resolution: Fixed code in RegionPlacement.expandRegionsToNewRack(...) > [89-fb] Adding a rack in HBase in online fashion > > > Key: HBASE-10939 > URL: https://issues.apache.org/jira/browse/HBASE-10939 > Project: HBase > Issue Type: New Feature > Components: Region Assignment >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > RegionPlacement -exprack to add a new rack into the region placement. So far > we have a static assignment plan and 3 preferred locations for a region, such > that the primary is the location which is serving all requests and hdfs > locality is very high on all 3 nodes. > -exprack is moving the the third preferred location on the new rack such that > it leaves the cluster in balanced state. After a few days locality is high > enough and we make some of this new locations primaries such that again we > have a balanced state in number of primaries per regionservers in the entire > cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10940) [0.89-fb] Rebalance primaries in-non disruptive way
[ https://issues.apache.org/jira/browse/HBASE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-10940. Resolution: Fixed code in RegionPlacement.balancePrimaries > [0.89-fb] Rebalance primaries in-non disruptive way > --- > > Key: HBASE-10940 > URL: https://issues.apache.org/jira/browse/HBASE-10940 > Project: HBase > Issue Type: New Feature > Components: Region Assignment >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > Added an option RegionPlacement -bp (balance primaries). > Sometimes in production we hit a case where some of the regionservers are > serving less number of regions than the rest and just updating the assignment > plan doesn't help since locality is highest on those locations and locality > is the highest parameter considered when we produce assignment plan for > primaries. > We want to switch primary and tertiary in a case where the regionserver has > more than average primaries and more primaries assigned than the > regionserver where teritary is (and tertiary has less than average). We do > bfs traversal from each node (node being a regionserver, and there is an edge > from machine serving primary to machine serving tertiary for a particular > region) until we find the node to which there is a > path and that node has less primaries assigned. Then we switch primary and > tertiary for all nodes on the path. We do that for each node. (node == > machine). > The motivation of the approach is - we want to move the region to a location > where locality is high enough. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10940) [0.89-fb] Rebalance primaries in-non disruptive way
Adela Maznikar created HBASE-10940: -- Summary: [0.89-fb] Rebalance primaries in-non disruptive way Key: HBASE-10940 URL: https://issues.apache.org/jira/browse/HBASE-10940 Project: HBase Issue Type: New Feature Components: Region Assignment Affects Versions: 0.89-fb Reporter: Adela Maznikar Assignee: Adela Maznikar Fix For: 0.89-fb Added an option RegionPlacement -bp (balance primaries). Sometimes in production we hit a case where some of the regionservers are serving less number of regions than the rest and just updating the assignment plan doesn't help since locality is highest on those locations and locality is the highest parameter considered when we produce assignment plan for primaries. We want to switch primary and tertiary in a case where the regionserver has more than average primaries and more primaries assigned than the regionserver where teritary is (and tertiary has less than average). We do bfs traversal from each node (node being a regionserver, and there is an edge from machine serving primary to machine serving tertiary for a particular region) until we find the node to which there is a path and that node has less primaries assigned. Then we switch primary and tertiary for all nodes on the path. We do that for each node. (node == machine). The motivation of the approach is - we want to move the region to a location where locality is high enough. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (HBASE-10939) [89-fb] Adding a rack in HBase in online fashion
[ https://issues.apache.org/jira/browse/HBASE-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar reassigned HBASE-10939: -- Assignee: Adela Maznikar > [89-fb] Adding a rack in HBase in online fashion > > > Key: HBASE-10939 > URL: https://issues.apache.org/jira/browse/HBASE-10939 > Project: HBase > Issue Type: New Feature > Components: Region Assignment >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > RegionPlacement -exprack to add a new rack into the region placement. So far > we have a static assignment plan and 3 preferred locations for a region, such > that the primary is the location which is serving all requests and hdfs > locality is very high on all 3 nodes. > -exprack is moving the the third preferred location on the new rack such that > it leaves the cluster in balanced state. After a few days locality is high > enough and we make some of this new locations primaries such that again we > have a balanced state in number of primaries per regionservers in the entire > cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10939) [89-fb] Adding a rack in HBase in online fashion
Adela Maznikar created HBASE-10939: -- Summary: [89-fb] Adding a rack in HBase in online fashion Key: HBASE-10939 URL: https://issues.apache.org/jira/browse/HBASE-10939 Project: HBase Issue Type: New Feature Components: Region Assignment Affects Versions: 0.89-fb Reporter: Adela Maznikar Fix For: 0.89-fb RegionPlacement -exprack to add a new rack into the region placement. So far we have a static assignment plan and 3 preferred locations for a region, such that the primary is the location which is serving all requests and hdfs locality is very high on all 3 nodes. -exprack is moving the the third preferred location on the new rack such that it leaves the cluster in balanced state. After a few days locality is high enough and we make some of this new locations primaries such that again we have a balanced state in number of primaries per regionservers in the entire cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10910) [89-fb] Change get(List) to batchGet(List)
Adela Maznikar created HBASE-10910: -- Summary: [89-fb] Change get(List) to batchGet(List) Key: HBASE-10910 URL: https://issues.apache.org/jira/browse/HBASE-10910 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Adela Maznikar Fix For: 0.89-fb batchGet(List) is more performant since it splits the list of Gets on regionserver level, and get(List) does that on region level. If we have a list of gets for regions on a same regionserver, get(List) will do #regions rpc calls and batchGet(List) will do just one rpc call. Changing HTable.get(List) to internally call HTable.batchGet(List) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (HBASE-10910) [89-fb] Change get(List) to batchGet(List)
[ https://issues.apache.org/jira/browse/HBASE-10910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar reassigned HBASE-10910: -- Assignee: Adela Maznikar > [89-fb] Change get(List) to batchGet(List) > > > Key: HBASE-10910 > URL: https://issues.apache.org/jira/browse/HBASE-10910 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > batchGet(List) is more performant since it splits the list of Gets on > regionserver level, and get(List) does that on region level. > If we have a list of gets for regions on a same regionserver, get(List) > will do #regions rpc calls and batchGet(List) will do just one rpc call. > Changing HTable.get(List) to internally call HTable.batchGet(List) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-9944) Create an HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-9944: -- Summary: Create an HBase C++ Thrift Client (was: Create a HBase C++ Thrift Client) > Create an HBase C++ Thrift Client > - > > Key: HBASE-9944 > URL: https://issues.apache.org/jira/browse/HBASE-9944 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.89-fb >Reporter: Gaurav Menghani >Assignee: Gaurav Menghani > Fix For: 0.89-fb > > > This is a task to create a native thrift C++ client for HBase when we change > the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-4047) [Coprocessors] Generic external process host
[ https://issues.apache.org/jira/browse/HBASE-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902088#comment-13902088 ] Adela Maznikar commented on HBASE-4047: --- I am curious if there is any additional progress here. Really exciting idea! > [Coprocessors] Generic external process host > > > Key: HBASE-4047 > URL: https://issues.apache.org/jira/browse/HBASE-4047 > Project: HBase > Issue Type: New Feature > Components: Coprocessors >Reporter: Andrew Purtell >Assignee: Andrew Purtell > > Where HBase coprocessors deviate substantially from the design (as I > understand it) of Google's BigTable coprocessors is we've reimagined it as a > framework for internal extension. In contrast BigTable coprocessors run as > separate processes colocated with tablet servers. The essential trade off is > between performance, flexibility and possibility, and the ability to control > and enforce resource usage. > Since the initial design of HBase coprocessors some additional considerations > are in play: > - Developing computational frameworks sitting directly on top of HBase hosted > in coprocessor(s); > - Introduction of the map reduce next generation (mrng) resource management > model, and the probability that limits will be enforced via cgroups at the OS > level after this is generally available, e.g. when RHEL 6 deployments are > common; > - The possibility of deployment of HBase onto mrng-enabled Hadoop clusters > via the mrng resource manager and a HBase-specific application controller. > Therefore we should consider developing a coprocessor that is a generic host > for another coprocessor, but one that forks a child process, loads the target > coprocessor into the child, establishes a bidirectional pipe and uses an > eventing model and umbilical protocol to provide for the coprocessor loaded > into the child the same semantics as if it was loaded internally to the > parent, and (eventually) use available resource management capabilities on > the platform -- perhaps via the mrng resource controller or directly with > cgroups -- to limit the child as desired by system administrators or the > application designer. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10503) [0.89-fb] Add metrics to track compaction hook progress
Adela Maznikar created HBASE-10503: -- Summary: [0.89-fb] Add metrics to track compaction hook progress Key: HBASE-10503 URL: https://issues.apache.org/jira/browse/HBASE-10503 Project: HBase Issue Type: Improvement Components: Compaction Affects Versions: 0.89-fb Reporter: Adela Maznikar Assignee: Adela Maznikar Priority: Minor Add a metric to track how many KVs we have converted with the compaction hook, and bytes that we have saved during the process. This will help us to see when there are no new KVs converted and give us a good signal when to disable it (all KVs are converted). Related JIRA: HBASE-7099 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10425) [0.89-fb] Isolate assignment plan on subset of machines
Adela Maznikar created HBASE-10425: -- Summary: [0.89-fb] Isolate assignment plan on subset of machines Key: HBASE-10425 URL: https://issues.apache.org/jira/browse/HBASE-10425 Project: HBase Issue Type: New Feature Components: Region Assignment Affects Versions: 0.89-fb Reporter: Adela Maznikar Assignee: Adela Maznikar We use AssignmentPlan to decide on favored nodes for regions. Right now we include all machines from the cluster in the assignment plan of a table. We want ability to limit the number of machines when assigning regions. This will help us to isolate the failure domain in case different users are using the cluster (in case someone is misusing the cluster, hopefully just a subset of machines would be affected). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10393) [fb-0.89] Expose a hook to compact files in hbase on the CLI
[ https://issues.apache.org/jira/browse/HBASE-10393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10393: --- Assignee: (was: Adela Maznikar) > [fb-0.89] Expose a hook to compact files in hbase on the CLI > > > Key: HBASE-10393 > URL: https://issues.apache.org/jira/browse/HBASE-10393 > Project: HBase > Issue Type: New Feature > Components: Compaction >Affects Versions: 0.89-fb >Reporter: Adela Maznikar > Fix For: 0.89-fb > > > Sometimes we need way to perform compactions outside of the regionserver, > example before turning on the cluster. The task is to expose a way to compact > files from the CLI without requring a running RS. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10393) [fb-0.89] Expose a hook to compact files in hbase on the CLI
[ https://issues.apache.org/jira/browse/HBASE-10393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10393: --- Description: Sometimes we need way to perform compactions outside of the regionserver, example before turning on the cluster. The task is to expose a way to compact files from the CLI without requiring a running RS. (was: Sometimes we need way to perform compactions outside of the regionserver, example before turning on the cluster. The task is to expose a way to compact files from the CLI without requring a running RS.) > [fb-0.89] Expose a hook to compact files in hbase on the CLI > > > Key: HBASE-10393 > URL: https://issues.apache.org/jira/browse/HBASE-10393 > Project: HBase > Issue Type: New Feature > Components: Compaction >Affects Versions: 0.89-fb >Reporter: Adela Maznikar > Fix For: 0.89-fb > > > Sometimes we need way to perform compactions outside of the regionserver, > example before turning on the cluster. The task is to expose a way to compact > files from the CLI without requiring a running RS. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10393) [fb-0.89] Expose a hook to compact files in hbase on the CLI
[ https://issues.apache.org/jira/browse/HBASE-10393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-10393: --- Assignee: Adela Maznikar > [fb-0.89] Expose a hook to compact files in hbase on the CLI > > > Key: HBASE-10393 > URL: https://issues.apache.org/jira/browse/HBASE-10393 > Project: HBase > Issue Type: New Feature > Components: Compaction >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > Sometimes we need way to perform compactions outside of the regionserver, > example before turning on the cluster. The task is to expose a way to compact > files from the CLI without requring a running RS. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10393) [fb-0.89] Expose a hook to compact files in hbase on the CLI
[ https://issues.apache.org/jira/browse/HBASE-10393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878061#comment-13878061 ] Adela Maznikar commented on HBASE-10393: oh great, thanks stack! I wasn't aware of this > [fb-0.89] Expose a hook to compact files in hbase on the CLI > > > Key: HBASE-10393 > URL: https://issues.apache.org/jira/browse/HBASE-10393 > Project: HBase > Issue Type: New Feature > Components: Compaction >Affects Versions: 0.89-fb >Reporter: Adela Maznikar > Fix For: 0.89-fb > > > Sometimes we need way to perform compactions outside of the regionserver, > example before turning on the cluster. The task is to expose a way to compact > files from the CLI without requring a running RS. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10393) [fb-0.89] Expose a hook to compact files in hbase on the CLI
Adela Maznikar created HBASE-10393: -- Summary: [fb-0.89] Expose a hook to compact files in hbase on the CLI Key: HBASE-10393 URL: https://issues.apache.org/jira/browse/HBASE-10393 Project: HBase Issue Type: New Feature Components: Compaction Affects Versions: 0.89-fb Reporter: Adela Maznikar Fix For: 0.89-fb Sometimes we need way to perform compactions outside of the regionserver, example before turning on the cluster. The task is to expose a way to compact files from the CLI without requring a running RS. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10109) [0.89-fb] Balance #regions/RS better when creating new table
[ https://issues.apache.org/jira/browse/HBASE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844708#comment-13844708 ] Adela Maznikar commented on HBASE-10109: The current approach assigns the regions in round robin fashion, but taking the racks into consideration (for each rack, for each regionserver , we assign a region). And we always start with the same rack. Additional improvement is to merge all regionservers together and then do the round robin assignment which would give us balance per regionserver. > [0.89-fb] Balance #regions/RS better when creating new table > > > Key: HBASE-10109 > URL: https://issues.apache.org/jira/browse/HBASE-10109 > Project: HBase > Issue Type: Improvement > Components: Region Assignment >Affects Versions: 0.89-fb >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > > When a new table is created we place the primary locations for the regions in > a round robin fashion. Because we do this for every newly created table it is > possible that some regionservers end up with more regions than the others and > if there are more tables in the cluster the difference between a min and max > #regions per RS can be larger. > One small optimization is to sort the RS in ascending order before assigning > them regions. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (HBASE-10109) [0.89-fb] Balance #regions/RS better when creating new table
Adela Maznikar created HBASE-10109: -- Summary: [0.89-fb] Balance #regions/RS better when creating new table Key: HBASE-10109 URL: https://issues.apache.org/jira/browse/HBASE-10109 Project: HBase Issue Type: Improvement Components: Region Assignment Affects Versions: 0.89-fb Reporter: Adela Maznikar Assignee: Adela Maznikar Priority: Minor Fix For: 0.89-fb When a new table is created we place the primary locations for the regions in a round robin fashion. Because we do this for every newly created table it is possible that some regionservers end up with more regions than the others and if there are more tables in the cluster the difference between a min and max #regions per RS can be larger. One small optimization is to sort the RS in ascending order before assigning them regions. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (HBASE-8114) [89-fb] Interrupt the server processing rpc call when client has closed the connection
[ https://issues.apache.org/jira/browse/HBASE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-8114. --- Resolution: Fixed Fix Version/s: 0.89-fb > [89-fb] Interrupt the server processing rpc call when client has closed the > connection > -- > > Key: HBASE-8114 > URL: https://issues.apache.org/jira/browse/HBASE-8114 > Project: HBase > Issue Type: Improvement >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > When the client issues a request the server will start processing, but if the > request is a big get/scan the client can close the connection (for example > timeout is reached) while the server is still processing the request. This > improvement should interrupt the server executing the call after the client > has closed the connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-8688) Add a choice for single/multiple throttler for callqueue
[ https://issues.apache.org/jira/browse/HBASE-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-8688. --- Resolution: Fixed Fix Version/s: 0.89-fb > Add a choice for single/multiple throttler for callqueue > > > Key: HBASE-8688 > URL: https://issues.apache.org/jira/browse/HBASE-8688 > Project: HBase > Issue Type: Improvement >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > The general idea is to have two throttles, such that we throttle larger and > smaller responses differently. If we know what is the typical size of the > response to a client, we can limit the possibilities of being blocked by > large requests. This will help in case when the client is issuing large > requests, the smaller ones will not be blocked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-7099) [89-fb] Create compaction hooks
[ https://issues.apache.org/jira/browse/HBASE-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-7099. --- Resolution: Fixed Fix Version/s: 0.89-fb > [89-fb] Create compaction hooks > > > Key: HBASE-7099 > URL: https://issues.apache.org/jira/browse/HBASE-7099 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > Create compaction hooks which should be used to modify the value of the KV > during compaction. The possible modifications would include: skipping the KV, > modifying the value of the KV in the desired format, leaving the value as it > was. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-5032) Add other DELETE type information into the delete bloom filter to optimize the time range query
[ https://issues.apache.org/jira/browse/HBASE-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-5032. --- Resolution: Fixed Fix Version/s: 0.89-fb > Add other DELETE type information into the delete bloom filter to optimize > the time range query > --- > > Key: HBASE-5032 > URL: https://issues.apache.org/jira/browse/HBASE-5032 > Project: HBase > Issue Type: Improvement >Reporter: Liyin Tang >Assignee: Adela Maznikar > Fix For: 0.89-fb > > > To speed up time range scans we need to seek to the maximum timestamp of the > requested range,instead of going to the first KV of the (row, column) pair > and iterating from there. If we don't know the (row, column), e.g. if it is > not specified in the query, we need to go to end of the current row/column > pair first, get a KV from there, and do another seek to (row', column', > timerange_max) from there. We can only skip over to the timerange_max > timestamp when we know that there are no DeleteColumn records at the top of > that row/column with a higher timestamp. We can utilize another Bloom filter > keyed on (row, column) to quickly find that out. (From HBASE-4962) > So the motivation is to save seek ops for scanning time-range queries if we > know there is no delete for this row/column. > From the implementation perspective, we have already had a delete family > bloom filter which contains all the delete family key values. So we can reuse > the same bloom filter for all other kinds of delete information such as > delete columns or delete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (HBASE-6967) [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row.
[ https://issues.apache.org/jira/browse/HBASE-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-6967 stopped by Adela Maznikar. > [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in > a single row. > --- > > Key: HBASE-6967 > URL: https://issues.apache.org/jira/browse/HBASE-6967 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > > Introduce an interface for enabling hooks in StoreScanner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (HBASE-6967) [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row.
[ https://issues.apache.org/jira/browse/HBASE-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-6967 started by Adela Maznikar. > [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in > a single row. > --- > > Key: HBASE-6967 > URL: https://issues.apache.org/jira/browse/HBASE-6967 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > > Introduce an interface for enabling hooks in StoreScanner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6967) [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row.
[ https://issues.apache.org/jira/browse/HBASE-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar resolved HBASE-6967. --- Resolution: Fixed Fix Version/s: 0.89-fb > [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in > a single row. > --- > > Key: HBASE-6967 > URL: https://issues.apache.org/jira/browse/HBASE-6967 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > Fix For: 0.89-fb > > > Introduce an interface for enabling hooks in StoreScanner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8688) Add a choice for single/multiple throttler for callqueue
[ https://issues.apache.org/jira/browse/HBASE-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-8688: -- Summary: Add a choice for single/multiple throttler for callqueue (was: Add a choice for single/multiple throtller for callqueue) > Add a choice for single/multiple throttler for callqueue > > > Key: HBASE-8688 > URL: https://issues.apache.org/jira/browse/HBASE-8688 > Project: HBase > Issue Type: Improvement >Reporter: Adela Maznikar >Assignee: Adela Maznikar > > The general idea is to have two throttles, such that we throttle larger and > smaller responses differently. If we know what is the typical size of the > response to a client, we can limit the possibilities of being blocked by > large requests. This will help in case when the client is issuing large > requests, the smaller ones will not be blocked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8688) Add a choice for single/multiple throtller for callqueue
Adela Maznikar created HBASE-8688: - Summary: Add a choice for single/multiple throtller for callqueue Key: HBASE-8688 URL: https://issues.apache.org/jira/browse/HBASE-8688 Project: HBase Issue Type: Improvement Reporter: Adela Maznikar Assignee: Adela Maznikar The general idea is to have two throttles, such that we throttle larger and smaller responses differently. If we know what is the typical size of the response to a client, we can limit the possibilities of being blocked by large requests. This will help in case when the client is issuing large requests, the smaller ones will not be blocked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8114) [89-fb] Interrupt the server processing rpc call when client has closed the connection
[ https://issues.apache.org/jira/browse/HBASE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603888#comment-13603888 ] Adela Maznikar commented on HBASE-8114: --- I am working on a solution and we will definitely submit a patch on the [89-fb] branch. > [89-fb] Interrupt the server processing rpc call when client has closed the > connection > -- > > Key: HBASE-8114 > URL: https://issues.apache.org/jira/browse/HBASE-8114 > Project: HBase > Issue Type: Improvement >Reporter: Adela Maznikar >Assignee: Adela Maznikar > > When the client issues a request the server will start processing, but if the > request is a big get/scan the client can close the connection (for example > timeout is reached) while the server is still processing the request. This > improvement should interrupt the server executing the call after the client > has closed the connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8114) [89-fb] Interrupt the server processing rpc call when client has closed the connection
[ https://issues.apache.org/jira/browse/HBASE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-8114: -- Summary: [89-fb] Interrupt the server processing rpc call when client has closed the connection (was: [89-fb] Interrupt the server processing a request when client has closed the connection) > [89-fb] Interrupt the server processing rpc call when client has closed the > connection > -- > > Key: HBASE-8114 > URL: https://issues.apache.org/jira/browse/HBASE-8114 > Project: HBase > Issue Type: Improvement >Reporter: Adela Maznikar >Assignee: Adela Maznikar > > When the client issues a request the server will start processing, but if the > request is a big get/scan the client can close the connection (for example > timeout is reached) while the server is still processing the request. This > improvement should interrupt the server executing the call after the client > has closed the connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8114) [89-fb] Interrupt the server processing a request when client has closed the connection
[ https://issues.apache.org/jira/browse/HBASE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-8114: -- Summary: [89-fb] Interrupt the server processing a request when client has closed the connection (was: [89-fb] Interrupt the server execution when client has closed the connection) > [89-fb] Interrupt the server processing a request when client has closed the > connection > --- > > Key: HBASE-8114 > URL: https://issues.apache.org/jira/browse/HBASE-8114 > Project: HBase > Issue Type: Improvement >Reporter: Adela Maznikar >Assignee: Adela Maznikar > > When the client issues a request the server will start processing, but if the > request is a big get/scan the client can close the connection (for example > timeout is reached) while the server is still processing the request. This > improvement should interrupt the server executing the call after the client > has closed the connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8114) [89-fb] Interrupt the server execution when client has closed the connection
Adela Maznikar created HBASE-8114: - Summary: [89-fb] Interrupt the server execution when client has closed the connection Key: HBASE-8114 URL: https://issues.apache.org/jira/browse/HBASE-8114 Project: HBase Issue Type: Improvement Reporter: Adela Maznikar Assignee: Adela Maznikar When the client issues a request the server will start processing, but if the request is a big get/scan the client can close the connection (for example timeout is reached) while the server is still processing the request. This improvement should interrupt the server executing the call after the client has closed the connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7707) [89-fb] New copy table utility
[ https://issues.apache.org/jira/browse/HBASE-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565730#comment-13565730 ] Adela Maznikar commented on HBASE-7707: --- Yes, it should work the same. > [89-fb] New copy table utility > -- > > Key: HBASE-7707 > URL: https://issues.apache.org/jira/browse/HBASE-7707 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > > We need a new utility which instead of doing Scan and Put will Scan the table > and create HFiles which will be bulkloaded afterwards into a new table. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7707) [89-fb] New copy table utility
[ https://issues.apache.org/jira/browse/HBASE-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-7707: -- Description: We need a new utility which instead of doing Scan and Put will Scan the table and create HFiles which will be bulkloaded afterwards into a new table. was: We noticed some issues using CopyTable so we want to work on a new utility for table copying. We will keep the old CopyTable and create a new class which will use TableInputFormat + HFileOutputFormat + Bulkload mechanism. We will have a MR job that will load the table and create HFiles and then using a bulkload we will load those HFiles into a new table. The tool will also allow specifying start and stop row, if the user doesn't want to copy the whole table. > [89-fb] New copy table utility > -- > > Key: HBASE-7707 > URL: https://issues.apache.org/jira/browse/HBASE-7707 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > > We need a new utility which instead of doing Scan and Put will Scan the table > and create HFiles which will be bulkloaded afterwards into a new table. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7707) [89-fb] New copy table utility
Adela Maznikar created HBASE-7707: - Summary: [89-fb] New copy table utility Key: HBASE-7707 URL: https://issues.apache.org/jira/browse/HBASE-7707 Project: HBase Issue Type: New Feature Reporter: Adela Maznikar Assignee: Adela Maznikar Priority: Minor We noticed some issues using CopyTable so we want to work on a new utility for table copying. We will keep the old CopyTable and create a new class which will use TableInputFormat + HFileOutputFormat + Bulkload mechanism. We will have a MR job that will load the table and create HFiles and then using a bulkload we will load those HFiles into a new table. The tool will also allow specifying start and stop row, if the user doesn't want to copy the whole table. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6967) [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row.
[ https://issues.apache.org/jira/browse/HBASE-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-6967: -- Summary: [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row. (was: Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row.) > [89-fb] Introduce a hook in StoreScanner to allow aggregation of KeyValues in > a single row. > --- > > Key: HBASE-6967 > URL: https://issues.apache.org/jira/browse/HBASE-6967 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > > Introduce an interface for enabling hooks in StoreScanner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7099) create compaction hooks
[ https://issues.apache.org/jira/browse/HBASE-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491042#comment-13491042 ] Adela Maznikar commented on HBASE-7099: --- Andrew, I am working on the 89-fb branch. Sorry for the confusion, will modify the summary now. Thanks > create compaction hooks > > > Key: HBASE-7099 > URL: https://issues.apache.org/jira/browse/HBASE-7099 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar > > Create compaction hooks which should be used to modify the value of the KV > during compaction. The possible modifications would include: skipping the KV, > modifying the value of the KV in the desired format, leaving the value as it > was. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7099) [89-fb] Create compaction hooks
[ https://issues.apache.org/jira/browse/HBASE-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adela Maznikar updated HBASE-7099: -- Summary: [89-fb] Create compaction hooks (was: create compaction hooks ) > [89-fb] Create compaction hooks > > > Key: HBASE-7099 > URL: https://issues.apache.org/jira/browse/HBASE-7099 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar > > Create compaction hooks which should be used to modify the value of the KV > during compaction. The possible modifications would include: skipping the KV, > modifying the value of the KV in the desired format, leaving the value as it > was. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7099) create compaction hooks
Adela Maznikar created HBASE-7099: - Summary: create compaction hooks Key: HBASE-7099 URL: https://issues.apache.org/jira/browse/HBASE-7099 Project: HBase Issue Type: New Feature Reporter: Adela Maznikar Assignee: Adela Maznikar Create compaction hooks which should be used to modify the value of the KV during compaction. The possible modifications would include: skipping the KV, modifying the value of the KV in the desired format, leaving the value as it was. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6967) Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row.
[ https://issues.apache.org/jira/browse/HBASE-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474400#comment-13474400 ] Adela Maznikar commented on HBASE-6967: --- One example is aggregating all KV's for a row into one and write that value. > Introduce a hook in StoreScanner to allow aggregation of KeyValues in a > single row. > --- > > Key: HBASE-6967 > URL: https://issues.apache.org/jira/browse/HBASE-6967 > Project: HBase > Issue Type: New Feature >Reporter: Adela Maznikar >Assignee: Adela Maznikar >Priority: Minor > > Introduce an interface for enabling hooks in StoreScanner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6967) Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row.
Adela Maznikar created HBASE-6967: - Summary: Introduce a hook in StoreScanner to allow aggregation of KeyValues in a single row. Key: HBASE-6967 URL: https://issues.apache.org/jira/browse/HBASE-6967 Project: HBase Issue Type: New Feature Reporter: Adela Maznikar Assignee: Adela Maznikar Priority: Minor Introduce an interface for enabling hooks in StoreScanner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6872) Number of records written/read per second on regionserver level
Adela Maznikar created HBASE-6872: - Summary: Number of records written/read per second on regionserver level Key: HBASE-6872 URL: https://issues.apache.org/jira/browse/HBASE-6872 Project: HBase Issue Type: New Feature Components: regionserver Reporter: Adela Maznikar Priority: Minor Regionserver level metrics that shows the number of records written/read per second. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
