[
https://issues.apache.org/jira/browse/HBASE-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15207539#comment-15207539
]
stack commented on HBASE-14921:
-------------------------------
On the patch, up to this, a CellBlock was nothing but a CellScanner at read
time and a pride of Cells written by a Cell Codec sitting in a ByteBuffer or a
byte [] when write had finished. CellBlocks were a ghost because we were afraid
to commit in case it shut down our being able to do particular implementations
or optimizations behind the scenes.
In this patch, you appropriate CellBlock and give it a concret implementation
and one that does not respect the above (badly spec'd) CellBlock ghost
structure; you implement Map but not CellScanner (See IPCUtil for write-side
example of a "CellBlock' and RPCClientImpl#readResponse for how we read the
written CellBlocks... CellBlocks up to this have been in RPC tier only.... but
are a concept that should be throughout -- as you are trying to help us do). I
think you have to call this CellBlock thing that is in the patch something else.
The class comment on this CellBlock says "...CellBlock stores a constant number
of elements and is immutable after creation stage.". Looking at this
description makes me wonder if we couldn't do this with a Cell Codec? The
"SausageCodec" since it is making CellBlocks of constant size? Codec Interface
does not support this notion of Encoding in pieces... The Interface just wants
us to output to an OS. Would extending Codec help so you could make your Cell
sausages?
But hang on... I'll be back. This patch looks interesting....
> Memory optimizations
> --------------------
>
> Key: HBASE-14921
> URL: https://issues.apache.org/jira/browse/HBASE-14921
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0
> Reporter: Eshcar Hillel
> Assignee: Anastasia Braginsky
> Attachments: CellBlocksSegmentInMemStore.pdf,
> CellBlocksSegmentinthecontextofMemStore(1).pdf, HBASE-14921-V01.patch,
> HBASE-14921-V02.patch
>
>
> Memory optimizations including compressed format representation and offheap
> allocations
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
