HDFS is designed to not lose data if a few nodes fail. It holds multiple 
replicas of each block. Having said that - it also depends on the definition of 
"a few". Many companies are using HDFS as their central data store and it's 
proven at scale in production. It does not lose data arbitrarily, and neither 
does HBase. Have you come across a case where you experience data loss with 
either HDFS or HBase? We'd be curious to learn about it.

On Monday, May 14, 2012 at 12:35 PM, Srikanth P. Shreenivas wrote:

> Yes, agreed that data can be lost in any DB. However, isnt it more frequently 
> seen in NoSql DBs. In case of Hbase, Is it not possible for underlying HDFS 
> to lose data if nodes went down abrubtly few times.
> 
> 
> Andrew Purtell <andrew.purt...@gmail.com (mailto:andrew.purt...@gmail.com)> 
> wrote:
> 
> 
> Any data store may lose data, as a generic statement, so maybe you had 
> something more specific in mind?
> 
> On May 13, 2012, at 9:21 PM, "Srikanth P. Shreenivas" 
> <srikanth_shreeni...@mindtree.com (mailto:srikanth_shreeni...@mindtree.com)> 
> wrote:
> 
> > There is a possibility that you may lose data, and hence, I would not use 
> > it for first class data if data cannot be re-created.
> > If you can derive data from secondary source and store data in HBase for 
> > performance gains, then, it is a viable use case.
> > 
> > Regards,
> > Srikanth
> > 
> > -----Original Message-----
> > From: S Ahmed [mailto:sahmed1...@gmail.com]
> > Sent: Monday, May 14, 2012 7:52 AM
> > To: user@hbase.apache.org (mailto:user@hbase.apache.org); Otis Gospodnetic
> > Subject: Re: hbase as a primary store, or is it more for "2nd class" data?
> > 
> > Otis,
> > 
> > It kind of goes back to what I was saying earlier, if FB is using it for 
> > searching your inbox, or storing your chat messages or wall posts, I don't 
> > really think that is important (and really it isn't hehe)
> > 
> > I was just making an observation and wanted to get a feel for what others 
> > think. Obviously ever tool has its purpose and domain, and I was curious as 
> > to what others have seen in production usage etc.
> > 
> > (I do realize some use cases the data is very important like analytic data 
> > that usually correlates to advertising $$ etc.)
> > 
> > On Sun, May 13, 2012 at 10:00 PM, Otis Gospodnetic < 
> > otis_gospodne...@yahoo.com (mailto:otis_gospodne...@yahoo.com)> wrote:
> > 
> > > Hi Ahmed,
> > > 
> > > At Sematext we have a few SaaS products that use HBase as the primary
> > > data store. I hear Facebook uses HBase for some important stuff, too.
> > > ;) So far we've survived. HBase does have rough edges, but also good
> > > developers who are making it better every day.
> > > 
> > > Otis
> > > ----
> > > Performance Monitoring for Solr / ElasticSearch / HBase -
> > > http://sematext.com/spm
> > > 
> > > 
> > > 
> > > > ________________________________
> > > > From: S Ahmed <sahmed1...@gmail.com (mailto:sahmed1...@gmail.com)>
> > > > To: user@hbase.apache.org (mailto:user@hbase.apache.org)
> > > > Sent: Sunday, May 13, 2012 8:14 PM
> > > > Subject: hbase as a primary store, or is it more for "2nd class" data?
> > > > 
> > > > I'm interested to learn if people are using hbase as a primary store
> > > > or is it more for "2nd class" type data.
> > > > 
> > > > Pretend you have a CMS product, or eCommerce Saas application:
> > > > 
> > > > What I mean by this is, I consider "primary store" to mean storing
> > > > the actual content (say articles, or blog posts), category data, user
> > > > information, or shopping cart order, product information.
> > > > 
> > > > "2nd class" type data is data like metrics, analytics, log data, or
> > > > say index data (data that can be re-built via the primary store).
> > > > 
> > > > In general 2nd class data is data that if lost, it won't bring the
> > > business
> > > > to its knees.
> > > > 
> > > > What do you guys think, am I right?
> > > > 
> > > > i.e. if you are creating a Saas product, it wouldn't be advisible to
> > > > build it using hbase (or it will be kind of bleeding edge architecture).
> > > > 
> > > 
> > > 
> > 
> > 
> > ________________________________
> > 
> > http://www.mindtree.com/email/disclaimer.html 

Reply via email to