p*****2
发帖数: 21240 | |
f*******t
发帖数: 7549 | |
p*****w
发帖数: 429 | 3 你们公司用了之后什么感觉?
【在 f*******t 的大作中提到】
: 我是搞HBase的……
|
f*******t
发帖数: 7549 | 4 我们是自己的fork，已经跟开源社区的分枝有很大差别了。现在use case越来越多，挺
好的
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****w 的大作中提到】
: 你们公司用了之后什么感觉?
|
p*****w
发帖数: 429 | 5 i see.我听说维护麻烦,而且replica多.
【在 f*******t 的大作中提到】
: 我们是自己的fork，已经跟开源社区的分枝有很大差别了。现在use case越来越多，挺
: 好的
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
f*******t
发帖数: 7549 | 6 维护是麻烦。replica多是指？
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****w 的大作中提到】
: i see.我听说维护麻烦,而且replica多.
|
p*****w
发帖数: 429 | 7 我不知道hbase里面叫什么,就是mysql里面要有slaves. 你们一份数据有多少复制?假设
你们肯定也是网站应用.
【在 f*******t 的大作中提到】
: 维护是麻烦。replica多是指？
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
p*****2
发帖数: 21240 | 8
膜拜大神。等我有问题再来问你。另外大神有比较过cassandra吗？
【在 f*******t 的大作中提到】
: 我是搞HBase的……
|
f*******t
发帖数: 7549 | 9 我们有三种replication：
1.异步replay log的slave
2.client同时写两个hbase，只从其中一个读取，对data loss和availability要求不高
3.quorum multi data center synchronous replication，快要发布了
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****w 的大作中提到】
: 我不知道hbase里面叫什么,就是mysql里面要有slaves. 你们一份数据有多少复制?假设
: 你们肯定也是网站应用.
|
f*******t
发帖数: 7549 | 10 没有，我进公司之前Cassandra已经被抛弃了
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****2 的大作中提到】
:
: 膜拜大神。等我有问题再来问你。另外大神有比较过cassandra吗？
|
|
|
g*****g
发帖数: 34805 | 11 Quancast?
【在 f*******t 的大作中提到】
: 我们有三种replication：
: 1.异步replay log的slave
: 2.client同时写两个hbase，只从其中一个读取，对data loss和availability要求不高
: 3.quorum multi data center synchronous replication，快要发布了
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
f*******t
发帖数: 7549 | 12 你说我的公司？fb
★ 发自iPhone App: ChineseWeb 8.6
【在 g*****g 的大作中提到】
: Quancast?
|
p*****w
发帖数: 429 | 13 messenger?
【在 f*******t 的大作中提到】
: 你说我的公司？fb
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
w**z
发帖数: 8232 | 14 去年HBasecon 一个中国小伙代表fb做keynotes, 很不错。
【在 f*******t 的大作中提到】
: 你说我的公司？fb
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
c******3
发帖数: 296 | 15 为什么抛弃C*?有什么技术上的考量吗？
【在 f*******t 的大作中提到】
: 没有，我进公司之前Cassandra已经被抛弃了
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
f*******t
发帖数: 7549 | 16 那是我们tech lead，挺牛的
【在 w**z 的大作中提到】
: 去年HBasecon 一个中国小伙代表fb做keynotes, 很不错。
|
f*******t
发帖数: 7549 | 17 具体细节我不清楚，至少eventually consistent model不能满足客户需求，尤其是
messaging这种对短时间内的data loss和disorder非常敏感的应用。
【在 c******3 的大作中提到】
: 为什么抛弃C*?有什么技术上的考量吗？
|
w**z
发帖数: 8232 | 18 方便透露，你们的newsfeed 存哪里的？
【在 f*******t 的大作中提到】
: 具体细节我不清楚，至少eventually consistent model不能满足客户需求，尤其是
: messaging这种对短时间内的data loss和disorder非常敏感的应用。
|
w**z
发帖数: 8232 | 19 从来没有明确说过原因。
【在 c******3 的大作中提到】
: 为什么抛弃C*?有什么技术上的考量吗？
|
f*******t
发帖数: 7549 | 20 他们本身有一个KV store，现在开始转向跟G丢出来的rocksdb（原名levelDB），C++派
大概不愿意用HBase
【在 w**z 的大作中提到】
: 方便透露，你们的newsfeed 存哪里的？
|
|
|
d*******r
发帖数: 3299 | 21 维护主要是哪点麻烦
【在 p*****w 的大作中提到】
: i see.我听说维护麻烦,而且replica多.
|
w**z
发帖数: 8232 | 22 那部分是用C++的？ 我们用C*存newsfeed。
【在 f*******t 的大作中提到】
: 他们本身有一个KV store，现在开始转向跟G丢出来的rocksdb（原名levelDB），C++派
: 大概不愿意用HBase
|
p*****2
发帖数: 21240 | 23 靠。HBase快把我搞死了。怪不得三驾马车里排行末位呢。一晚上没整work。 |
f*******t
发帖数: 7549 | 24 前端PHP，后端C++的经典搭配嘛
【在 w**z 的大作中提到】
: 那部分是用C++的？ 我们用C*存newsfeed。
|
z*******3
发帖数: 13709 | 25 主要是hadoop用了hbase吧
一开始fb用mysql，然后自己发明了c*，最后发现周围公司都在hadoop
于是就换到hbase去了
把c*贡献给了apache，apache把c*改造成了一个ap system
就非常适合搞缓存这种了，如果cp system，当然上来就是hbase了
这也没啥好考虑的
【在 c******3 的大作中提到】
: 为什么抛弃C*?有什么技术上的考量吗？
|
z*******3
发帖数: 13709 | 26 正常，哈哈
这是trade off
让你用couchbase的话，估计你不爽在后面
hbase好歹免费的文档多
【在 p*****2 的大作中提到】
: 靠。HBase快把我搞死了。怪不得三驾马车里排行末位呢。一晚上没整work。
|
p*****2
发帖数: 21240 | |
f*******t
发帖数: 7549 | |
p*****w
发帖数: 429 | 29 你们公司用了之后什么感觉?
【在 f*******t 的大作中提到】
: 我是搞HBase的……
|
f*******t
发帖数: 7549 | 30 我们是自己的fork，已经跟开源社区的分枝有很大差别了。现在use case越来越多，挺
好的
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****w 的大作中提到】
: 你们公司用了之后什么感觉?
|
|
|
p*****w
发帖数: 429 | 31 i see.我听说维护麻烦,而且replica多.
【在 f*******t 的大作中提到】
: 我们是自己的fork，已经跟开源社区的分枝有很大差别了。现在use case越来越多，挺
: 好的
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
f*******t
发帖数: 7549 | 32 维护是麻烦。replica多是指？
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****w 的大作中提到】
: i see.我听说维护麻烦,而且replica多.
|
p*****w
发帖数: 429 | 33 我不知道hbase里面叫什么,就是mysql里面要有slaves. 你们一份数据有多少复制?假设
你们肯定也是网站应用.
【在 f*******t 的大作中提到】
: 维护是麻烦。replica多是指？
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
p*****2
发帖数: 21240 | 34
膜拜大神。等我有问题再来问你。另外大神有比较过cassandra吗？
【在 f*******t 的大作中提到】
: 我是搞HBase的……
|
f*******t
发帖数: 7549 | 35 我们有三种replication：
1.异步replay log的slave
2.client同时写两个hbase，只从其中一个读取，对data loss和availability要求不高
3.quorum multi data center synchronous replication，快要发布了
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****w 的大作中提到】
: 我不知道hbase里面叫什么,就是mysql里面要有slaves. 你们一份数据有多少复制?假设
: 你们肯定也是网站应用.
|
f*******t
发帖数: 7549 | 36 没有，我进公司之前Cassandra已经被抛弃了
★ 发自iPhone App: ChineseWeb 8.6
【在 p*****2 的大作中提到】
:
: 膜拜大神。等我有问题再来问你。另外大神有比较过cassandra吗？
|
g*****g
发帖数: 34805 | 37 Quancast?
【在 f*******t 的大作中提到】
: 我们有三种replication：
: 1.异步replay log的slave
: 2.client同时写两个hbase，只从其中一个读取，对data loss和availability要求不高
: 3.quorum multi data center synchronous replication，快要发布了
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
f*******t
发帖数: 7549 | 38 你说我的公司？fb
★ 发自iPhone App: ChineseWeb 8.6
【在 g*****g 的大作中提到】
: Quancast?
|
p*****w
发帖数: 429 | 39 messenger?
【在 f*******t 的大作中提到】
: 你说我的公司？fb
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
w**z
发帖数: 8232 | 40 去年HBasecon 一个中国小伙代表fb做keynotes, 很不错。
【在 f*******t 的大作中提到】
: 你说我的公司？fb
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
|
|
c******3
发帖数: 296 | 41 为什么抛弃C*?有什么技术上的考量吗？
【在 f*******t 的大作中提到】
: 没有，我进公司之前Cassandra已经被抛弃了
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
f*******t
发帖数: 7549 | 42 那是我们tech lead，挺牛的
【在 w**z 的大作中提到】
: 去年HBasecon 一个中国小伙代表fb做keynotes, 很不错。
|
f*******t
发帖数: 7549 | 43 具体细节我不清楚，至少eventually consistent model不能满足客户需求，尤其是
messaging这种对短时间内的data loss和disorder非常敏感的应用。
【在 c******3 的大作中提到】
: 为什么抛弃C*?有什么技术上的考量吗？
|
w**z
发帖数: 8232 | 44 方便透露，你们的newsfeed 存哪里的？
【在 f*******t 的大作中提到】
: 具体细节我不清楚，至少eventually consistent model不能满足客户需求，尤其是
: messaging这种对短时间内的data loss和disorder非常敏感的应用。
|
w**z
发帖数: 8232 | 45 从来没有明确说过原因。
【在 c******3 的大作中提到】
: 为什么抛弃C*?有什么技术上的考量吗？
|
f*******t
发帖数: 7549 | 46 他们本身有一个KV store，现在开始转向跟G丢出来的rocksdb（原名levelDB），C++派
大概不愿意用HBase
【在 w**z 的大作中提到】
: 方便透露，你们的newsfeed 存哪里的？
|
d*******r
发帖数: 3299 | 47 维护主要是哪点麻烦
【在 p*****w 的大作中提到】
: i see.我听说维护麻烦,而且replica多.
|
w**z
发帖数: 8232 | 48 那部分是用C++的？ 我们用C*存newsfeed。
【在 f*******t 的大作中提到】
: 他们本身有一个KV store，现在开始转向跟G丢出来的rocksdb（原名levelDB），C++派
: 大概不愿意用HBase
|
p*****2
发帖数: 21240 | 49 靠。HBase快把我搞死了。怪不得三驾马车里排行末位呢。一晚上没整work。 |
f*******t
发帖数: 7549 | 50 前端PHP，后端C++的经典搭配嘛
【在 w**z 的大作中提到】
: 那部分是用C++的？ 我们用C*存newsfeed。
|
|
|
z*******3
发帖数: 13709 | 51 主要是hadoop用了hbase吧
一开始fb用mysql，然后自己发明了c*，最后发现周围公司都在hadoop
于是就换到hbase去了
把c*贡献给了apache，apache把c*改造成了一个ap system
就非常适合搞缓存这种了，如果cp system，当然上来就是hbase了
这也没啥好考虑的
【在 c******3 的大作中提到】
: 为什么抛弃C*?有什么技术上的考量吗？
|
z*******3
发帖数: 13709 | 52 正常，哈哈
这是trade off
让你用couchbase的话，估计你不爽在后面
hbase好歹免费的文档多
【在 p*****2 的大作中提到】
: 靠。HBase快把我搞死了。怪不得三驾马车里排行末位呢。一晚上没整work。
|
z*******3
发帖数: 13709 | 53 不过不对啊
你们不是早就hadoop了么？
hadoop难道不是用hbase做persistence？
c*大多数时候我们是用来存一些非重要性数据
比如log这些，当典型的nosql用
主要目的是读写快，反正牺牲掉了短期的consistent
hbase更多的是一种db的替代
就是没有transaction就是了
只要你不update历史数据，都没啥问题 |
z*******3
发帖数: 13709 | 54 我一直都认为c*和mongodb这些，不是一个层面的，跟hbase
hbase是非用不可，除非你不用hadoop
但是在这个之前，有无数种方式予以优化，c*只是其中一种
这个内森那篇文章介绍storm时候说得很好啊
他用了三个persistence
分别是c*，hbase和他自己写的elephonedb
其实把这里elephonedb换成postgresql也一样用
你们才用一个数据库或者nosql的产品吗？
我现在就用了三个了，hbase虽然也用，但是主要时间不是在hbase上
而是在c*这些更靠近前端的缓冲库上，还有db
【在 p*****2 的大作中提到】
: 靠。HBase快把我搞死了。怪不得三驾马车里排行末位呢。一晚上没整work。
|
p*****2
发帖数: 21240 | 55 hadoop可以用hdfs吧
【在 z*******3 的大作中提到】
: 不过不对啊
: 你们不是早就hadoop了么？
: hadoop难道不是用hbase做persistence？
: c*大多数时候我们是用来存一些非重要性数据
: 比如log这些，当典型的nosql用
: 主要目的是读写快，反正牺牲掉了短期的consistent
: hbase更多的是一种db的替代
: 就是没有transaction就是了
: 只要你不update历史数据，都没啥问题
|
p*****2
发帖数: 21240 | 56 我们主要Redis mongo
【在 z*******3 的大作中提到】
: 我一直都认为c*和mongodb这些，不是一个层面的，跟hbase
: hbase是非用不可，除非你不用hadoop
: 但是在这个之前，有无数种方式予以优化，c*只是其中一种
: 这个内森那篇文章介绍storm时候说得很好啊
: 他用了三个persistence
: 分别是c*，hbase和他自己写的elephonedb
: 其实把这里elephonedb换成postgresql也一样用
: 你们才用一个数据库或者nosql的产品吗？
: 我现在就用了三个了，hbase虽然也用，但是主要时间不是在hbase上
: 而是在c*这些更靠近前端的缓冲库上，还有db
|
p*****2
发帖数: 21240 | 57 好虫不是说c也可以cp吗
【在 z*******3 的大作中提到】
: 主要是hadoop用了hbase吧
: 一开始fb用mysql，然后自己发明了c*，最后发现周围公司都在hadoop
: 于是就换到hbase去了
: 把c*贡献给了apache，apache把c*改造成了一个ap system
: 就非常适合搞缓存这种了，如果cp system，当然上来就是hbase了
: 这也没啥好考虑的
|
p*****2
发帖数: 21240 | 58 貌似需要重启zookeeper 这个看来稳定性有点问题呀
【在 z*******3 的大作中提到】
: 正常，哈哈
: 这是trade off
: 让你用couchbase的话，估计你不爽在后面
: hbase好歹免费的文档多
|
H****S
发帖数: 1359 | 59 不喜欢用，.meta table如果被戳了几个洞处理起来很麻烦。
【在 p*****2 的大作中提到】
: 感觉一水Cassandra。
|
d*******r
发帖数: 3299 | 60 hadoop 有这么必须? 只能处理 offline batch job, 学起来还麻烦，现在还在转 2.0,
看着有点晕呢
【在 z*******3 的大作中提到】
: 我一直都认为c*和mongodb这些，不是一个层面的，跟hbase
: hbase是非用不可，除非你不用hadoop
: 但是在这个之前，有无数种方式予以优化，c*只是其中一种
: 这个内森那篇文章介绍storm时候说得很好啊
: 他用了三个persistence
: 分别是c*，hbase和他自己写的elephonedb
: 其实把这里elephonedb换成postgresql也一样用
: 你们才用一个数据库或者nosql的产品吗？
: 我现在就用了三个了，hbase虽然也用，但是主要时间不是在hbase上
: 而是在c*这些更靠近前端的缓冲库上，还有db
|
|
|
z****e
发帖数: 54598 | 61 要tune
麻烦
懒得做
而且各种features少很多
我们弄个cache不就是图方便么？
mongodb最大的卖点也是简单，容易上手，像db
要不然谁用它？
【在 p*****2 的大作中提到】
: 好虫不是说c也可以cp吗
|
z****e
发帖数: 54598 | 62 是没这么必需，但是现在不都在big data么？
是个人就上hadoop，现在差不多是时候让它破了
规模没有到的，不上也罢
但是对于到了这个规模的，其实这后面是另外一套系统
跟前台作页面的不在一个层面上
到时候估计都是另外一个组在做
如果这个层面跟前台是同一批人在做的话
那就说明这个其实是滥用，前台程序员还是专心做点js比较好
前台用hadoop有些扯淡
0,
【在 d*******r 的大作中提到】
: hadoop 有这么必须? 只能处理 offline batch job, 学起来还麻烦，现在还在转 2.0,
: 看着有点晕呢
|
d*******r
发帖数: 3299 | 63 每次看到hadoop2.0那个构架图，我就觉得它想做的事情太多了...
http://hortonworks.com/hadoop/yarn/
【在 z****e 的大作中提到】
: 是没这么必需，但是现在不都在big data么？
: 是个人就上hadoop，现在差不多是时候让它破了
: 规模没有到的，不上也罢
: 但是对于到了这个规模的，其实这后面是另外一套系统
: 跟前台作页面的不在一个层面上
: 到时候估计都是另外一个组在做
: 如果这个层面跟前台是同一批人在做的话
: 那就说明这个其实是滥用，前台程序员还是专心做点js比较好
: 前台用hadoop有些扯淡
:
|
z****e
发帖数: 54598 | 64 他们考虑的至少是至少上千一般上万台机器的处理
不是有牛人介绍过yarn么？
说目前除了yahoo，其他公司恐怕都达不到这个规模
你们公司有cdo这个职位么？
http://en.wikipedia.org/wiki/Chief_data_officer
如果有的话，用这个差不多
否则就有些overkill了
我不是很喜欢这种搞法，太重了，就像以前ejb一样
什么情况都按照最复杂的情况来处理，简单的反而更容易搞定市场
所以cassandra很好啊，对付大多数网站其实足够了，配合一个简单的db
比如postgresql，可以了
【在 d*******r 的大作中提到】
: 每次看到hadoop2.0那个构架图，我就觉得它想做的事情太多了...
: http://hortonworks.com/hadoop/yarn/
|
z****e
发帖数: 54598 | 65 可以阿，但是纯文件搞起来也有些低效率
当然还是优先考虑堆轮子了
hdfs上也没有其他数据库可以用了
【在 p*****2 的大作中提到】
: hadoop可以用hdfs吧
|
z****e
发帖数: 54598 | |
z****e
发帖数: 54598 | 67 过了一段时间回头看这个图
发现yarn上连hpc的mpi接口都有阿
啧啧，高大上，高大上
【在 d*******r 的大作中提到】
: 每次看到hadoop2.0那个构架图，我就觉得它想做的事情太多了...
: http://hortonworks.com/hadoop/yarn/
|
d*******r
发帖数: 3299 | 68 看完后更坚定了不花时间学习hadoop2.0的决定...
我等屌丝projects肯定用不上了，自己也不喜欢这么复杂的东西
【在 z****e 的大作中提到】
: http://www.mitbbs.com/article_t/Java/31140605.html
|
z****e
发帖数: 54598 | 69 然，这个等进了yahoo之类再学不迟
大多数人真用不到这么复杂的东西
【在 d*******r 的大作中提到】
: 看完后更坚定了不花时间学习hadoop2.0的决定...
: 我等屌丝projects肯定用不上了，自己也不喜欢这么复杂的东西
|
d*******r
发帖数: 3299 | 70 我有同学就在yahoo里面写这个，我听他说也是一头雾水，估计他也是个螺丝钉而已
【在 z****e 的大作中提到】
: 然，这个等进了yahoo之类再学不迟
: 大多数人真用不到这么复杂的东西
|
|
|
z****e
发帖数: 54598 | 71 正常，正常
大多数人都是瞎子摸象
世界这么大，没有人能知道全部东西
立足本行，然后渗透周边知识点，能做到这点已经很牛逼了
只有五年硕士这种，才会大言不惭说自己什么都懂
其实什么都不懂
【在 d*******r 的大作中提到】
: 我有同学就在yahoo里面写这个，我听他说也是一头雾水，估计他也是个螺丝钉而已
|
t***t
发帖数: 6066 | 72 is big data a hype?
2 weeks ago, visited a start up, they are just using mysql. they said unless
you are yahoo or google, you can just use mysql for everything. |
w**z
发帖数: 8232 | 73 道理是这样的。就像那么多startup 都是用php。time to market 是最重要的。mysql
还是懂的人多，没有learning curve。 但随着nosql 的普及，会的人多了，就会有小
公司开始用了。如果我现在换工作，去一个小公司，凭我对C＊的熟悉，我就会在合适
的情况下上。
unless
【在 t***t 的大作中提到】
: is big data a hype?
: 2 weeks ago, visited a start up, they are just using mysql. they said unless
: you are yahoo or google, you can just use mysql for everything.
|
d*******r
发帖数: 3299 | 74 postgresql 还是远远不如 mysql?
感觉从 postgresql 转 mysql 也不难呀
mysql
【在 w**z 的大作中提到】
: 道理是这样的。就像那么多startup 都是用php。time to market 是最重要的。mysql
: 还是懂的人多，没有learning curve。 但随着nosql 的普及，会的人多了，就会有小
: 公司开始用了。如果我现在换工作，去一个小公司，凭我对C＊的熟悉，我就会在合适
: 的情况下上。
:
: unless
|
g*****g
发帖数: 34805 | 75 startup can have 400 users, or 400 million users, the technology chosen is
dependent on the scale.
mysql
【在 w**z 的大作中提到】
: 道理是这样的。就像那么多startup 都是用php。time to market 是最重要的。mysql
: 还是懂的人多，没有learning curve。 但随着nosql 的普及，会的人多了，就会有小
: 公司开始用了。如果我现在换工作，去一个小公司，凭我对C＊的熟悉，我就会在合适
: 的情况下上。
:
: unless
|
t***t
发帖数: 6066 | 76 应该差不多吧？都是传统db。
没用过postgresql。mysql被oracle给慢性自杀了，十年基本没有development。
【在 d*******r 的大作中提到】
: postgresql 还是远远不如 mysql?
: 感觉从 postgresql 转 mysql 也不难呀
:
: mysql
|
z****e
发帖数: 54598 | 77 主要是很多用户有惯性
所以都还在mysql
我在sun被收购那天起就不用mysql了
坚决postgresql
which is written in pure c
good one
【在 t***t 的大作中提到】
: 应该差不多吧？都是传统db。
: 没用过postgresql。mysql被oracle给慢性自杀了，十年基本没有development。
|
