HBASE-22873 Typo in block caching docs
Signed-off-by: Reid Chan <reidchan@apache.org>
This commit is contained in:
parent
43a0ec80fa
commit
7903f55c18
|
@ -837,7 +837,7 @@ Here are two use cases:
|
||||||
Setting block caching on such a table is a waste of memory and CPU cycles, more so that it will generate more garbage to pick up by the JVM.
|
Setting block caching on such a table is a waste of memory and CPU cycles, more so that it will generate more garbage to pick up by the JVM.
|
||||||
For more information on monitoring GC, see <<trouble.log.gc>>.
|
For more information on monitoring GC, see <<trouble.log.gc>>.
|
||||||
* Mapping a table: In a typical MapReduce job that takes a table in input, every row will be read only once so there's no need to put them into the block cache.
|
* Mapping a table: In a typical MapReduce job that takes a table in input, every row will be read only once so there's no need to put them into the block cache.
|
||||||
The Scan object has the option of turning this off via the setCaching method (set it to false). You can still keep block caching turned on on this table if you need fast random read access.
|
The Scan object has the option of turning this off via the setCacheBlocks method (set it to false). You can still keep block caching turned on on this table if you need fast random read access.
|
||||||
An example would be counting the number of rows in a table that serves live traffic, caching every block of that table would create massive churn and would surely evict data that's currently in use.
|
An example would be counting the number of rows in a table that serves live traffic, caching every block of that table would create massive churn and would surely evict data that's currently in use.
|
||||||
|
|
||||||
[[data.blocks.in.fscache]]
|
[[data.blocks.in.fscache]]
|
||||||
|
|
Loading…
Reference in New Issue