To make Configuration 4 possible (last slide in http://www.edwardcapriolo.com/roller/edwardcapriolo/resource/memcache.odp ) -- Big Request Load, not so Big Data.
Otis -- We're hiring HBase hackers for Data Mining and Analytics http://blog.sematext.com/2011/04/18/hiring-data-mining-analytics-machine-learning-hackers/ ----- Original Message ---- > From: Jean-Daniel Cryans <[email protected]> > To: [email protected] > Sent: Tue, April 19, 2011 5:28:46 PM > Subject: Re: Region replication? > > I don't know why you would want to serve from other region servers if > all they did was transferring data, the current situation would be > better. > > J-D > > On Tue, Apr 19, 2011 at 2:26 PM, Otis Gospodnetic > <[email protected]> wrote: > > Thanks J-D! > > > > Yeah, what you describe below is also something that I think Edward > > pointed >out > > in some of his slides - that you could route all requests for X to the place > > where X is when you don't want to have X cached (in app-level caches and/or > > OS-level caches) on multiple servers, but that sometimes you do want to >"waste" > > memory like this because you have to spread requests for X over more >servers. > > > > Are these two modes going to be supported in HBase? > > > > Thanks, > > Otis > > ---- > > We're hiring HBase hackers for Data Mining and Analytics > > >http://blog.sematext.com/2011/04/18/hiring-data-mining-analytics-machine-learning-hackers/ > > > > > > > > > > > > > ----- Original Message ---- > >> From: Jean-Daniel Cryans <[email protected]> > >> To: [email protected] > >> Sent: Tue, April 19, 2011 5:10:07 PM > >> Subject: Re: Region replication? > >> > >> We have something on the menu: > >> https://issues.apache.org/jira/browse/HBASE-2357 Coprocessors: Add > >> read-only region replicas (slaves) for availability and fast region > >> recovery > >> > >> Something to keep in mind is that you have to cache the data for each > >> replica, so a row could be in 3 different caches (which also have to > >> be warmed). I guess this is useful for very hot rows compared to a > >> much larger read distribution, in which case you'd really want to > >> cache it only once else you'd need 3x the memory to hold your dataset > >> in cache. > >> > >> J-D > >> > >> On Tue, Apr 19, 2011 at 12:33 PM, Otis Gospodnetic > >> <[email protected]> wrote: > >> > Hi, > >> > > >> > I imagine lots of HBase folks have read or will want to read > >> > >http://blog.milford.io/2011/04/why-i-am-very-excited-about-datastaxs-brisk/ > > , > >> > including comments. > >> > > >> > My question has to do with one of the good comments from Edward >Capriolo, > >>who > >> > pointed out that some of the Configurations he described in his >Cassandra > >> as > >> > Memcached talk ( > >> > http://www.edwardcapriolo.com/roller/edwardcapriolo/resource/memcache.odp > >> > >) > >>are > >> > not possible with HBase because in HBase there is only 1 copy of any > given > >> > Region and it lives on a single RegionServer (I'm assuming this is > >>correct?), > >> > thus making it impossible to spread reads of data from one Region over > >>multiple > >> > RegionServers: > >> > > >> > >>>http://blog.milford.io/2011/04/why-i-am-very-excited-about-datastaxs-brisk/#comment-187253604 >4 > >> > >> > > >> > > >> > So I poked around on search-hadoop.com and JIRA, and looked at > >> > http://hbase.apache.org/book/regions.arch.html to see about this > > limitation, > >> > whether it's even mentioned as a limitation, whether there are plans to > >>change > >> > it or if there are some configuration alternatives that would make > >> > some >of > >>those > >> > configurations described by Ed possible with HBase, but I actually >didn't > >>find > >> > any explicit information about that. > >> > > >> > Would anyone care to comment? :) > >> > > >> > Many thanks, > >> > Otis > >> > -- > >> > We're hiring HBase hackers for Data Mining and Analytics > >> > >>>http://blog.sematext.com/2011/04/18/hiring-data-mining-analytics-machine-learning-hackers/ >/ > >> > >> > > >> > > >
