J****R
发帖数: 373 | 1 记得二爷推崇c*, 说过多次hbase已死。
最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
query限制非常多。
两个DB的performance 也区别不大。
有大牛能展开说说自己的看法吗？非常感谢！ |
p*****2
发帖数: 21240 | 2
performance差不少吧？我们这里用HB的都在往C＊上转。
【在 J****R 的大作中提到】
: 记得二爷推崇c*, 说过多次hbase已死。
: 最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
: query限制非常多。
: 两个DB的performance 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
|
J****R
发帖数: 373 | 3 你们那里的cluster是多大的？ 我build了6 nodes, 感觉区别不是很大。
【在 p*****2 的大作中提到】
:
: performance差不少吧？我们这里用HB的都在往C＊上转。
|
w***g
发帖数: 5958 | 4 请贴benchmark结果。感觉C*是强在scalability。机器多了以后HBase的
头节点会成为瓶颈，C*没这个问题。还有就是HBase中间夹了一层HDFS，
比如冗余机制就是靠HDFS实现的。比如C*要写两个copy，客户端直接
定位两台机器，写果去就完了。HBase要写两个copy，其实在到region
server之前都是1个copy，然后写入HDFS的时候才变成两个。中间多隔
一台机器，还会牵扯到Hadoop的namenode。
如果你的app就那么点数据，其实应该和MySQL比，应该比C*和Hbase都强。
【在 J****R 的大作中提到】
: 记得二爷推崇c*, 说过多次hbase已死。
: 最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
: query限制非常多。
: 两个DB的performance 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
|
p*****2
发帖数: 21240 | 5
我们没用HBase，这东西太难用了。
其他组用的，说是read上百ms了，C＊我们基本就是1ms
【在 J****R 的大作中提到】
: 你们那里的cluster是多大的？ 我build了6 nodes, 感觉区别不是很大。
|
f*******t
发帖数: 7549 | 6 Hbase主要问题是hdfs太屎
【在 w***g 的大作中提到】
: 请贴benchmark结果。感觉C*是强在scalability。机器多了以后HBase的
: 头节点会成为瓶颈，C*没这个问题。还有就是HBase中间夹了一层HDFS，
: 比如冗余机制就是靠HDFS实现的。比如C*要写两个copy，客户端直接
: 定位两台机器，写果去就完了。HBase要写两个copy，其实在到region
: server之前都是1个copy，然后写入HDFS的时候才变成两个。中间多隔
: 一台机器，还会牵扯到Hadoop的namenode。
: 如果你的app就那么点数据，其实应该和MySQL比，应该比C*和Hbase都强。
|
w***g
发帖数: 5958 | 7 hdfs本来备用做hadoop的存储层，用来做大块文件读写。
如果每次从hdfs读写几百兆的块，最近几个版本的Hadoop性能是没啥问题的。
（早期也很屎，后来改进了。）
在hdfs上做HBase本来就是一个很傻B的设计, 本来也不是用来做实时应用的。
后来用的人多了，用的范围大了，
engineering投入进去，性能补救了一点上去而已。但别人C*很自然就能做到
的性能，在HBase上就成了challenge。
【在 f*******t 的大作中提到】
: Hbase主要问题是hdfs太屎
|
z****e
发帖数: 54598 | 8 什么的benchmark？
六个nodes，如果数据量很小的话
强c和弱c是没有太大区别的
cassandra最好的一点就是不要求强c
而且可以tune，相比之下，hbase要做到这一点
就很苦逼 |
z****e
发帖数: 54598 | 9 脚本引擎肯定有各种限制
但是hbase连脚本引擎都不存在
你想想你自己实现一个hql会有多麻烦
cql虽然比不上sql，但是比起没有ql的hbase，那还是要强一点 |
c*******9
发帖数: 9032 | 10 hbase之上有些SQL中间层如Phoenix，不知道好不好用。
【在 z****e 的大作中提到】
: 脚本引擎肯定有各种限制
: 但是hbase连脚本引擎都不存在
: 你想想你自己实现一个hql会有多麻烦
: cql虽然比不上sql，但是比起没有ql的hbase，那还是要强一点
|
|
|
p*****2
发帖数: 21240 | 11
很难用。我们这里有人用fail了项目，走人了。
【在 c*******9 的大作中提到】
: hbase之上有些SQL中间层如Phoenix，不知道好不好用。
|
c*******9
发帖数: 9032 | 12 看到有C*整合Hadoop的。如果C*新项目，是不是不需要Hadoop？
【在 w***g 的大作中提到】
: hdfs本来备用做hadoop的存储层，用来做大块文件读写。
: 如果每次从hdfs读写几百兆的块，最近几个版本的Hadoop性能是没啥问题的。
: （早期也很屎，后来改进了。）
: 在hdfs上做HBase本来就是一个很傻B的设计, 本来也不是用来做实时应用的。
: 后来用的人多了，用的范围大了，
: engineering投入进去，性能补救了一点上去而已。但别人C*很自然就能做到
: 的性能，在HBase上就成了challenge。
|
z****e
发帖数: 54598 | 13
可以吧，hadoop那个年代，nosql不多，也没有其他东西可以用
所以主要是围绕hadoop在做东西，现在越来越多
还有spark什么也都开始支持hadoop了，就无所谓了
【在 c*******9 的大作中提到】
: 看到有C*整合Hadoop的。如果C*新项目，是不是不需要Hadoop？
|
c*******9
发帖数: 9032 | 14 如果运行在集群，一般项目，spark还是需要hadoop的文件系统吧？
如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
【在 z****e 的大作中提到】
:
: 可以吧，hadoop那个年代，nosql不多，也没有其他东西可以用
: 所以主要是围绕hadoop在做东西，现在越来越多
: 还有spark什么也都开始支持hadoop了，就无所谓了
|
z****e
发帖数: 54598 | 15
你说的是zookeeper吗？
如果你需要zookeeper的话，那就单独剥离出来用吧
hadoop主要是hdfs, hdmr, yarn这些，我觉得这几个好像没啥必要的
这几个我都不用，目前还没遇到啥问题
【在 c*******9 的大作中提到】
: 如果运行在集群，一般项目，spark还是需要hadoop的文件系统吧？
: 如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
|
w***g
发帖数: 5958 | 16 spark需要hadoop。楼上估计自己都没有装过spark机群。
【在 c*******9 的大作中提到】
: 如果运行在集群，一般项目，spark还是需要hadoop的文件系统吧？
: 如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
|
z****e
发帖数: 54598 | 17
p
虽然我很想骂你一顿，但是一想到重装就一堆破事
而且还是cluster mode
还是算了，回家要紧，你不信拉倒
【在 w***g 的大作中提到】
: spark需要hadoop。楼上估计自己都没有装过spark机群。
|
c*******9
发帖数: 9032 | 18 看文档有stand along，一直以为没什么用。
【在 w***g 的大作中提到】
: spark需要hadoop。楼上估计自己都没有装过spark机群。
|
w***g
发帖数: 5958 | 19 standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
..绕过HDFS读本地文件系统。
【在 c*******9 的大作中提到】
: 看文档有stand along，一直以为没什么用。
|
N*****m
发帖数: 42603 | 20 不用，比如可以用mesos
/.
【在 w***g 的大作中提到】
: standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
: HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
: ..绕过HDFS读本地文件系统。
|
|
|
c*******9
发帖数: 9032 | 21 用HDFS的好处是什么？
/.
【在 w***g 的大作中提到】
: standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
: HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
: ..绕过HDFS读本地文件系统。
|
c*******9
发帖数: 9032 | 22 用mesos的好处是什么？
【在 N*****m 的大作中提到】
: 不用，比如可以用mesos
:
: /.
|
N*****m
发帖数: 42603 | 23 方便，很多app都可以在上面跑
【在 c*******9 的大作中提到】
: 用mesos的好处是什么？
|
w***g
发帖数: 5958 | 24 确实是这样。spark程序可以用yarn或者mesos调度，也可以啥都不用裸跑。
spark本身是链接hadoop库的，但背后不一定需要读写dfs://...，可以读写
本地数据，C*或者s3啥的。但是高性能读写大量数据我觉得最好的还是dfs。
因为输入数据往往远大于输出数据，所以输入数据最好也存在dfs上。
最终计算的结果直接写入C*或者s3啥的，可以省掉来回倒腾。
我手里的生产系统用的是yarn调度，因为反正要用hadoop。不过机器比较少，
也没啥调度可言，基本上一个app跑上去内存就用满了，都是独占模式。
我没用hadoop/spark读过C*或者s3。我怀疑C*的读写性能会远差于HDFS。
希望用过的同学过来说说。（上面我有帖子说C*性能比HBase好，那个context
不一样，是说当数据库用的性能)
【在 N*****m 的大作中提到】
: 不用，比如可以用mesos
:
: /.
|
N*****m
发帖数: 42603 | 25 是的，主要还是看应用
比如，如果用spark stream，基本上没必要hdfs/hadoop
【在 w***g 的大作中提到】
: 确实是这样。spark程序可以用yarn或者mesos调度，也可以啥都不用裸跑。
: spark本身是链接hadoop库的，但背后不一定需要读写dfs://...，可以读写
: 本地数据，C*或者s3啥的。但是高性能读写大量数据我觉得最好的还是dfs。
: 因为输入数据往往远大于输出数据，所以输入数据最好也存在dfs上。
: 最终计算的结果直接写入C*或者s3啥的，可以省掉来回倒腾。
: 我手里的生产系统用的是yarn调度，因为反正要用hadoop。不过机器比较少，
: 也没啥调度可言，基本上一个app跑上去内存就用满了，都是独占模式。
: 我没用hadoop/spark读过C*或者s3。我怀疑C*的读写性能会远差于HDFS。
: 希望用过的同学过来说说。（上面我有帖子说C*性能比HBase好，那个context
: 不一样，是说当数据库用的性能)
|
w***g
发帖数: 5958 | 26 我直接忽略了spark stream。这个是我不对。
【在 N*****m 的大作中提到】
: 是的，主要还是看应用
: 比如，如果用spark stream，基本上没必要hdfs/hadoop
|
N*****m
发帖数: 42603 | 27 在本版，还是跟wdong讨论舒服
【在 w***g 的大作中提到】
: 我直接忽略了spark stream。这个是我不对。
|
p*****2
发帖数: 21240 | 28 hdfs有locality 性能是最好的
c需要加一个ring专门做分析 不然性能影响很大
【在 w***g 的大作中提到】
: 确实是这样。spark程序可以用yarn或者mesos调度，也可以啥都不用裸跑。
: spark本身是链接hadoop库的，但背后不一定需要读写dfs://...，可以读写
: 本地数据，C*或者s3啥的。但是高性能读写大量数据我觉得最好的还是dfs。
: 因为输入数据往往远大于输出数据，所以输入数据最好也存在dfs上。
: 最终计算的结果直接写入C*或者s3啥的，可以省掉来回倒腾。
: 我手里的生产系统用的是yarn调度，因为反正要用hadoop。不过机器比较少，
: 也没啥调度可言，基本上一个app跑上去内存就用满了，都是独占模式。
: 我没用hadoop/spark读过C*或者s3。我怀疑C*的读写性能会远差于HDFS。
: 希望用过的同学过来说说。（上面我有帖子说C*性能比HBase好，那个context
: 不一样，是说当数据库用的性能)
|
g*****g
发帖数: 34805 | 29 C* 读写快，scale容易，维护容易，多数据中心支持，适合 online. Hbase主要好处是
支持 range query, 跟 hadoop整合好。我们完全用 s3 替代 Hbase.
【在 w***g 的大作中提到】
: 请贴benchmark结果。感觉C*是强在scalability。机器多了以后HBase的
: 头节点会成为瓶颈，C*没这个问题。还有就是HBase中间夹了一层HDFS，
: 比如冗余机制就是靠HDFS实现的。比如C*要写两个copy，客户端直接
: 定位两台机器，写果去就完了。HBase要写两个copy，其实在到region
: server之前都是1个copy，然后写入HDFS的时候才变成两个。中间多隔
: 一台机器，还会牵扯到Hadoop的namenode。
: 如果你的app就那么点数据，其实应该和MySQL比，应该比C*和Hbase都强。
|
z****e
发帖数: 54598 | 30
“我没用hadoop/spark读过C*或者s3。”
所以说到底就是你根本没做过c*和spark的连接嘛
你没做过的东西干嘛急着否定？
每次都这样捣乱，很让人觉得讨厌诶
【在 w***g 的大作中提到】
: 确实是这样。spark程序可以用yarn或者mesos调度，也可以啥都不用裸跑。
: spark本身是链接hadoop库的，但背后不一定需要读写dfs://...，可以读写
: 本地数据，C*或者s3啥的。但是高性能读写大量数据我觉得最好的还是dfs。
: 因为输入数据往往远大于输出数据，所以输入数据最好也存在dfs上。
: 最终计算的结果直接写入C*或者s3啥的，可以省掉来回倒腾。
: 我手里的生产系统用的是yarn调度，因为反正要用hadoop。不过机器比较少，
: 也没啥调度可言，基本上一个app跑上去内存就用满了，都是独占模式。
: 我没用hadoop/spark读过C*或者s3。我怀疑C*的读写性能会远差于HDFS。
: 希望用过的同学过来说说。（上面我有帖子说C*性能比HBase好，那个context
: 不一样，是说当数据库用的性能)
|
|
|
z****e
发帖数: 54598 | 31
/.
standalone可以单独部署在集群上，并不是一个toy example用的
我倒是很奇怪，你们居然没有丢掉yarn这些东西
不过我是不用yarn，我觉得yarn太过于复杂了
大部分工作我用vert.x可以很快完成，直接操作c*，调度我自己写
yarn一堆api搞得跟ejb一样繁琐，什么container，context都来了
spark应该是直接替换yarn，这才是standalone模式的初衷
这个应该才是spark最初的目的才对，而不是run spark over yarn
这个感觉怪怪的，反正我不用yarn，不知道其他人怎样
对于spark的需求主要集中在mllib，其他的其实没啥，如果是streaming的话
用storm就好，不过我也不想这样换来换去，如果flink将来能解决这个问题的话
我就切换到flink上去，反正我现在也只用了mllib
剩下的crud，这个不用spark/flink这些，直接用c*的api就可以做很多了
cql连查询都帮你搞了不少，就更没有必要麻烦spark/flink了
【在 w***g 的大作中提到】
: standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
: HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
: ..绕过HDFS读本地文件系统。
|
z****e
发帖数: 54598 | 32 另外我写数据并不经过spark
直接vert.x->c*，spark主要负责读出数据做分析
如果单纯的crud，根本不过spark
包括查询，也不过spark，用cql
所以对于spark的需求仅仅限于ml部分
这样数据量大就不是完全spark的东西了
很大一部分分流给了vert.x去做，比如使用storm
就不需要介入spark的streaming
可能这也是为什么我可以放弃掉hadoop的原因
yarn更是早就放弃了 |
S*******e
发帖数: 525 | 33 不用yarn/mesos, how can you run two or more jobs at the same time?
我有一个项目用standalone （over hdfs)，我把20个“jobs" 放在一个进程，不是很
好，但勉强能工作。 我另外一个ETL项目， 有260 jobs，无法这么做。
【在 z****e 的大作中提到】
: 另外我写数据并不经过spark
: 直接vert.x->c*，spark主要负责读出数据做分析
: 如果单纯的crud，根本不过spark
: 包括查询，也不过spark，用cql
: 所以对于spark的需求仅仅限于ml部分
: 这样数据量大就不是完全spark的东西了
: 很大一部分分流给了vert.x去做，比如使用storm
: 就不需要介入spark的streaming
: 可能这也是为什么我可以放弃掉hadoop的原因
: yarn更是早就放弃了
|
z****e
发帖数: 54598 | 34
yarn主要是给hadoop/hdfs用的
c*我没用过yarn
对于c*来说，yarn不是必需的，甚至我觉得是多余的
etl这种多半是streaming的事
你可以通过storm什么来搞
而且java有的是处理并发的api啥的
你自己写一个也不难啊
job调度我通过vert.x来搞
多线程，异步什么能搞很多东西
【在 S*******e 的大作中提到】
: 不用yarn/mesos, how can you run two or more jobs at the same time?
: 我有一个项目用standalone （over hdfs)，我把20个“jobs" 放在一个进程，不是很
: 好，但勉强能工作。 我另外一个ETL项目， 有260 jobs，无法这么做。
|
p*****2
发帖数: 21240 | 35 查询不用spark会很蛋疼吧
cql查询能力还是很弱呀
【在 z****e 的大作中提到】
: 另外我写数据并不经过spark
: 直接vert.x->c*，spark主要负责读出数据做分析
: 如果单纯的crud，根本不过spark
: 包括查询，也不过spark，用cql
: 所以对于spark的需求仅仅限于ml部分
: 这样数据量大就不是完全spark的东西了
: 很大一部分分流给了vert.x去做，比如使用storm
: 就不需要介入spark的streaming
: 可能这也是为什么我可以放弃掉hadoop的原因
: yarn更是早就放弃了
|
J****R
发帖数: 373 | 36 二爷说的是对的，hdfs的确是一坨。
以前觉得hbase跟c*差不多，是因为忘了把hbase加到hdfs上，所以其实是在一个node上
跑的结果。加上hdfs以后，我靠，慢了20倍都不止。。。。。
6 nodes
hbase +hdfs
use java connector to batch load 1.4M lines of data into hbase, batch size
is 1000, takes about 36 minutes.....
it used to take much shorter time to load same size of data into one node
hbase based on local file system.
sth must be wrong.........
【在 w***g 的大作中提到】
: 请贴benchmark结果。感觉C*是强在scalability。机器多了以后HBase的
: 头节点会成为瓶颈，C*没这个问题。还有就是HBase中间夹了一层HDFS，
: 比如冗余机制就是靠HDFS实现的。比如C*要写两个copy，客户端直接
: 定位两台机器，写果去就完了。HBase要写两个copy，其实在到region
: server之前都是1个copy，然后写入HDFS的时候才变成两个。中间多隔
: 一台机器，还会牵扯到Hadoop的namenode。
: 如果你的app就那么点数据，其实应该和MySQL比，应该比C*和Hbase都强。
|
f*******t
发帖数: 7549 | 37 hdfs是pipeline写入模式，三个node接近串行，性能不如现在主流的quorum。
hbase基于hdfs虽然有hadoop生态圈的加成，但也严重影响了性能，最重要的是安装难
度提高太多，一般人不愿意弄 |
J****R
发帖数: 373 | 38 hdfs 就算串行也没理由那么慢. 2M 行左右数据，size 大概200M，写进hbase居然要半
个小时，这个有点不像话了，单node都不应该这么慢。
刚才试了一下直接把数据文件put到hdfs, 也不过用了110 seconds。
【在 f*******t 的大作中提到】
: hdfs是pipeline写入模式，三个node接近串行，性能不如现在主流的quorum。
: hbase基于hdfs虽然有hadoop生态圈的加成，但也严重影响了性能，最重要的是安装难
: 度提高太多，一般人不愿意弄
|
p*****u
发帖数: 310 | 39 Hbase太expensive。一份data要存6个copy |
f*******t
发帖数: 7549 | 40 不用啊，hdfs默认复制3份，replication factor甚至可以设成1
【在 p*****u 的大作中提到】
: Hbase太expensive。一份data要存6个copy
|
|
|
p*****u
发帖数: 310 | 41 replication factor 是整个cluster的，default 3 make sense。
【在 f*******t 的大作中提到】
: 不用啊，hdfs默认复制3份，replication factor甚至可以设成1
|
w**z
发帖数: 8232 | 42 C* 最大的好处是easy to scale. 有了vnode 加新node 太容易了。multi DC
replication 是自带的，很方便。 痛处是 repair.
【在 J****R 的大作中提到】
: 记得二爷推崇c*, 说过多次hbase已死。
: 最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
: query限制非常多。
: 两个DB的performance 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
|
p*****2
发帖数: 21240 | 43 到底一般什么时候需要repair呢
【在 w**z 的大作中提到】
: C* 最大的好处是easy to scale. 有了vnode 加新node 太容易了。multi DC
: replication 是自带的，很方便。 痛处是 repair.
|
z*******3
发帖数: 13709 | 44
肯定不可能像sql那样傻瓜容易
但是绕开spark的话，自己实现，很多东西更想得明白
c*也用了一段时间了，做起来也没有那么难了
加上spark sql也未必简单，整合起来很多时候是buff还是debuff不好说
【在 p*****2 的大作中提到】
: 查询不用spark会很蛋疼吧
: cql查询能力还是很弱呀
|
z*******3
发帖数: 13709 | 45
repair zkss？
replica设置为3+的话
应该还好吧，就是那个拜占庭将军问题
【在 w**z 的大作中提到】
: C* 最大的好处是easy to scale. 有了vnode 加新node 太容易了。multi DC
: replication 是自带的，很方便。 痛处是 repair.
|
w**z
发帖数: 8232 | 46 如果你有delete, 就会产生tombstone, 在grace period time 之内就必须repair, 否
则tombstone 会有可能重新回来。如果你没有delete, 而且read, write 都quorum, 理
论上就不需要repair.但一般为了保证data eventual consistent,都会repair. repair
时会消耗大量的 CPU memory disk 和 network bandwidth, 所以repair的时候server
最容易出事。
【在 p*****2 的大作中提到】
: 到底一般什么时候需要repair呢
|
p*****2
发帖数: 21240 | 47
repair
server
一般应该怎么schedule repair
【在 w**z 的大作中提到】
: 如果你有delete, 就会产生tombstone, 在grace period time 之内就必须repair, 否
: 则tombstone 会有可能重新回来。如果你没有delete, 而且read, write 都quorum, 理
: 论上就不需要repair.但一般为了保证data eventual consistent,都会repair. repair
: 时会消耗大量的 CPU memory disk 和 network bandwidth, 所以repair的时候server
: 最容易出事。
|
w**z
发帖数: 8232 | 48 cron job at low traffic time. at least once for all nodes within grace
period time which is 10 days by default.
【在 p*****2 的大作中提到】
:
: repair
: server
: 一般应该怎么schedule repair
|
d*******r
发帖数: 3299 | 49 cron job 是 Linux shell 那个吗?
C* 这些都上了, 估计是在用 Java 吧, 用 Java 的 schedule lib 搞比 cron job 好
吧.
【在 w**z 的大作中提到】
: cron job at low traffic time. at least once for all nodes within grace
: period time which is 10 days by default.
|
z*******3
发帖数: 13709 | 50 cron job在这里就是scheduler的同义词吧？
google cloud上也有cron job
不仅仅是linux shell上才有
包括yarn什么也都有
【在 d*******r 的大作中提到】
: cron job 是 Linux shell 那个吗?
: C* 这些都上了, 估计是在用 Java 吧, 用 Java 的 schedule lib 搞比 cron job 好
: 吧.
|
|
|
w**z
发帖数: 8232 | 51 C* repair is wrapped as a shell command. Cron job is the obvious choice to
schedule that.
【在 d*******r 的大作中提到】
: cron job 是 Linux shell 那个吗?
: C* 这些都上了, 估计是在用 Java 吧, 用 Java 的 schedule lib 搞比 cron job 好
: 吧.
|
