Thanks Mohammad, By saying the major purpose is to host very large tables (implying a smaller number of them), are you referring to anything other than the memstores per column family taking up sizable portions of physical memory? Are there other components or design aspects that make using large numbers of tables inadvisable?
On Sun, Aug 5, 2012 at 5:55 PM, Mohammad Tariq <[email protected]> wrote: > Hello sir, > > Going for a single table with 30+ rows would be a better choice, > if the data from all the sources is not very different. Since, you are > considering Hbase as your data store, it wouldn't be wise to have > several small rows. The major purpose of Hbase is to host very large > tables that may go beyond billions of rows and millions of columns. > > Regards, > Mohammad Tariq > > > On Mon, Aug 6, 2012 at 3:18 AM, Eric Czech <[email protected]> wrote: >> I need to support data that comes from 30+ sources and the structure >> of that data is consistent across all the sources, but what I'm not >> clear on is whether or not I should use 30+ tables with roughly the >> same format or 1 table where the row key reflects the source. >> >> Anybody have a strong argument one way or the other? >> >> Thanks!
