Thanks for the reply Joey. This sounds better than using uuids .. I will give it a shot.
One more thing, with such a setup, will it still be possible to do map reduce jobs ? Is it possible to create a single scanner that will look at all the prefixes ? if not, is it possible to map reduce with multiple scanners ? Thanks a lot for your help. ------------------------------ *From:* Joey Echeverria <[email protected]> *To:* Sam Seigal <[email protected]> *Sent:* Wed, June 8, 2011 5:08:32 PM *Subject:* Re: hbase hashing algorithm and schema design A better option than a uuid would be to take a hash of the eventid-timestamp, modulo some value (maybe 4x #regionservers) and add that to the front of the key. If you need to scan, create a scanner per prefix and merge the results. -Joey On Jun 8, 2011 4:54 PM, "Sam Seigal" <[email protected]> wrote: > On Wed, Jun 8, 2011 at 12:40 AM, tsuna <[email protected]> wrote: > >> On Tue, Jun 7, 2011 at 7:56 PM, Kjew Jned <[email protected]> wrote: >> > I was studying the OpenTSDB example, where they also prefix the row keys >> with >> > event id. >> > >> > I further modified my row keys to have this -> >> > >> > <eventid> <uuid> <yyyy-mm-dd> >> > >> > The uuid is fairly unique and random. >> > Is appending a uuid to the event id help the distribution ? >> >> Yes it will help the distribution, but it will also make certain query >> patterns harder. You can no longer scan for a time range, for a given >> eventid. How to solve this problem depends on how you generate the >> UUIDs. >> >> I wouldn't recommend doing this unless you've already tried simpler >> approaches and reached the conclusion that they don't work. Many >> people seem to be afraid of creating hot spots in their tables without >> having first-hand evidence that the hot spots would actually be a >> problem. >> >> >> >> > Can I not use regex row filters to query for date ranges ? There is an added > overhead for the client to > order them, and it is not an efficient query, but it is certainly possible > to do so ? Am I wrong ? > > > >> > Let us say if I have 4 region servers to start off with and I start the >> >> If you have only 4 region servers, your goal should be to have roughly >> 25% of writes going to each server. It doesn't matter if the 25% >> slice of one server is going to a single region or not. As long as >> all the writes don't go to the same row (which would cause lock >> contention on that row), you'll get the same kind of performance. >> > > I am worried about the following scenario, hence putting a lot of thought > into how to design this schema. > > For example, for simplicity sake, I only have two event Ids A and B, and the > traffic is equally distributed > between them i.e. 50% of my traffic is event A and 50% is event B. I have > two region servers running, on > two physical nodes with the following schema - > > <eventid> <timestamp> > > Ideally, I now have all of A traffic going into regionServerA and all of B > traffic going into regionserver B. > The cluster is able to hold this traffic, and the write load is distributed > 50-50. > > However, now I reach a point where I need to scale, since the two clusters > are not being able to > cope with the write traffic. Adding extra regionservers to the cluster is > not going to make any difference > , since only the physical machine holding the tail end of the region is the > one that will receive > the traffic. Most of my other cluster is going to be idle. > > To generalize, if I want to scale where the # of machines is greater than > the # of unique event ids, I have no way to > distribute the load in an efficient manner, since I cannot distribute the > load of a single event id across multiple machines > (without adding a uuid somewhere in the middle and sacrificing data locality > on ordered timestamps). > > Do you think my concern is genuine ? Thanks a lot for your help. > > >> >> > workload, how does HBase decide how many regions is it going to create, >> and what >> > key is going to go into what region ? >> >> Your table starts as a single region. As this region fills up, it'll >> split. Where it split is chosen by HBase. HBase tries to spit the >> region "in the middle", so that roughly the number of keys ends up in >> each new daughter region. >> >> You can also manually pre-split a table (from the shell). This can be >> advantageous in certain situations where you know what your table will >> look like and you have a very high write volume coupled with >> aggressive latency requirements for >95th percentile. >> > >> > I could have gone with something like >> > >> > <uuid><eventid><yyyy-mm-dd> , but would not like to, since my queries are >> always >> > going to be against a particular event id type, and i would like them to >> be >> > spatially located. >> >> If you have a lot of data per <eventid>, then putting the <uuid> in >> between the <eventid> and the <yyyy-mm-dd> will screw up data locality >> anyway. But the exact details depend on how you pick the <uuid>. >> >> -- >> Benoit "tsuna" Sigoure >> Software Engineer @ www.StumbleUpon.com <http://www.stumbleupon.com/> >>
