hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Standalone == Dev Only?
Date Fri, 06 Mar 2015 16:24:50 GMT
Hi Joseph,

Generally speaking we've thought of stand-alone mode a dev/testing because
the common use case for HBase is larger datasets. There's nothing
specifically non-production about a stand-alone mode, though you obviously
won't have high-availability, and there may be bugs in the code paths that
are less used. For instance, issues like HADOOP-7844 pop up are not not
necessarily prioritized because local mode isn't the common production case.

There's also been discussion of refactoring HBase to extract its storage
engine, making it available as a library that can be embedded in other
applications. I'm not sure of the status of that discussion (or if there's
a ticket for it), but it may also be suitable for your use-case. CC Enis as
he's been vocal about this recently.



On Tue, Mar 3, 2015 at 7:32 AM, Rose, Joseph <
Joseph.Rose@childrens.harvard.edu> wrote:

> Folks,
> I’m new to HBase (but not new to these sorts of data stores.) I think
> HBase would be a good fit for a project I’m working on, except for one
> thing: the amount of data we’re talking about, here, is far smaller than
> what’s usually recommended for HBase. As I read the docs, though, it seems
> like the main argument against small datasets is replication: HDFS requires
> a bunch of nodes right from the start and that’s overkill for my use.
> So, what’s the motivation behind labeling standalone HBase deployments
> “dev only”? If all I really need is a table full of keys and all of that
> will fit comfortably in a single node, and if I have my own backup solution
> (literally, backing up the VM on which it’ll run), why bother with HDFS and
> distributed HBase?
> (As an aside, I could go to something like Berkeley DB but then I don’t
> get all the nice coprocessors and filters and so on, not to mention
> cell-level security. Because I work with patient data the latter is
> definitely a huge win.)
> Thanks for your help.
> Joseph Rose
> Intelligent Health Laboratory
> Boston Children’s Hospital

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message