Ok, but here’s the thing… you extrapolate the design out… each column with a subordinate record will get its own CF. Simple examples can go very bad when you move to real life.
Again you need to look at hierarchical databases and not think in terms of relational. To give you a really good example… look at a point of sale system in Pick/Revelation/U2 … You are great at finding a specific customer’s order and what they ordered. You suck at telling me how many customers ordered that widget in red. during the past month’s promotion. (You’ll need to do a map/reduce for that. ) This is why you have to go in to secondary indexing. (Which is a whole different ball of wax from inverted tables to SOLR. ) But to really grok hbase, you have to understand data structures and databases beyond relational. On Sep 10, 2014, at 6:33 PM, Wilm Schumacher <wilm.schumac...@cawoom.com> wrote: > > > Am 10.09.2014 um 17:33 schrieb Michael Segel: >> Because you really don’t want to do that since you need to keep the number >> of CFs low. > in my example the number of CFs is 1. So this is not a problem. > > Best wishes, > > Wilm >
