J****R
发帖数: 373 | 1 hbase里面不同时间加的new column cell是怎么存储的？
理论上cells in same row all stay together.各位高手有知道detail的吗？ |
w**z
发帖数: 8232 | 2 不是很确定Hbase怎么做的，根据Google big table
应该是用 Memtable and LSM trees
Cassandra 里叫SSTable， 用 compaction 把SSTable compact起来。没有compact的就
在query 的时候merge
Hbase 应该同样的原理。
【在 J****R 的大作中提到】
: hbase里面不同时间加的new column cell是怎么存储的？
: 理论上cells in same row all stay together.各位高手有知道detail的吗？
|
J****R
发帖数: 373 | 3 那么只要加新的column就会触发compaction? 这unlimited columns岂不是没什么用。
。。。。
【在 w**z 的大作中提到】
: 不是很确定Hbase怎么做的，根据Google big table
: 应该是用 Memtable and LSM trees
: Cassandra 里叫SSTable， 用 compaction 把SSTable compact起来。没有compact的就
: 在query 的时候merge
: Hbase 应该同样的原理。
|
w**z
发帖数: 8232 | 4 No. You can't compact for every writes. It will kill your performance if you
do that.
Again, I am not so sure about HBase. In Cassandra, there are different
compaction strategies.
If the compactions don't happen often, the read performance will suffer
since the read will have to go through Mulitple SSTables.
【在 J****R 的大作中提到】
: 那么只要加新的column就会触发compaction? 这unlimited columns岂不是没什么用。
: 。。。。
|
f*******t
发帖数: 7549 | 5 不同column family的数据是分开存储的。hbase文件夹结构是
table / column family / hfile
不同column (qualifier)都是堆在一起的。
rowkey + column family + qualifier + timestamp才是真正的key，对应一个value。
“cell in same row”里的row如果指rowkey的话，只要cell的column family不同，就
不会存在一起。 |
J****R
发帖数: 373 | 6 这个我倒是知道。只是当put 一个新的column qualifier的时候存储结构是怎么回事一
直没搞清楚。因为理论上同一个row key的数据都是存储在一起的。如果在row1之后已
经写了row2的数据，那再增加一个row1的数据会怎么处理呢？难不成开始compaction?
【在 f*******t 的大作中提到】
: 不同column family的数据是分开存储的。hbase文件夹结构是
: table / column family / hfile
: 不同column (qualifier)都是堆在一起的。
: rowkey + column family + qualifier + timestamp才是真正的key，对应一个value。
: “cell in same row”里的row如果指rowkey的话，只要cell的column family不同，就
: 不会存在一起。
|
f*******t
发帖数: 7549 | 7 每个write先放进memory，隔一段时间或region占用内存过了一个threshold后flush到
一个新的HFile里。每个HFile都是sorted，读的时候差不多是对每个HFile做binary
search。
因为每次flush都会产生一个新的HFile，文件越攒越多肯定不行，所以有算是offline
的compaction把几个文件合并成一个。
【在 J****R 的大作中提到】
: 这个我倒是知道。只是当put 一个新的column qualifier的时候存储结构是怎么回事一
: 直没搞清楚。因为理论上同一个row key的数据都是存储在一起的。如果在row1之后已
: 经写了row2的数据，那再增加一个row1的数据会怎么处理呢？难不成开始compaction?
|
J****R
发帖数: 373 | 8 看样子compaction 的问题真的很麻烦。我原本想每个column是一个date,这样的话每增
加一天的data就得compact一次，看来似乎不是什么好主意。。。。。
offline
【在 f*******t 的大作中提到】
: 每个write先放进memory，隔一段时间或region占用内存过了一个threshold后flush到
: 一个新的HFile里。每个HFile都是sorted，读的时候差不多是对每个HFile做binary
: search。
: 因为每次flush都会产生一个新的HFile，文件越攒越多肯定不行，所以有算是offline
: 的compaction把几个文件合并成一个。
|
w**z
发帖数: 8232 | 9 compact doesn't happen for every writes. 仔细看看我上面的comments. spend
some time understanding it please. you need to get the basics.
【在 J****R 的大作中提到】
: 看样子compaction 的问题真的很麻烦。我原本想每个column是一个date,这样的话每增
: 加一天的data就得compact一次，看来似乎不是什么好主意。。。。。
:
: offline
|
J****R
发帖数: 373 | 10 这个我倒是知道。问题是不同的schema导致compaction时要处理的文件是否有区别？
比如一个store在compaction之后只有一个big store file了，那么当你再次在每个row
中都加入了新的column以后，这个文件是不是再次需要修改?修改后是不是又要进行
region splitting?
相反，如果已经写入的row不需要再加新的column，那么在一个store 只含有一个store
file的情况下做compaction，包含这部分数据的文件可能就不需要再处理了？
【在 w**z 的大作中提到】
: compact doesn't happen for every writes. 仔细看看我上面的comments. spend
: some time understanding it please. you need to get the basics.
|
|
|
f*******t
发帖数: 7549 | 11 HFile是immutable的。
compaction是把几个HFile合并写入一个临时文件，然后做一个文件系统的transaction
，分三步：
1.把原来的HFile删掉
2.把新的HFile放进column family的文件夹
3.在region里将旧的HFile信息删除，加进新的HFile。
我之前说过了，满足一定条件才会引起flush，加入新的column不会。另外region是按
row key的range分的，跟column没有任何关系。为什么怕region split？ |
w**z
发帖数: 8232 | 12 原理和Cassandra一样， Cassandra里叫sstable. 都是从Google big table 过来的。
楼主要花点时间了解基础。费了半天口舌，他还是不明白。
transaction
【在 f*******t 的大作中提到】
: HFile是immutable的。
: compaction是把几个HFile合并写入一个临时文件，然后做一个文件系统的transaction
: ，分三步：
: 1.把原来的HFile删掉
: 2.把新的HFile放进column family的文件夹
: 3.在region里将旧的HFile信息删除，加进新的HFile。
: 我之前说过了，满足一定条件才会引起flush，加入新的column不会。另外region是按
: row key的range分的，跟column没有任何关系。为什么怕region split？
|
f*******t
发帖数: 7549 | |
J****R
发帖数: 373 | 14 谢谢回复。可能是我没表述清楚。
假设某个regionA里面已经做过compaction,所以只有一个接近maxsize的HFile1，里面
存了3行数据
001:column1
002:column1
003:column1
那么当在每一行都加一个新的column2的时候，会在这个region folder里面产生一个新
的HFile2.里面也是3行数据：
001：column2
002：column2
003：column2
在下一次compaction的时候, sort data by key, 同一key的data需要存放在一起，从
而形成：
001：column1
001: column2
002: column1
002：column2
003: column1
003：column2
但是这个合并后的Hfile文件会超过maxsize，所以又要region split。导致产生一个新
的regionB,结果变成了：
regionA:
001：column1
001: column2
002: column1
002：column2
regionB:
003: column1
003：column2
以此类推，如果数据量已经很大了，所有row都要增加new column的时候，这种情况就
会反复发生，很多Hfile都需要重新做compaction。这就是我担心的。
相反，如果设计的schema中不需要增加 new column，而是增加新的row, 那么新增加的
数据很可能不在同一region. 原来regionA中不需要再加入新的Hfile, 那么原来的
HFile1可能就不需要做compaction.
transaction
【在 f*******t 的大作中提到】
: HFile是immutable的。
: compaction是把几个HFile合并写入一个临时文件，然后做一个文件系统的transaction
: ，分三步：
: 1.把原来的HFile删掉
: 2.把新的HFile放进column family的文件夹
: 3.在region里将旧的HFile信息删除，加进新的HFile。
: 我之前说过了，满足一定条件才会引起flush，加入新的column不会。另外region是按
: row key的range分的，跟column没有任何关系。为什么怕region split？
|
f*******t
发帖数: 7549 | 15 只要持续写入，hbase就会不断做compaction，你为什么这么怕它？？？
另外你多大数据量啊，还用担心region split？？？一个cluster存几百T数据没问题，
你还担心啥
【在 J****R 的大作中提到】
: 谢谢回复。可能是我没表述清楚。
: 假设某个regionA里面已经做过compaction,所以只有一个接近maxsize的HFile1，里面
: 存了3行数据
: 001:column1
: 002:column1
: 003:column1
: 那么当在每一行都加一个新的column2的时候，会在这个region folder里面产生一个新
: 的HFile2.里面也是3行数据：
: 001：column2
: 002：column2
|
J****R
发帖数: 373 | 16 我也希望事情能简单一点，但是设计数据库的时候，有些底层的东西不得不考虑。之前
跟一些用C* 和Hbase的人求教过经验。基本上比较一致的结论就是目前为止compaction
不管在哪，都还是很头疼的一件事情，另一件事情就是schema design，这一点C*尤其
需要谨慎。
Hbase 里面minor compaction 就不提了。major compaction 中并不是所有的HFile都
会参与，尤其是当存储的是immutable data。当某个region 中 Hfile 被合并到region
maxsize上限，会trigger region split。这之后原来的region中可能就不会再写入数
据，因为row key可能不会再映射到这个region.
如果schema设计成了每隔一段时间就在每一行都加一个新的column，那么已经存储的所
有Hfile都会被涉及到，做compaction的时候，这些文件都需要merge甚至trigger
region split。存储的数据多了以后，这个代价就相当大了。
【在 f*******t 的大作中提到】
: 只要持续写入，hbase就会不断做compaction，你为什么这么怕它？？？
: 另外你多大数据量啊，还用担心region split？？？一个cluster存几百T数据没问题，
: 你还担心啥
|
w**z
发帖数: 8232 | 17 C* is column family, adding new column doesn't mean schema change.
Compaction happens when new data is written to the database and flushed to
the disk as immutable File. So one row could live in different SSTable, in
order to perform the reads more efficiently, compaction needs to be
performed.
It doesn't seem like you understand the fundamental of the column family
based nosql database.
compaction
region
【在 J****R 的大作中提到】
: 我也希望事情能简单一点，但是设计数据库的时候，有些底层的东西不得不考虑。之前
: 跟一些用C* 和Hbase的人求教过经验。基本上比较一致的结论就是目前为止compaction
: 不管在哪，都还是很头疼的一件事情，另一件事情就是schema design，这一点C*尤其
: 需要谨慎。
: Hbase 里面minor compaction 就不提了。major compaction 中并不是所有的HFile都
: 会参与，尤其是当存储的是immutable data。当某个region 中 Hfile 被合并到region
: maxsize上限，会trigger region split。这之后原来的region中可能就不会再写入数
: 据，因为row key可能不会再映射到这个region.
: 如果schema设计成了每隔一段时间就在每一行都加一个新的column，那么已经存储的所
: 有Hfile都会被涉及到，做compaction的时候，这些文件都需要merge甚至trigger
|
J****R
发帖数: 373 | 18 那我就想问一句了，在compaction的时候，哪些SSTABLE不需要做compaction?
哪些SSTABLE又必须做compaction?
常见的case比如cell update, delete就不用提了。
【在 w**z 的大作中提到】
: C* is column family, adding new column doesn't mean schema change.
: Compaction happens when new data is written to the database and flushed to
: the disk as immutable File. So one row could live in different SSTable, in
: order to perform the reads more efficiently, compaction needs to be
: performed.
: It doesn't seem like you understand the fundamental of the column family
: based nosql database.
:
: compaction
: region
|
w**z
发帖数: 8232 | 19 The reason to have compaction is to reduce the number of disk seeks during
reads.
SStables are immutable, so one row could reside in multiple SStables
depending when it is written. For read, it has to merge the columns from all
the SSTable where that rowkey is found. Compaction merge the row in one
SSTable from all the SSTables compacted. But which tables are compacted
depends on the compaction strategy.
It's fine even there is no compaction at all, but the reads will become
slower and slower.
【在 J****R 的大作中提到】
: 那我就想问一句了，在compaction的时候，哪些SSTABLE不需要做compaction?
: 哪些SSTABLE又必须做compaction?
: 常见的case比如cell update, delete就不用提了。
|
