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. cheers, ulrich On Wed, Jan 25, 2012 at 10:04 PM, Mike Spreitzer <mspre...@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 <http://goog_958005736>http://www.activequant.com Connect online: https://www.xing.com/profile/Ulrich_Staudinger
