L*R
2 楼
现在准备签证，才知道政策变了，要先交签证费，因为我们那没有指定的中信，要坐火
车去省城或北京。想问一下，必须本人去吗？别人可以代交吗？需要带什么手续？中信
网站也没有说明，多谢了。
车去省城或北京。想问一下，必须本人去吗？别人可以代交吗？需要带什么手续？中信
网站也没有说明，多谢了。
d*r
3 楼
【 以下文字转载自 Chemistry 讨论区 】
发信人: dayandhour (sleepy), 信区: Chemistry
标 题: 中年职场危机,公司还是学校?
发信站: BBS 未名空间站 (Fri Dec 28 16:20:29 2012, 美东)
看的化学版上的"我这五年", 又看了下面这个连接, 感慨很多.
我来美10多年了, 亲身接触的, 听到的例子, 也有个不小的样本了.
这里只说老中, 牛的就不说了, 只说纠结的.
混公司的,80年代早期来美国的那批, 现在不少都快到退休的年纪了. 知道不少干到
Principle Scientist/Engineer然后被劝退, 然后很无奈的做part-time混退休的. 还
有些40多被裁的找到一个3流学校重新做assistant prof.
混学校做千老的,头发花百了还在和小本和博士生共用BENCH, 做实验, 但是都很坦然,
因为学校退休PENSION都还不错, 就等着老板的FUNDING每5年一续, 混到退休.
混学校做教授的,tenure后10年左右的, 做的东西老化了, 也拿不来钱了, associate
prof, even full professor变成lecturer,就靠上课. 这批人里面回国忽悠的也多, 正
好赶上国内科学大跃进.
联想到我们这一代, 10-20年后, 我们会走在哪条道路上, 又会有怎样的纠结???
发信人: mitbbs2013 (unknown), 信区: Chemistry
标 题: 震惊：写人名反应那书的Jie Jack Li也在找工作
发信站: BBS 未名空间站 (Fri Dec 28 10:03:47 2012, 美东)
http://www.linkedin.com/profile/view?id=10630172&ref=PYMK&authT
发信人: dayandhour (sleepy), 信区: Chemistry
标 题: 中年职场危机,公司还是学校?
发信站: BBS 未名空间站 (Fri Dec 28 16:20:29 2012, 美东)
看的化学版上的"我这五年", 又看了下面这个连接, 感慨很多.
我来美10多年了, 亲身接触的, 听到的例子, 也有个不小的样本了.
这里只说老中, 牛的就不说了, 只说纠结的.
混公司的,80年代早期来美国的那批, 现在不少都快到退休的年纪了. 知道不少干到
Principle Scientist/Engineer然后被劝退, 然后很无奈的做part-time混退休的. 还
有些40多被裁的找到一个3流学校重新做assistant prof.
混学校做千老的,头发花百了还在和小本和博士生共用BENCH, 做实验, 但是都很坦然,
因为学校退休PENSION都还不错, 就等着老板的FUNDING每5年一续, 混到退休.
混学校做教授的,tenure后10年左右的, 做的东西老化了, 也拿不来钱了, associate
prof, even full professor变成lecturer,就靠上课. 这批人里面回国忽悠的也多, 正
好赶上国内科学大跃进.
联想到我们这一代, 10-20年后, 我们会走在哪条道路上, 又会有怎样的纠结???
发信人: mitbbs2013 (unknown), 信区: Chemistry
标 题: 震惊：写人名反应那书的Jie Jack Li也在找工作
发信站: BBS 未名空间站 (Fri Dec 28 10:03:47 2012, 美东)
http://www.linkedin.com/profile/view?id=10630172&ref=PYMK&authT
H*1
4 楼
前几天root完后，youtube挺好的。这几天不工作了，一点就有回到了extras的界面。
我就把它用nook color tools里面的 manage applications 把它给删除了。
我还想看youtube，请大侠支招！ 多谢
我就把它用nook color tools里面的 manage applications 把它给删除了。
我还想看youtube，请大侠支招！ 多谢
J*R
5 楼
记得二爷推崇c*, 说过多次hbase已死。
最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
query限制非常多。
两个DB的performance 也区别不大。
有大牛能展开说说自己的看法吗？非常感谢！
最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
query限制非常多。
两个DB的performance 也区别不大。
有大牛能展开说说自己的看法吗？非常感谢！
a*n
6 楼
每个中信规定不一样，最好找人先去问问
【在 L***R 的大作中提到】
: 现在准备签证，才知道政策变了，要先交签证费，因为我们那没有指定的中信，要坐火
: 车去省城或北京。想问一下，必须本人去吗？别人可以代交吗？需要带什么手续？中信
: 网站也没有说明，多谢了。
【在 L***R 的大作中提到】
: 现在准备签证，才知道政策变了，要先交签证费，因为我们那没有指定的中信，要坐火
: 车去省城或北京。想问一下，必须本人去吗？别人可以代交吗？需要带什么手续？中信
: 网站也没有说明，多谢了。
B*2
7 楼
还是做tenure教授的靠谱
g*g
8 楼
找个youtube的apk,再装一下就好了
pandarus的那个包里就有个好用的
【在 H*********1 的大作中提到】
: 前几天root完后，youtube挺好的。这几天不工作了，一点就有回到了extras的界面。
: 我就把它用nook color tools里面的 manage applications 把它给删除了。
: 我还想看youtube，请大侠支招！ 多谢
pandarus的那个包里就有个好用的
【在 H*********1 的大作中提到】
: 前几天root完后，youtube挺好的。这几天不工作了，一点就有回到了extras的界面。
: 我就把它用nook color tools里面的 manage applications 把它给删除了。
: 我还想看youtube，请大侠支招！ 多谢
p*2
9 楼
performance差不少吧？我们这里用HB的都在往C＊上转。
【在 J****R 的大作中提到】
: 记得二爷推崇c*, 说过多次hbase已死。
: 最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
: query限制非常多。
: 两个DB的performance 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
t*s
10 楼
看探亲与陪读版置顶的常见问题
http://www.mitbbs.com/article_t2/Reunion/31319663.html
http://www.mitbbs.com/article_t2/Reunion/31319663.html
b*c
11 楼
难道随便选？嗯，随便选的话，50以前在公司挣钱，50以后去学校养老...可惜我估计
人学校不收我这样的。
【在 d********r 的大作中提到】
: 【 以下文字转载自 Chemistry 讨论区 】
: 发信人: dayandhour (sleepy), 信区: Chemistry
: 标 题: 中年职场危机,公司还是学校?
: 发信站: BBS 未名空间站 (Fri Dec 28 16:20:29 2012, 美东)
: 看的化学版上的"我这五年", 又看了下面这个连接, 感慨很多.
: 我来美10多年了, 亲身接触的, 听到的例子, 也有个不小的样本了.
: 这里只说老中, 牛的就不说了, 只说纠结的.
: 混公司的,80年代早期来美国的那批, 现在不少都快到退休的年纪了. 知道不少干到
: Principle Scientist/Engineer然后被劝退, 然后很无奈的做part-time混退休的. 还
: 有些40多被裁的找到一个3流学校重新做assistant prof.
人学校不收我这样的。
【在 d********r 的大作中提到】
: 【 以下文字转载自 Chemistry 讨论区 】
: 发信人: dayandhour (sleepy), 信区: Chemistry
: 标 题: 中年职场危机,公司还是学校?
: 发信站: BBS 未名空间站 (Fri Dec 28 16:20:29 2012, 美东)
: 看的化学版上的"我这五年", 又看了下面这个连接, 感慨很多.
: 我来美10多年了, 亲身接触的, 听到的例子, 也有个不小的样本了.
: 这里只说老中, 牛的就不说了, 只说纠结的.
: 混公司的,80年代早期来美国的那批, 现在不少都快到退休的年纪了. 知道不少干到
: Principle Scientist/Engineer然后被劝退, 然后很无奈的做part-time混退休的. 还
: 有些40多被裁的找到一个3流学校重新做assistant prof.
M*t
12 楼
再装回去呗，多大点儿事啊？呵呵。
看置顶的文章。那个小技巧里面。那个版本比较好。
【在 H*********1 的大作中提到】
: 前几天root完后，youtube挺好的。这几天不工作了，一点就有回到了extras的界面。
: 我就把它用nook color tools里面的 manage applications 把它给删除了。
: 我还想看youtube，请大侠支招！ 多谢
看置顶的文章。那个小技巧里面。那个版本比较好。
【在 H*********1 的大作中提到】
: 前几天root完后，youtube挺好的。这几天不工作了，一点就有回到了extras的界面。
: 我就把它用nook color tools里面的 manage applications 把它给删除了。
: 我还想看youtube，请大侠支招！ 多谢
J*R
13 楼
你们那里的cluster是多大的？ 我build了6 nodes, 感觉区别不是很大。
【在 p*****2 的大作中提到】
:
: performance差不少吧？我们这里用HB的都在往C＊上转。
【在 p*****2 的大作中提到】
:
: performance差不少吧？我们这里用HB的都在往C＊上转。
p*s
14 楼
用安装输入法同样的办法
【在 H*********1 的大作中提到】
: 前几天root完后，youtube挺好的。这几天不工作了，一点就有回到了extras的界面。
: 我就把它用nook color tools里面的 manage applications 把它给删除了。
: 我还想看youtube，请大侠支招！ 多谢
【在 H*********1 的大作中提到】
: 前几天root完后，youtube挺好的。这几天不工作了，一点就有回到了extras的界面。
: 我就把它用nook color tools里面的 manage applications 把它给删除了。
: 我还想看youtube，请大侠支招！ 多谢
w*g
15 楼
请贴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 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
头节点会成为瓶颈，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 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
G2
16 楼
pandarus一定很郁闷，nc确实是个好东西，普及这玩意儿本版包括国内坛子你功不可没
但是别人不肯好好读文章，懒得动手，连几行代码都不想输，什么都搞不定
回头还抱怨。哎~~~
我当时还攒了n多页的各种walkaround和tweaks，后来想想，算了，我费劲写这个干吗啊
我又不是bn的shareholder，卖多了跟我有半毛钱关系吗？何必呢
【在 p******s 的大作中提到】
: 用安装输入法同样的办法
但是别人不肯好好读文章，懒得动手，连几行代码都不想输，什么都搞不定
回头还抱怨。哎~~~
我当时还攒了n多页的各种walkaround和tweaks，后来想想，算了，我费劲写这个干吗啊
我又不是bn的shareholder，卖多了跟我有半毛钱关系吗？何必呢
【在 p******s 的大作中提到】
: 用安装输入法同样的办法
p*2
17 楼
我们没用HBase，这东西太难用了。
其他组用的，说是read上百ms了，C＊我们基本就是1ms
【在 J****R 的大作中提到】
: 你们那里的cluster是多大的？ 我build了6 nodes, 感觉区别不是很大。
p*s
18 楼
让你猜着了 是挺郁闷的 很多东西其实都写在那了 动手搜一下就行 而且一般也附上
xda原帖 要觉得写得不清楚 也可以看原帖去
刚折腾的时候 都要靠自己来搞adb 现在好了 root explorer很多都能干
某些脚本什么的 用gscript也能运行
吗啊
【在 G2 的大作中提到】
: pandarus一定很郁闷，nc确实是个好东西，普及这玩意儿本版包括国内坛子你功不可没
: 但是别人不肯好好读文章，懒得动手，连几行代码都不想输，什么都搞不定
: 回头还抱怨。哎~~~
: 我当时还攒了n多页的各种walkaround和tweaks，后来想想，算了，我费劲写这个干吗啊
: 我又不是bn的shareholder，卖多了跟我有半毛钱关系吗？何必呢
xda原帖 要觉得写得不清楚 也可以看原帖去
刚折腾的时候 都要靠自己来搞adb 现在好了 root explorer很多都能干
某些脚本什么的 用gscript也能运行
吗啊
【在 G2 的大作中提到】
: pandarus一定很郁闷，nc确实是个好东西，普及这玩意儿本版包括国内坛子你功不可没
: 但是别人不肯好好读文章，懒得动手，连几行代码都不想输，什么都搞不定
: 回头还抱怨。哎~~~
: 我当时还攒了n多页的各种walkaround和tweaks，后来想想，算了，我费劲写这个干吗啊
: 我又不是bn的shareholder，卖多了跟我有半毛钱关系吗？何必呢
f*t
19 楼
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 的大作中提到】
: 请贴benchmark结果。感觉C*是强在scalability。机器多了以后HBase的
: 头节点会成为瓶颈，C*没这个问题。还有就是HBase中间夹了一层HDFS，
: 比如冗余机制就是靠HDFS实现的。比如C*要写两个copy，客户端直接
: 定位两台机器，写果去就完了。HBase要写两个copy，其实在到region
: server之前都是1个copy，然后写入HDFS的时候才变成两个。中间多隔
: 一台机器，还会牵扯到Hadoop的namenode。
: 如果你的app就那么点数据，其实应该和MySQL比，应该比C*和Hbase都强。
G2
20 楼
我是anoia的mj，哼哼
千万千万别让这些连代码都不想打的人装gscript，不小心再出个篓子，按错个键，直接
系统弄残了。。。
【在 p******s 的大作中提到】
: 让你猜着了 是挺郁闷的 很多东西其实都写在那了 动手搜一下就行 而且一般也附上
: xda原帖 要觉得写得不清楚 也可以看原帖去
: 刚折腾的时候 都要靠自己来搞adb 现在好了 root explorer很多都能干
: 某些脚本什么的 用gscript也能运行
:
: 吗啊
千万千万别让这些连代码都不想打的人装gscript，不小心再出个篓子，按错个键，直接
系统弄残了。。。
【在 p******s 的大作中提到】
: 让你猜着了 是挺郁闷的 很多东西其实都写在那了 动手搜一下就行 而且一般也附上
: xda原帖 要觉得写得不清楚 也可以看原帖去
: 刚折腾的时候 都要靠自己来搞adb 现在好了 root explorer很多都能干
: 某些脚本什么的 用gscript也能运行
:
: 吗啊
w*g
21 楼
hdfs本来备用做hadoop的存储层，用来做大块文件读写。
如果每次从hdfs读写几百兆的块，最近几个版本的Hadoop性能是没啥问题的。
（早期也很屎，后来改进了。）
在hdfs上做HBase本来就是一个很傻B的设计, 本来也不是用来做实时应用的。
后来用的人多了，用的范围大了，
engineering投入进去，性能补救了一点上去而已。但别人C*很自然就能做到
的性能，在HBase上就成了challenge。
【在 f*******t 的大作中提到】
: Hbase主要问题是hdfs太屎
如果每次从hdfs读写几百兆的块，最近几个版本的Hadoop性能是没啥问题的。
（早期也很屎，后来改进了。）
在hdfs上做HBase本来就是一个很傻B的设计, 本来也不是用来做实时应用的。
后来用的人多了，用的范围大了，
engineering投入进去，性能补救了一点上去而已。但别人C*很自然就能做到
的性能，在HBase上就成了challenge。
【在 f*******t 的大作中提到】
: Hbase主要问题是hdfs太屎
p*s
22 楼
呵呵 gscript 有个选项 可以重刷rom 本来是很方便的功能 但有人不小心点了 然后就
骂gscript
直接
【在 G2 的大作中提到】
: 我是anoia的mj，哼哼
: 千万千万别让这些连代码都不想打的人装gscript，不小心再出个篓子，按错个键，直接
: 系统弄残了。。。
骂gscript
直接
【在 G2 的大作中提到】
: 我是anoia的mj，哼哼
: 千万千万别让这些连代码都不想打的人装gscript，不小心再出个篓子，按错个键，直接
: 系统弄残了。。。
z*e
23 楼
什么的benchmark？
六个nodes，如果数据量很小的话
强c和弱c是没有太大区别的
cassandra最好的一点就是不要求强c
而且可以tune，相比之下，hbase要做到这一点
就很苦逼
六个nodes，如果数据量很小的话
强c和弱c是没有太大区别的
cassandra最好的一点就是不要求强c
而且可以tune，相比之下，hbase要做到这一点
就很苦逼
M*t
24 楼
我还是喜欢ADB，快。
可没
【在 p******s 的大作中提到】
: 让你猜着了 是挺郁闷的 很多东西其实都写在那了 动手搜一下就行 而且一般也附上
: xda原帖 要觉得写得不清楚 也可以看原帖去
: 刚折腾的时候 都要靠自己来搞adb 现在好了 root explorer很多都能干
: 某些脚本什么的 用gscript也能运行
:
: 吗啊
可没
【在 p******s 的大作中提到】
: 让你猜着了 是挺郁闷的 很多东西其实都写在那了 动手搜一下就行 而且一般也附上
: xda原帖 要觉得写得不清楚 也可以看原帖去
: 刚折腾的时候 都要靠自己来搞adb 现在好了 root explorer很多都能干
: 某些脚本什么的 用gscript也能运行
:
: 吗啊
z*e
25 楼
脚本引擎肯定有各种限制
但是hbase连脚本引擎都不存在
你想想你自己实现一个hql会有多麻烦
cql虽然比不上sql，但是比起没有ql的hbase，那还是要强一点
但是hbase连脚本引擎都不存在
你想想你自己实现一个hql会有多麻烦
cql虽然比不上sql，但是比起没有ql的hbase，那还是要强一点
b*e
26 楼
Help, The link to download does not work. Got Error (403)
c*9
27 楼
hbase之上有些SQL中间层如Phoenix，不知道好不好用。
【在 z****e 的大作中提到】
: 脚本引擎肯定有各种限制
: 但是hbase连脚本引擎都不存在
: 你想想你自己实现一个hql会有多麻烦
: cql虽然比不上sql，但是比起没有ql的hbase，那还是要强一点
【在 z****e 的大作中提到】
: 脚本引擎肯定有各种限制
: 但是hbase连脚本引擎都不存在
: 你想想你自己实现一个hql会有多麻烦
: cql虽然比不上sql，但是比起没有ql的hbase，那还是要强一点
a*a
28 楼
你试试这个，我desktop上翻出来的，不太确定是否是我正在用的
如果不行再告诉我，我有空从我nook上给你刨出来
http://dl.dropbox.com/u/13502456/com.google.android.youtube.apk
【在 b******e 的大作中提到】
: Help, The link to download does not work. Got Error (403)
如果不行再告诉我，我有空从我nook上给你刨出来
http://dl.dropbox.com/u/13502456/com.google.android.youtube.apk
【在 b******e 的大作中提到】
: Help, The link to download does not work. Got Error (403)
p*2
29 楼
很难用。我们这里有人用fail了项目，走人了。
【在 c*******9 的大作中提到】
: hbase之上有些SQL中间层如Phoenix，不知道好不好用。
b*e
30 楼
多谢，可用！
【在 a***a 的大作中提到】
: 你试试这个，我desktop上翻出来的，不太确定是否是我正在用的
: 如果不行再告诉我，我有空从我nook上给你刨出来
: http://dl.dropbox.com/u/13502456/com.google.android.youtube.apk
【在 a***a 的大作中提到】
: 你试试这个，我desktop上翻出来的，不太确定是否是我正在用的
: 如果不行再告诉我，我有空从我nook上给你刨出来
: http://dl.dropbox.com/u/13502456/com.google.android.youtube.apk
c*9
31 楼
看到有C*整合Hadoop的。如果C*新项目，是不是不需要Hadoop？
【在 w***g 的大作中提到】
: hdfs本来备用做hadoop的存储层，用来做大块文件读写。
: 如果每次从hdfs读写几百兆的块，最近几个版本的Hadoop性能是没啥问题的。
: （早期也很屎，后来改进了。）
: 在hdfs上做HBase本来就是一个很傻B的设计, 本来也不是用来做实时应用的。
: 后来用的人多了，用的范围大了，
: engineering投入进去，性能补救了一点上去而已。但别人C*很自然就能做到
: 的性能，在HBase上就成了challenge。
【在 w***g 的大作中提到】
: hdfs本来备用做hadoop的存储层，用来做大块文件读写。
: 如果每次从hdfs读写几百兆的块，最近几个版本的Hadoop性能是没啥问题的。
: （早期也很屎，后来改进了。）
: 在hdfs上做HBase本来就是一个很傻B的设计, 本来也不是用来做实时应用的。
: 后来用的人多了，用的范围大了，
: engineering投入进去，性能补救了一点上去而已。但别人C*很自然就能做到
: 的性能，在HBase上就成了challenge。
a*a
32 楼
这个桌面图标有HD标志吗，帮我确认一下，多谢
【在 b******e 的大作中提到】
: 多谢，可用！
【在 b******e 的大作中提到】
: 多谢，可用！
z*e
33 楼
可以吧，hadoop那个年代，nosql不多，也没有其他东西可以用
所以主要是围绕hadoop在做东西，现在越来越多
还有spark什么也都开始支持hadoop了，就无所谓了
【在 c*******9 的大作中提到】
: 看到有C*整合Hadoop的。如果C*新项目，是不是不需要Hadoop？
c*9
34 楼
如果运行在集群，一般项目，spark还是需要hadoop的文件系统吧？
如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
【在 z****e 的大作中提到】
:
: 可以吧，hadoop那个年代，nosql不多，也没有其他东西可以用
: 所以主要是围绕hadoop在做东西，现在越来越多
: 还有spark什么也都开始支持hadoop了，就无所谓了
如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
【在 z****e 的大作中提到】
:
: 可以吧，hadoop那个年代，nosql不多，也没有其他东西可以用
: 所以主要是围绕hadoop在做东西，现在越来越多
: 还有spark什么也都开始支持hadoop了，就无所谓了
z*e
35 楼
你说的是zookeeper吗？
如果你需要zookeeper的话，那就单独剥离出来用吧
hadoop主要是hdfs, hdmr, yarn这些，我觉得这几个好像没啥必要的
这几个我都不用，目前还没遇到啥问题
【在 c*******9 的大作中提到】
: 如果运行在集群，一般项目，spark还是需要hadoop的文件系统吧？
: 如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
w*g
36 楼
spark需要hadoop。楼上估计自己都没有装过spark机群。
【在 c*******9 的大作中提到】
: 如果运行在集群，一般项目，spark还是需要hadoop的文件系统吧？
: 如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
【在 c*******9 的大作中提到】
: 如果运行在集群，一般项目，spark还是需要hadoop的文件系统吧？
: 如果是spark＋C*的项目，C*有自己的集群管理， hadoop还有用吗？
z*e
37 楼
p
虽然我很想骂你一顿，但是一想到重装就一堆破事
而且还是cluster mode
还是算了，回家要紧，你不信拉倒
【在 w***g 的大作中提到】
: spark需要hadoop。楼上估计自己都没有装过spark机群。
c*9
38 楼
看文档有stand along，一直以为没什么用。
【在 w***g 的大作中提到】
: spark需要hadoop。楼上估计自己都没有装过spark机群。
【在 w***g 的大作中提到】
: spark需要hadoop。楼上估计自己都没有装过spark机群。
w*g
39 楼
standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
..绕过HDFS读本地文件系统。
【在 c*******9 的大作中提到】
: 看文档有stand along，一直以为没什么用。
HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
..绕过HDFS读本地文件系统。
【在 c*******9 的大作中提到】
: 看文档有stand along，一直以为没什么用。
N*m
40 楼
不用，比如可以用mesos
/.
【在 w***g 的大作中提到】
: standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
: HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
: ..绕过HDFS读本地文件系统。
/.
【在 w***g 的大作中提到】
: standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
: HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
: ..绕过HDFS读本地文件系统。
c*9
41 楼
用HDFS的好处是什么？
/.
【在 w***g 的大作中提到】
: standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
: HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
: ..绕过HDFS读本地文件系统。
/.
【在 w***g 的大作中提到】
: standalone是用来在笔记本上跑toy example用的。正经机群上大规模数据还是得走
: HDFS。Hadoop也有不用HDFS的standalone模式。就是上了机群，还是可以指定file://.
: ..绕过HDFS读本地文件系统。
c*9
42 楼
用mesos的好处是什么？
【在 N*****m 的大作中提到】
: 不用，比如可以用mesos
:
: /.
【在 N*****m 的大作中提到】
: 不用，比如可以用mesos
:
: /.
N*m
43 楼
方便，很多app都可以在上面跑
【在 c*******9 的大作中提到】
: 用mesos的好处是什么？
【在 c*******9 的大作中提到】
: 用mesos的好处是什么？
w*g
44 楼
确实是这样。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
:
: /.
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
45 楼
是的，主要还是看应用
比如，如果用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
: 不一样，是说当数据库用的性能)
比如，如果用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
46 楼
我直接忽略了spark stream。这个是我不对。
【在 N*****m 的大作中提到】
: 是的，主要还是看应用
: 比如，如果用spark stream，基本上没必要hdfs/hadoop
【在 N*****m 的大作中提到】
: 是的，主要还是看应用
: 比如，如果用spark stream，基本上没必要hdfs/hadoop
N*m
47 楼
在本版，还是跟wdong讨论舒服
【在 w***g 的大作中提到】
: 我直接忽略了spark stream。这个是我不对。
【在 w***g 的大作中提到】
: 我直接忽略了spark stream。这个是我不对。
p*2
48 楼
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
: 不一样，是说当数据库用的性能)
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
49 楼
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都强。
支持 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
50 楼
“我没用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
51 楼
/.
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
52 楼
另外我写数据并不经过spark
直接vert.x->c*，spark主要负责读出数据做分析
如果单纯的crud，根本不过spark
包括查询，也不过spark，用cql
所以对于spark的需求仅仅限于ml部分
这样数据量大就不是完全spark的东西了
很大一部分分流给了vert.x去做，比如使用storm
就不需要介入spark的streaming
可能这也是为什么我可以放弃掉hadoop的原因
yarn更是早就放弃了
直接vert.x->c*，spark主要负责读出数据做分析
如果单纯的crud，根本不过spark
包括查询，也不过spark，用cql
所以对于spark的需求仅仅限于ml部分
这样数据量大就不是完全spark的东西了
很大一部分分流给了vert.x去做，比如使用storm
就不需要介入spark的streaming
可能这也是为什么我可以放弃掉hadoop的原因
yarn更是早就放弃了
S*e
53 楼
不用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更是早就放弃了
我有一个项目用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
54 楼
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
55 楼
查询不用spark会很蛋疼吧
cql查询能力还是很弱呀
【在 z****e 的大作中提到】
: 另外我写数据并不经过spark
: 直接vert.x->c*，spark主要负责读出数据做分析
: 如果单纯的crud，根本不过spark
: 包括查询，也不过spark，用cql
: 所以对于spark的需求仅仅限于ml部分
: 这样数据量大就不是完全spark的东西了
: 很大一部分分流给了vert.x去做，比如使用storm
: 就不需要介入spark的streaming
: 可能这也是为什么我可以放弃掉hadoop的原因
: yarn更是早就放弃了
cql查询能力还是很弱呀
【在 z****e 的大作中提到】
: 另外我写数据并不经过spark
: 直接vert.x->c*，spark主要负责读出数据做分析
: 如果单纯的crud，根本不过spark
: 包括查询，也不过spark，用cql
: 所以对于spark的需求仅仅限于ml部分
: 这样数据量大就不是完全spark的东西了
: 很大一部分分流给了vert.x去做，比如使用storm
: 就不需要介入spark的streaming
: 可能这也是为什么我可以放弃掉hadoop的原因
: yarn更是早就放弃了
J*R
56 楼
二爷说的是对的，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都强。
以前觉得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
57 楼
hdfs是pipeline写入模式，三个node接近串行，性能不如现在主流的quorum。
hbase基于hdfs虽然有hadoop生态圈的加成，但也严重影响了性能，最重要的是安装难
度提高太多，一般人不愿意弄
hbase基于hdfs虽然有hadoop生态圈的加成，但也严重影响了性能，最重要的是安装难
度提高太多，一般人不愿意弄
J*R
58 楼
hdfs 就算串行也没理由那么慢. 2M 行左右数据，size 大概200M，写进hbase居然要半
个小时，这个有点不像话了，单node都不应该这么慢。
刚才试了一下直接把数据文件put到hdfs, 也不过用了110 seconds。
【在 f*******t 的大作中提到】
: hdfs是pipeline写入模式，三个node接近串行，性能不如现在主流的quorum。
: hbase基于hdfs虽然有hadoop生态圈的加成，但也严重影响了性能，最重要的是安装难
: 度提高太多，一般人不愿意弄
个小时，这个有点不像话了，单node都不应该这么慢。
刚才试了一下直接把数据文件put到hdfs, 也不过用了110 seconds。
【在 f*******t 的大作中提到】
: hdfs是pipeline写入模式，三个node接近串行，性能不如现在主流的quorum。
: hbase基于hdfs虽然有hadoop生态圈的加成，但也严重影响了性能，最重要的是安装难
: 度提高太多，一般人不愿意弄
p*u
59 楼
Hbase太expensive。一份data要存6个copy
f*t
60 楼
不用啊，hdfs默认复制3份，replication factor甚至可以设成1
【在 p*****u 的大作中提到】
: Hbase太expensive。一份data要存6个copy
【在 p*****u 的大作中提到】
: Hbase太expensive。一份data要存6个copy
p*u
61 楼
replication factor 是整个cluster的，default 3 make sense。
【在 f*******t 的大作中提到】
: 不用啊，hdfs默认复制3份，replication factor甚至可以设成1
【在 f*******t 的大作中提到】
: 不用啊，hdfs默认复制3份，replication factor甚至可以设成1
w*z
62 楼
C* 最大的好处是easy to scale. 有了vnode 加新node 太容易了。multi DC
replication 是自带的，很方便。 痛处是 repair.
【在 J****R 的大作中提到】
: 记得二爷推崇c*, 说过多次hbase已死。
: 最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
: query限制非常多。
: 两个DB的performance 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
replication 是自带的，很方便。 痛处是 repair.
【在 J****R 的大作中提到】
: 记得二爷推崇c*, 说过多次hbase已死。
: 最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
: query限制非常多。
: 两个DB的performance 也区别不大。
: 有大牛能展开说说自己的看法吗？非常感谢！
p*2
63 楼
到底一般什么时候需要repair呢
【在 w**z 的大作中提到】
: C* 最大的好处是easy to scale. 有了vnode 加新node 太容易了。multi DC
: replication 是自带的，很方便。 痛处是 repair.
【在 w**z 的大作中提到】
: C* 最大的好处是easy to scale. 有了vnode 加新node 太容易了。multi DC
: replication 是自带的，很方便。 痛处是 repair.
z*3
64 楼
肯定不可能像sql那样傻瓜容易
但是绕开spark的话，自己实现，很多东西更想得明白
c*也用了一段时间了，做起来也没有那么难了
加上spark sql也未必简单，整合起来很多时候是buff还是debuff不好说
【在 p*****2 的大作中提到】
: 查询不用spark会很蛋疼吧
: cql查询能力还是很弱呀
z*3
65 楼
repair zkss？
replica设置为3+的话
应该还好吧，就是那个拜占庭将军问题
【在 w**z 的大作中提到】
: C* 最大的好处是easy to scale. 有了vnode 加新node 太容易了。multi DC
: replication 是自带的，很方便。 痛处是 repair.
w*z
66 楼
如果你有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呢
则tombstone 会有可能重新回来。如果你没有delete, 而且read, write 都quorum, 理
论上就不需要repair.但一般为了保证data eventual consistent,都会repair. repair
时会消耗大量的 CPU memory disk 和 network bandwidth, 所以repair的时候server
最容易出事。
【在 p*****2 的大作中提到】
: 到底一般什么时候需要repair呢
p*2
67 楼
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
68 楼
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
period time which is 10 days by default.
【在 p*****2 的大作中提到】
:
: repair
: server
: 一般应该怎么schedule repair
d*r
69 楼
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.
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
70 楼
cron job在这里就是scheduler的同义词吧？
google cloud上也有cron job
不仅仅是linux shell上才有
包括yarn什么也都有
【在 d*******r 的大作中提到】
: cron job 是 Linux shell 那个吗?
: C* 这些都上了, 估计是在用 Java 吧, 用 Java 的 schedule lib 搞比 cron job 好
: 吧.
google cloud上也有cron job
不仅仅是linux shell上才有
包括yarn什么也都有
【在 d*******r 的大作中提到】
: cron job 是 Linux shell 那个吗?
: C* 这些都上了, 估计是在用 Java 吧, 用 Java 的 schedule lib 搞比 cron job 好
: 吧.
w*z
71 楼
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 好
: 吧.
schedule that.
【在 d*******r 的大作中提到】
: cron job 是 Linux shell 那个吗?
: C* 这些都上了, 估计是在用 Java 吧, 用 Java 的 schedule lib 搞比 cron job 好
: 吧.
相关阅读
大家用过NIF吗？大家都用go写什么projects?内推 job referral web site，请使用 http://aireferral.com/ (转载)C++11痛并快乐着Node.js question: webpage always defaults to index.htmlATOM果然是现在除了vi最好的editor.大赞，可以算是light ide. full fledged editorangular2里面怎么import第三方包？老魏，我觉得你要做就全套一起做需要写个浏览器自用，什么内核比较好?Re: 【讨论】作为即将决定去FLGT的小博，谈谈我的看法 (转载)赵策怎么看OOP hell的问题?码工还是必须要有自己的武装组织vert.x 3还真的挺好用。大家对写map reduce有兴趣么？感觉很无聊阿要不这么好了学校科研用HIGHCHARTS 需要买LICESE吗？好玩的梦了：米饭均衡 。。。 (转载)HOW TO DELETE IN KEY-VALUE STOREHaskell的第二春老魏和老g的矛盾，有两个解决办法