Apache
/
hbase
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HBASE-24455 Correct the doc of "On the number of column families" (#1799) 

Signed-off-by: Wellington Ramos Chevreuil <wchevreuil@apache.org>
Signed-off-by: Viraj Jasani <vjasani@apache.org>
This commit is contained in:
bsglz 2020-06-01 16:38:07 +08:00 committed by GitHub
parent f5b90fcc44
commit 716702a349
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/main/asciidoc/_chapters/schema_design.adoc
View File

@ -127,8 +127,9 @@ ____
== On the number of column families == On the number of column families
HBase currently does not do well with anything above two or three column families so keep the number of column families in your schema low. HBase currently does not do well with anything above two or three column families so keep the number of column families in your schema low.
Currently, flushing and compactions are done on a per Region basis so if one column family is carrying the bulk of the data bringing on flushes, the adjacent families will also be flushed even though the amount of data they carry is small. Currently, flushing is done on a per Region basis so if one column family is carrying the bulk of the data bringing on flushes, the adjacent families will also be flushed even though the amount of data they carry is small.
When many column families exist the flushing and compaction interaction can make for a bunch of needless i/o (To be addressed by changing flushing and compaction to work on a per column family basis). For more information on compactions, see <<compaction>>. When many column families exist the flushing interaction can make for a bunch of needless i/o (To be addressed by changing flushing to work on a per column family basis).
In addition, compactions triggered at table/region level will happen per store too.
Try to make do with one column family if you can in your schemas. Try to make do with one column family if you can in your schemas.
Only introduce a second and third column family in the case where data access is usually column scoped; i.e. Only introduce a second and third column family in the case where data access is usually column scoped; i.e.