>>This would cause extreme version inflation in HBase without
>>appropriate action to mitigate it.
Can you please expand on this? What exactly can be done to mitigate this?
On Tue, Jul 13, 2010 at 12:48 AM, Ryan Rawson <[EMAIL PROTECTED]> wrote:
> To answer your question in broader terms:
> 1. Sessions are tricky, they tend to have a 1:1 read/write model.
> This would cause extreme version inflation in HBase without
> appropriate action to mitigate it. Generally speaking though, I
> believe in HBase as a high performance low latency data store, so it
> should fit nicely any systems that require those things.
> 2. If you can achieve the right level of performance in data retrieval, why
> 3. Very complex relational-based data might not be appropriate to
> store in HBase. For example, indexes in HBase are not free and require
> a bunch of things to make it happen.
> Infrequently written, but heavily read things might not make sense in
> HBase... ie: things you might use a CDN for. Software downloads. Very
> large media. You might be able to use HBase as the source for things
> that are cached in a layer like varnish or akamai.
> On Mon, Jul 12, 2010 at 9:36 PM, S Ahmed <[EMAIL PROTECTED]> wrote:
> > I realize that stumbleupon uses hbase for su.pr, and is currently using
> > hbase for new functionality but isn't necessarily going back and
> > everything to fit into the hbase model.
> > Having said that, do you guys think hbase could very well be used for
> > like:
> > 1. when a user logs in, keep the user session in hbase?
> > 2. for pages like:
> > So this involves all elements on the page, would this be possible and
> > importantly make sense with hbase?
> > 3. What sort of things/functionality do you see NOT being suitable in
> > experiences?
> > Thanks for your insights!