This is exactly the kind of feedback I'm looking for thanks, Barney. So its sounds like you cache the data you get from HBase in a session-based memory? Are you using a Java EE HttpSession? (I'm less familiar with django/rails equivalent but I'm assuming they exist) Or are you using a memory cache provider like ehcache or memcache(d)?
Can you tell me more about your experience with latency and why you say that? Barney Frank wrote: > > I am using Hbase to store visitor level clickstream-like data. At the > beginning of the visitor session I retrieve all the previous session data > from hbase and use it within my app server and massage it a little and > serve > to the consumer via web services. Where I think you will run into the > most > problems is your latency requirement. > > Just my 2 cents from a user. > > On Tue, Mar 9, 2010 at 9:45 AM, jaxzin <brian.r.jack...@espn3.com> wrote: > >> >> Hi all, I've got a question about how everyone is using HBase. Is anyone >> using its as online data store to directly back a web service? >> >> The text-book example of a weblink HBase table suggests there would be an >> associated web front-end to display the information in that HBase table >> (ex. >> search results page), but I'm having trouble finding evidence that anyone >> is >> servicing web traffic backed directly by an HBase instance in practice. >> >> I'm evaluating if HBase would be the right tool to provide a few things >> for >> a large-scale web service we want to develop at ESPN and I'd really like >> to >> get opinions and experience from people who have already been down this >> path. No need to reinvent the wheel, right? >> >> I can tell you a little about the project goals if it helps give you an >> idea >> of what I'm trying to design for: >> >> 1) Highly available (It would be a central service and an outage would >> take >> down everything) >> 2) Low latency (1-2 ms, less is better, more isn't acceptable) >> 3) High throughput (5-10k req/sec at worse case peak) >> 4) Unstable traffic (ex. Sunday afternoons during football season) >> 5) Small data...for now (< 10 GB of total data currently, but HBase could >> allow us to design differently and store more online) >> >> The reason I'm looking at HBase is that we've solved many of our scaling >> issues with the same basic concepts of HBase (sharding, flattening data >> to >> fit in one row, throw away ACID, etc) but with home-grown software. I'd >> like to adopt an active open-source project if it makes sense. >> >> Alternatives I'm also looking at: RDBMS fronted with Websphere eXtreme >> Scale, RDBMS fronted with Hibernate/ehcache, or (the option I understand >> the >> least right now) memcached. >> >> Thanks, >> Brian >> -- >> View this message in context: >> http://old.nabble.com/Use-cases-of-HBase-tp27837470p27837470.html >> Sent from the HBase User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://old.nabble.com/Use-cases-of-HBase-tp27837470p27838006.html Sent from the HBase User mailing list archive at Nabble.com.
