Configuring hbase.hregion.percolumnfamilyflush.size.lower.bound for multi-family table should take into account pattern of write-load. Without proper configuration, undesired flush(es) would still happen.
Since this is a relatively new feature, user should perform some experiment(s) so that it fits the user's needs. Cheers On Wed, Jan 7, 2015 at 8:42 PM, Otis Gospodnetic <[email protected] > wrote: > Thanks Ted! > > So with HBASE-10201 in place, would N sparsely populated CFs with the same > key structure ever be a better choice than a single densely populated CF > with the same key structure? > > Thanks, > Otis > -- > Monitoring * Alerting * Anomaly Detection * Centralized Log Management > Solr & Elasticsearch Support * http://sematext.com/ > > > On Wed, Jan 7, 2015 at 12:31 PM, Ted Yu <[email protected]> wrote: > > > Please see HBASE-10201 which would come in 1.1.0 release. > > > > Cheers > > > > On Wed, Jan 7, 2015 at 9:10 AM, Otis Gospodnetic < > > [email protected] > > > wrote: > > > > > Hi, > > > > > > I recently came across this good thread about 1 vs. N ColumnFamilies, > the > > > max recommended number of CFs, dense vs. sparse structure, etc. -- > > > http://search-hadoop.com/m/TozMw1jqh262 > > > > > > This thread is from 2013. Even though people say HBase should handle > more > > > than 3 CFs, the docs still recommend to stick to 2-3 CFs. Is that > still > > > the case? > > > > > > See http://hbase.apache.org/book.html#number.of.cfs > > > > > > Also, the thread talks about lumpy CFs and the fact that all CFs would > > have > > > to be flushed whenever any one of them triggers compaction..... but I > > > remember something being changed in this space a while back. No? > > > > > > Thanks, > > > Otis > > > -- > > > Monitoring * Alerting * Anomaly Detection * Centralized Log Management > > > Solr & Elasticsearch Support * http://sematext.com/ > > > > > >
