hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Staudinger <ustaudin...@activequant.com>
Subject Re: Important Question
Date Wed, 25 Jan 2012 21:20:01 GMT
Hey everybody,

with the risk of being flamed and bbqued...
to be absolutely honest, I think the NoSQL approach and with it HBase and
all other alternatives don't fit your use case at all. You have a complex
domain model, where it is very likely that you will want to search through
your domain space by all possible attributes of your domain model.

For example, patient has had diseases, prescriptions, etc. So, to make
access into your data space fast, you want to have indices. You want to
have sorting ascending and descending by all attributes.

And preferably you don't want to have to think about building indexing
logic yourself.

Above all, you want to have  referential integrity in your data space -
patient data is not like wall messages where it really doesn't matter that
much if one in a million is lost because something went awry. So
transactions should be supported.

On top of that, your patient data (not counting MRI scans or CT scans), is
probably not going to be more then 10 mb per patient (if at all) - with 1
million users, you would have something like 10 terrabyte of data. With
proper partitioning, you can easily manage that within an average database.

but i maybe wrong and i am looking forward to hear another opinion.


On Wed, Jan 25, 2012 at 10:04 PM, Mike Spreitzer <mspreitz@us.ibm.com>wrote:

> Just a couple more questions.  Your data will all be in one place, this is
> not a federated architecture, right?  How much data are we talking about?
> It sounds like you want to find/create/update/delete individual records
> and do simple aggregations over records identified by a conjunction of
> predicates on fields; is that right?
> Thanks,
> Mike (not on the hive mailing list)

Ulrich Staudinger

Connect online: https://www.xing.com/profile/Ulrich_Staudinger

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