Hbase new column 存储问题# Programming - 葵花宝典
s*e
1 楼
论坛上置顶说现在北京上海不接受跨区签证了，可在大使馆网页上看到的就是可以跨区。
想让妈妈来美国看一下，supposed是在北京签。可是我想让她去上海或者广州签，可以
吗？
非常感谢！
想让妈妈来美国看一下，supposed是在北京签。可是我想让她去上海或者广州签，可以
吗？
非常感谢！
g*t
2 楼
讲的是一位双人舞女演员寻找男搭档，最后共同舞出人生的故事。Channing Tatum在影
片中的舞蹈技巧让人印象深刻。许多影迷希望如果重拍经典《dirty dance》，
Channing Tatum能担任已故的Patrick Swayze曾担任的角色。
http://www.imdb.com/title/tt0462590/
搜狐上有超清
http://tv.sohu.com/s2010/wcwrs/#super
还有一部2000年的同类型电影《center stage》讲的是一批纽约芭蕾舞学校学生通过如
何直面各自曲折的问题，以及艰苦的舞蹈训练，迈向舞蹈世界的故事。感人而且励志。
http://www.imdb.com/title/tt0210616/
其中的黑人女演员Zoe Saldana后来在《avatar》中一炮而红。
片中的舞蹈技巧让人印象深刻。许多影迷希望如果重拍经典《dirty dance》，
Channing Tatum能担任已故的Patrick Swayze曾担任的角色。
http://www.imdb.com/title/tt0462590/
搜狐上有超清
http://tv.sohu.com/s2010/wcwrs/#super
还有一部2000年的同类型电影《center stage》讲的是一批纽约芭蕾舞学校学生通过如
何直面各自曲折的问题，以及艰苦的舞蹈训练，迈向舞蹈世界的故事。感人而且励志。
http://www.imdb.com/title/tt0210616/
其中的黑人女演员Zoe Saldana后来在《avatar》中一炮而红。
J*R
3 楼
hbase里面不同时间加的new column cell是怎么存储的？
理论上cells in same row all stay together.各位高手有知道detail的吗？
理论上cells in same row all stay together.各位高手有知道detail的吗？
y*2
4 楼
好像北京上海不能跨区的。
为了保险起见，就在北京签吧。
为了保险起见，就在北京签吧。
p*m
5 楼
我很喜欢这部片子. 我以为他那个时候就已经成名了呢. 舞跳得好, 两主角非常有火花
. 现实生活中后来这男女主角结婚了.
. 现实生活中后来这男女主角结婚了.
w*z
6 楼
不是很确定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的吗？
应该是用 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的吗？
s*e
7 楼
谢谢！
【在 y******2 的大作中提到】
: 好像北京上海不能跨区的。
: 为了保险起见，就在北京签吧。
g*t
8 楼
他以前都演很小的角色。《step up》才真正让他独挑大梁。虽然是小制作，但是已经
锋芒毕露，聚集了不少人气，要红谁也拦不住。不像有些演员怎么捧都红不了。
锋芒毕露，聚集了不少人气，要红谁也拦不住。不像有些演员怎么捧都红不了。
J*R
9 楼
那么只要加新的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 的大作中提到】
: 不是很确定Hbase怎么做的，根据Google big table
: 应该是用 Memtable and LSM trees
: Cassandra 里叫SSTable， 用 compaction 把SSTable compact起来。没有compact的就
: 在query 的时候merge
: Hbase 应该同样的原理。
q*g
10 楼
北京和上海不接受跨区，也就是北京上海不接受其他区的申请人申请。
其他区接受跨区，但是必须这个区可以预约时间在所在区的预约时间之前。
其他区接受跨区，但是必须这个区可以预约时间在所在区的预约时间之前。
f*g
11 楼
很久以前就看过了，1 拍的最好，
step up 2 和 3 都挺烂的，主要是男主不行
【在 g****t 的大作中提到】
: 讲的是一位双人舞女演员寻找男搭档，最后共同舞出人生的故事。Channing Tatum在影
: 片中的舞蹈技巧让人印象深刻。许多影迷希望如果重拍经典《dirty dance》，
: Channing Tatum能担任已故的Patrick Swayze曾担任的角色。
: http://www.imdb.com/title/tt0462590/
: 搜狐上有超清
: http://tv.sohu.com/s2010/wcwrs/#super
: 还有一部2000年的同类型电影《center stage》讲的是一批纽约芭蕾舞学校学生通过如
: 何直面各自曲折的问题，以及艰苦的舞蹈训练，迈向舞蹈世界的故事。感人而且励志。
: http://www.imdb.com/title/tt0210616/
: 其中的黑人女演员Zoe Saldana后来在《avatar》中一炮而红。
step up 2 和 3 都挺烂的，主要是男主不行
【在 g****t 的大作中提到】
: 讲的是一位双人舞女演员寻找男搭档，最后共同舞出人生的故事。Channing Tatum在影
: 片中的舞蹈技巧让人印象深刻。许多影迷希望如果重拍经典《dirty dance》，
: Channing Tatum能担任已故的Patrick Swayze曾担任的角色。
: http://www.imdb.com/title/tt0462590/
: 搜狐上有超清
: http://tv.sohu.com/s2010/wcwrs/#super
: 还有一部2000年的同类型电影《center stage》讲的是一批纽约芭蕾舞学校学生通过如
: 何直面各自曲折的问题，以及艰苦的舞蹈训练，迈向舞蹈世界的故事。感人而且励志。
: http://www.imdb.com/title/tt0210616/
: 其中的黑人女演员Zoe Saldana后来在《avatar》中一炮而红。
w*z
12 楼
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岂不是没什么用。
: 。。。。
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岂不是没什么用。
: 。。。。
s*e
13 楼
感谢！明白了。
【在 q********g 的大作中提到】
: 北京和上海不接受跨区，也就是北京上海不接受其他区的申请人申请。
: 其他区接受跨区，但是必须这个区可以预约时间在所在区的预约时间之前。
f*t
14 楼
不同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不同，就
不会存在一起。
table / column family / hfile
不同column (qualifier)都是堆在一起的。
rowkey + column family + qualifier + timestamp才是真正的key，对应一个value。
“cell in same row”里的row如果指rowkey的话，只要cell的column family不同，就
不会存在一起。
J*R
15 楼
这个我倒是知道。只是当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不同，就
: 不会存在一起。
直没搞清楚。因为理论上同一个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
16 楼
每个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?
一个新的HFile里。每个HFile都是sorted，读的时候差不多是对每个HFile做binary
search。
因为每次flush都会产生一个新的HFile，文件越攒越多肯定不行，所以有算是offline
的compaction把几个文件合并成一个。
【在 J****R 的大作中提到】
: 这个我倒是知道。只是当put 一个新的column qualifier的时候存储结构是怎么回事一
: 直没搞清楚。因为理论上同一个row key的数据都是存储在一起的。如果在row1之后已
: 经写了row2的数据，那再增加一个row1的数据会怎么处理呢？难不成开始compaction?
J*R
17 楼
看样子compaction 的问题真的很麻烦。我原本想每个column是一个date,这样的话每增
加一天的data就得compact一次，看来似乎不是什么好主意。。。。。
offline
【在 f*******t 的大作中提到】
: 每个write先放进memory，隔一段时间或region占用内存过了一个threshold后flush到
: 一个新的HFile里。每个HFile都是sorted，读的时候差不多是对每个HFile做binary
: search。
: 因为每次flush都会产生一个新的HFile，文件越攒越多肯定不行，所以有算是offline
: 的compaction把几个文件合并成一个。
加一天的data就得compact一次，看来似乎不是什么好主意。。。。。
offline
【在 f*******t 的大作中提到】
: 每个write先放进memory，隔一段时间或region占用内存过了一个threshold后flush到
: 一个新的HFile里。每个HFile都是sorted，读的时候差不多是对每个HFile做binary
: search。
: 因为每次flush都会产生一个新的HFile，文件越攒越多肯定不行，所以有算是offline
: 的compaction把几个文件合并成一个。
w*z
18 楼
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
some time understanding it please. you need to get the basics.
【在 J****R 的大作中提到】
: 看样子compaction 的问题真的很麻烦。我原本想每个column是一个date,这样的话每增
: 加一天的data就得compact一次，看来似乎不是什么好主意。。。。。
:
: offline
J*R
19 楼
这个我倒是知道。问题是不同的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.
比如一个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
20 楼
HFile是immutable的。
compaction是把几个HFile合并写入一个临时文件，然后做一个文件系统的transaction
，分三步：
1.把原来的HFile删掉
2.把新的HFile放进column family的文件夹
3.在region里将旧的HFile信息删除，加进新的HFile。
我之前说过了，满足一定条件才会引起flush，加入新的column不会。另外region是按
row key的range分的，跟column没有任何关系。为什么怕region split？
compaction是把几个HFile合并写入一个临时文件，然后做一个文件系统的transaction
，分三步：
1.把原来的HFile删掉
2.把新的HFile放进column family的文件夹
3.在region里将旧的HFile信息删除，加进新的HFile。
我之前说过了，满足一定条件才会引起flush，加入新的column不会。另外region是按
row key的range分的，跟column没有任何关系。为什么怕region split？
w*z
21 楼
原理和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？
楼主要花点时间了解基础。费了半天口舌，他还是不明白。
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
22 楼
楼主的问题都比较无厘头，建议先读一下基础知识：http://hbase.apache.org/apache_hbase_reference_guide.pdf
J*R
23 楼
谢谢回复。可能是我没表述清楚。
假设某个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？
假设某个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
24 楼
只要持续写入，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
另外你多大数据量啊，还用担心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
25 楼
我也希望事情能简单一点，但是设计数据库的时候，有些底层的东西不得不考虑。之前
跟一些用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数据没问题，
: 你还担心啥
跟一些用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
26 楼
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
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
27 楼
那我就想问一句了，在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
哪些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
28 楼
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就不用提了。
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就不用提了。
相关阅读
Python越来越火爆啊video streaming library？业余时间想做一个project惊，朋友在digital ocean host的网站crash了。Java 的算法题：怎样把missing value替换成0 放在新生成的2D array里面？拉西债 verizon -> frontier (转载)是不是大部分的程序员都用Mac?关于搞ML刷数据的职业前途atom的windows安装文件要100MBalphoga, sorry mistake,基于纯暴力还是knowledge base有没有人觉得restful被高估了老邢的网站现在直接serve malware。还要脸不要？swift的科学计算librariesOne angry npm module took down the whole npmWebGL/ThreeJS可以在ASP.NET (C#)上运行吗？centos 7下自动安装各种CNN库生物千老能不能手写一个DNA函数出来? (转载)python questionsiOS app从国内存数据到美国的服务器chip信用卡为什么等那么久 (转载)