Probably not, based on the active development people are talking about today. Then again, it's open source. AFAIK, the current limitations are an implementation detail, not a design decision. Provide a patch to resolve those limitations, get it through review, and committed, you'll have the foundations for your feature.
On Monday, December 23, 2013, 乃岩 wrote: > So, in the future, Hbase will not support a big number of CFs, right? > Never to be a column-oriented data store? > > Please confirm it, so that we will reconsider if take Hbase as part of our > roadmap. Thanks! > > > > > NaiYan. > > From: Stack > Date: 2013-12-24 06:35 > To: HBase Dev List > CC: sohomodern; Andrew Purtell > Subject: Re: Re: About HBASE-3149 > I'd do non-relational database as per Jon... just make the change Nick.... > I'll push out later no worries (it is a bit of a pain... learn it by all > means but this is not cause enough) > > > > On Mon, Dec 23, 2013 at 1:03 PM, Jonathan Hsieh > <[email protected]<javascript:;>> > wrote: > > I usually say, non-relational database. > > Jon. > > > > On Mon, Dec 23, 2013 at 11:52 AM, Nick Dimiduk > <[email protected]<javascript:;>> > wrote: > > > > On Sat, Dec 21, 2013 at 7:07 PM, 乃岩 <[email protected] <javascript:;>> > wrote: > > > > > Hello, Thank you for your reply. > > > If use only 1 or 2 CFs, why Hbase say it's a column data store? It's > > > actually row-based data store!! > > > > > > > Nit: I don't think HBase claims to be a column-oriented store. > > "Column-family," yes... But now that I write this, I see right on the > > project homepage: "Apache HBase is an open-source, distributed, > versioned, > > *column-oriented* store modeled after ..." (emphasis my own). > > > > From: Andrew Purtell > > > Date: 2013-12-22 04:26 > > > To: [email protected] <javascript:;>; sohomodern > > > Subject: Re: About HBASE-3149 > > > Bear in mind that how many files you'll have open simultaneously is a > > > function of number of regions, number of column families, and how > > > compaction organizes the HBase files on disk (the strategy in effect > and > > > its parameters, the current ingest rate, and so on). You call ballpark > > this > > > as such: If you have one column family in a table, and store data into > > all > > > the regions, then you will have one file open on the cluster per > region, > > or > > > more. If you have 100,000 column families in a table, and store data > into > > > all the regions and CFs, then you will have 100,000 files open on the > > > cluster per region, *or more*. You will run into OS and HDFS levels > > > attempting this, I don't recommend it. > > > > > > > > > I don't think any reasonable schema design needs produce a requirement > > for > > > 100,000 column *families*. You can have any number of keys with > > > <column>:<qualifier> in a column family, varying the <qualifier> to > > 100,000 > > > or 1,000,000 or more unique values is no problem. Can you say more > about > > > what you are trying to accomplish? > > > > > > > > > > > > On Sat, Dec 21, 2013 at 7:17 AM, 乃岩 <[email protected] <javascript:;>> > wrote: > > > > > > Hi, > > > Can anybody tell me if future HBase release will integrate 3149 for > > > Make flush decisions per column family？ > > > > > > By the way, for current HBase, if the simultaneous flush is the only > > > issue? I mean, to create 100000 CFs will not be a problem, right? > > > > > > Thanks in advance! > > > > > > > > > > > > > > > > > > N.Y. > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > - Andy > > > > > > Problems worthy of attack prove their worth by hitting back. - Piet > Hein > > > (via Tom White) > > > > > > > > > > -- > // Jonathan Hsieh (shay) > // Software Engineer, Cloudera > // [email protected] <javascript:;>
