s********k
发帖数: 6180 | 1 FB 当年自己做的Cassandra，然后反而觉得bigtable系的Hbase更好基本放弃C，反而之
后Cassandra又做大，现在准备选型的话，需要支持record version，然后不需要强
consistency，哪个比较合适 |
w**z
发帖数: 8232 | 2 Cassandra 吧，社区活跃，维护更简便。
：FB 当年自己做的Cassandra，然后反而觉得bigtable系的Hbase更好基本放弃C，反而
之后Cassandra又做大，现在准备选型的话，需要支持record version，然后不需要强
：consistency，哪个比较合适 |
i*****9
发帖数: 3157 | 3 不在意 consistency 就选 Cassandra, 在意 consistency 且规模较大的话其实没得选。
：FB 当年自己做的Cassandra，然后反而觉得bigtable系的Hbase更好基本放弃C，反而
之后Cassandra又做大，现在准备选型的话，需要支持record version，然后不需要强
：consistency，哪个比较合适 |
s********k
发帖数: 6180 | 4 没得选的意思是没有合适的？Hbase现在在哪种场景下还用的多？
选。
【在 i*****9 的大作中提到】
: 不在意 consistency 就选 Cassandra, 在意 consistency 且规模较大的话其实没得选。
:
: ：FB 当年自己做的Cassandra，然后反而觉得bigtable系的Hbase更好基本放弃C，反而
: 之后Cassandra又做大，现在准备选型的话，需要支持record version，然后不需要强
: ：consistency，哪个比较合适
|
f*******t
发帖数: 7549 | 5 fb已经放弃hbase了，还是用cassandra吧。 |
h**j
发帖数: 2033 | 6 据说湾区做indexing系统大都是在hbase上搞
【在 s********k 的大作中提到】
: 没得选的意思是没有合适的？Hbase现在在哪种场景下还用的多？
:
: 选。
|
w**z
发帖数: 8232 | 7 据谁说的？大的 indexing 一般都是用 C++ 自己撸一套
【在 h**j 的大作中提到】
: 据说湾区做indexing系统大都是在hbase上搞
|
f******2
发帖数: 2455 | 8 这东西不是solr，elasticsearch搭积木吗？最多从lucene搞起吧？从头写没太听说过
: 据谁说的？大的 indexing 一般都是用 C 自己撸一套
【在 w**z 的大作中提到】
: 据谁说的？大的 indexing 一般都是用 C++ 自己撸一套
|
w**z
发帖数: 8232 | 9 大家伙的 searching index 都是自己撸的。
：这东西不是solr，elasticsearch搭积木吗？最多从lucene搞起吧？从头写没太听说过
： |
s********k
发帖数: 6180 | 10 可以理解，因为Hbase是col base的，而且支持field做verision，不过其实Hbase的查
询都是底下跑的mapreduce？是不是比较慢？
【在 h**j 的大作中提到】
: 据说湾区做indexing系统大都是在hbase上搞
|
|
|
f*******t
发帖数: 7549 | 11 hbase不跑mapreduce啊
【在 s********k 的大作中提到】
: 可以理解，因为Hbase是col base的，而且支持field做verision，不过其实Hbase的查
: 询都是底下跑的mapreduce？是不是比较慢？
|
s********k
发帖数: 6180 | 12 哦那我理解有误，Hbase是不是一般比较慢
【在 f*******t 的大作中提到】
: hbase不跑mapreduce啊
|
w**z
发帖数: 8232 | 13 你这理解差的有点远，自己好好做功课吧。
：哦那我理解有误，Hbase是不是一般比较慢
：【 在 fantasist (一) 的大作中提到: 】 |
i*****9
发帖数: 3157 | 14 其实用不用Hbase 是个伪命题，重点是要不要用 zookeeper ...
：没得选的意思是没有合适的？Hbase现在在哪种场景下还用的多？
：【 在 insect9 (insect9) 的大作中提到: 】 |
f******2
发帖数: 2455 | 15 Silver同学的确需要看看基本知识，这个理解不是一般的远。
: 你这理解差的有点远，自己好好做功课吧。
: ：哦那我理解有误，Hbase是不是一般比较慢
: ：【 在 fantasist (一) 的大作中提到: 】
【在 w**z 的大作中提到】
: 你这理解差的有点远，自己好好做功课吧。
:
: ：哦那我理解有误，Hbase是不是一般比较慢
: ：【 在 fantasist (一) 的大作中提到: 】
|
f******2
发帖数: 2455 | 16 这个基本讲到问题的核心上了，在我看来其实就是operation成本。
碰到上来就画cap三角形的一些小年轻，感觉可以教育的就多说两句；不可以教育的就
笑笑，竖竖大拇指，说你真有知识
: 其实用不用Hbase 是个伪命题，重点是要不要用 zookeeper ...
: ：没得选的意思是没有合适的？Hbase现在在哪种场景下还用的多？
: ：【 在 insect9 (insect9) 的大作中提到: 】
【在 i*****9 的大作中提到】
: 其实用不用Hbase 是个伪命题，重点是要不要用 zookeeper ...
:
: ：没得选的意思是没有合适的？Hbase现在在哪种场景下还用的多？
: ：【 在 insect9 (insect9) 的大作中提到: 】
|
s********k
发帖数: 6180 | 17 怎么讲？
【在 i*****9 的大作中提到】
: 其实用不用Hbase 是个伪命题，重点是要不要用 zookeeper ...
:
: ：没得选的意思是没有合适的？Hbase现在在哪种场景下还用的多？
: ：【 在 insect9 (insect9) 的大作中提到: 】
|
s********k
发帖数: 6180 | 18 正在补课中，版上大牛们提点一下
【在 f******2 的大作中提到】
: Silver同学的确需要看看基本知识，这个理解不是一般的远。
:
:
: 你这理解差的有点远，自己好好做功课吧。
:
: ：哦那我理解有误，Hbase是不是一般比较慢
:
: ：【 在 fantasist (一) 的大作中提到: 】
:
|
s********k
发帖数: 6180 | 19 说说都是怎么教育的？
【在 f******2 的大作中提到】
: 这个基本讲到问题的核心上了，在我看来其实就是operation成本。
: 碰到上来就画cap三角形的一些小年轻，感觉可以教育的就多说两句；不可以教育的就
: 笑笑，竖竖大拇指，说你真有知识
:
:
: 其实用不用Hbase 是个伪命题，重点是要不要用 zookeeper ...
:
: ：没得选的意思是没有合适的？Hbase现在在哪种场景下还用的多？
:
: ：【 在 insect9 (insect9) 的大作中提到: 】
:
|
i*****9
发帖数: 3157 | 20 去看一遍Google chubby 的论文，你就知道要实现一个真正可靠的 paxos 的通讯开销
有多高。然后就能想明白 Cassandra 要把锁逻辑集成到存储节点里来简化部署在真正
大规模部署环境下有多不靠谱。
：怎么讲？
：【 在 insect9 (insect9) 的大作中提到: 】 |
|
|
l**********0
发帖数: 150 | 21 是hive，确实不快
【在 s********k 的大作中提到】
: 哦那我理解有误，Hbase是不是一般比较慢
|
w**z
发帖数: 8232 | 22 Cassandra 追求的high write throughput. 所以是 eventual consistency. 不同的场
景，用不同的solution
netflix 95% 的data 是存在 cassandra. 大的cluster 有几百个node， 怎么叫在真正
大规模部署环境下有多不靠谱？
【在 i*****9 的大作中提到】
: 去看一遍Google chubby 的论文，你就知道要实现一个真正可靠的 paxos 的通讯开销
: 有多高。然后就能想明白 Cassandra 要把锁逻辑集成到存储节点里来简化部署在真正
: 大规模部署环境下有多不靠谱。
:
: ：怎么讲？
: ：【 在 insect9 (insect9) 的大作中提到: 】
|
s********k
发帖数: 6180 | 23 Cassandra就是write到一个data center，然后其他global data center再sync？一般
用个几百ms？
【在 w**z 的大作中提到】
: Cassandra 追求的high write throughput. 所以是 eventual consistency. 不同的场
: 景，用不同的solution
: netflix 95% 的data 是存在 cassandra. 大的cluster 有几百个node， 怎么叫在真正
: 大规模部署环境下有多不靠谱？
|
i*****9
发帖数: 3157 | 24 你高兴就好
：Cassandra 追求的high write throughput. 所以是 eventual consistency. 不同的
场景，用不同的solution
： |
w**z
发帖数: 8232 | 25 你可以自己设replication factor， 如果设了，Cassandra 自动帮你replicate
across DC， latency mostly is caused by the network. 具体多长latency， 需要
自己测一下。
【在 s********k 的大作中提到】
: Cassandra就是write到一个data center，然后其他global data center再sync？一般
: 用个几百ms？
|
w**z
发帖数: 8232 | 26 我高不高兴无所谓，但是Netflix seems to be happy with Cassandra.
【在 i*****9 的大作中提到】
: 你高兴就好
:
: ：Cassandra 追求的high write throughput. 所以是 eventual consistency. 不同的
: 场景，用不同的solution
: ：
|
l***p
发帖数: 358 | 27 一副高高在上的感觉
【在 i*****9 的大作中提到】
: 你高兴就好
:
: ：Cassandra 追求的high write throughput. 所以是 eventual consistency. 不同的
: 场景，用不同的solution
: ：
|
s********k
发帖数: 6180 | 28 一般来说，如果Cassandra配合cache用的话，那么cache也需要再有一套global DC之间
sync的办法?否则需要其他DC的explicit invalid cache？
比如之前我的某个 cache line= 葵花宝典”，然后全球10个DC的cache somehow都有这
个.之后DC2 重新写成了 cache line= “辟邪剑法”， write这个DC的cassandra
write through，然后其他9个DC的 DB上都陆续更新（1s 之内），但是其他9个DC的
cache line“葵花宝典”是会被相应DC invalid？还是有其他cache之间的sync办法？
一般用什么最好？
【在 w**z 的大作中提到】
: 你可以自己设replication factor， 如果设了，Cassandra 自动帮你replicate
: across DC， latency mostly is caused by the network. 具体多长latency， 需要
: 自己测一下。
|
w**z
发帖数: 8232 | 29 invalidate cache after successful writes 是application 的任务, 和DB无关。
depends on your write consistency level setting, application 选择何时
invalidate cache。
【在 s********k 的大作中提到】
: 一般来说，如果Cassandra配合cache用的话，那么cache也需要再有一套global DC之间
: sync的办法?否则需要其他DC的explicit invalid cache？
: 比如之前我的某个 cache line= 葵花宝典”，然后全球10个DC的cache somehow都有这
: 个.之后DC2 重新写成了 cache line= “辟邪剑法”， write这个DC的cassandra
: write through，然后其他9个DC的 DB上都陆续更新（1s 之内），但是其他9个DC的
: cache line“葵花宝典”是会被相应DC invalid？还是有其他cache之间的sync办法？
: 一般用什么最好？
|
i*****9
发帖数: 3157 | 30 很正常呀，因为 Netflix 的业务需求对 consistency 压根没要求。丢几条写请求无非
就是 用户视频 resume 的时候差了十几秒。就算严重点，用户收藏一个电影事后发现
没收藏上都算不了什么大事。
其实，到最后没多少应用真的要求 consistency, 这就是为啥 Cassandra 在被FB放弃
之后依然可以活得很好的原因。但对于真的需要 consistency 的场景，比如 Google,
比如FB， 也包括 Twitter, 用 Cassandra 就属于找死。
：我高不高兴无所谓，但是Netflix seems to be happy with Cassandra.
：【 在 insect9 (insect9) 的大作中提到: 】 |
|
|
l***p
发帖数: 358 | 31 google/fb 那些服务需要强一致性？
,
【在 i*****9 的大作中提到】
: 很正常呀，因为 Netflix 的业务需求对 consistency 压根没要求。丢几条写请求无非
: 就是 用户视频 resume 的时候差了十几秒。就算严重点，用户收藏一个电影事后发现
: 没收藏上都算不了什么大事。
: 其实，到最后没多少应用真的要求 consistency, 这就是为啥 Cassandra 在被FB放弃
: 之后依然可以活得很好的原因。但对于真的需要 consistency 的场景，比如 Google,
: 比如FB， 也包括 Twitter, 用 Cassandra 就属于找死。
:
: ：我高不高兴无所谓，但是Netflix seems to be happy with Cassandra.
: ：【 在 insect9 (insect9) 的大作中提到: 】
|
i*****9
发帖数: 3157 | 32 广告
：google/fb 那些服务需要强一致性？
： |
s********k
发帖数: 6180 | 33 FB点赞之类的应该用Cassandra也可以吧，不同地区用户短时间内看到赞差一些问题应
该不大
,
【在 i*****9 的大作中提到】
: 很正常呀，因为 Netflix 的业务需求对 consistency 压根没要求。丢几条写请求无非
: 就是 用户视频 resume 的时候差了十几秒。就算严重点，用户收藏一个电影事后发现
: 没收藏上都算不了什么大事。
: 其实，到最后没多少应用真的要求 consistency, 这就是为啥 Cassandra 在被FB放弃
: 之后依然可以活得很好的原因。但对于真的需要 consistency 的场景，比如 Google,
: 比如FB， 也包括 Twitter, 用 Cassandra 就属于找死。
:
: ：我高不高兴无所谓，但是Netflix seems to be happy with Cassandra.
: ：【 在 insect9 (insect9) 的大作中提到: 】
|
f*******t
发帖数: 7549 | 34 user account and relationship (e.g. friends), post and comment, message
【在 l***p 的大作中提到】
: google/fb 那些服务需要强一致性？
:
: ,
|
w**z
发帖数: 8232 | 35 post, comments 为什么需要 strong consistency? eventual consistency 在绝大多
数情况下只是delay 几个到几十 ms, 对于这些功能足够了。
：user account and relationship (e.g. friends), post and comment, message
：【 在 lauxp (秀才黄学州) 的大作中提到: 】 |
i*****9
发帖数: 3157 | 36 对于 Netflix 或是 Amazon 来说确实足够了，对于 FB 来说就要慢慢和用户解释他发
的帖子真的不是被人工审核屏蔽了，而是真的被系统 bug 不小心弄丢了，然后就是祈
祷用户真的会信，不会被捅到媒体上。
Amazon 的书评其实也有类似问题，不过 Amazon 显然属于债多不愁，技术上解决不了
就靠收购媒体来解决了。
：post, comments 为什么需要 strong consistency? eventual consistency 在绝大多
：数情况下只是delay 几个到几十 ms, 对于这些功能足够了。 |
i*****9
发帖数: 3157 | 37 eventually consistent 并不是说只有一小段时间的不一致，而是说经过不确定的时间
后理论上能实现最终一致。所以在一个持续更新的系统中，任何一个时间点获取一个系
统的镜像，你都可以认为得到的数据是大概率存在不一致的。
在这样一个系统中要维护一个可靠的好友关系都做不到，因为删一个好友，随后发一条
消息。这条消息会不会被刚被删的好友看见是不确定的。当然，在产品做到一定规模之
前，这种以万分之一以下概率出现行为未定义的情况，大家都不在意就好了。
只要别蠢到把和财务相关的流程放到这些不靠谱的分布式系统上就不会死的太难看。
：FB点赞之类的应该用Cassandra也可以吧，不同地区用户短时间内看到赞差一些问题应
：该不大 |
w**z
发帖数: 8232 | 38 你觉得 eventual consistency 就是丢东西？
：对于 Netflix 或是 Amazon 来说确实足够了，对于 FB 来说就要慢慢和用户解释他发
：的帖子真的不是被人工审核屏蔽了，而是真的被系统 bug 不小心弄丢了，然后就是祈 |
i*****9
发帖数: 3157 | 39 只是丢东西算实现的好的了，冒出完全不存在的数据那才叫麻烦。Cassandra 的实现算
好的，貌似只是会丢东西。
并不存在AP之后 eventually C 这种东西，只能是大概率C，99.9%， 99.9999%都有可
能，但最终还是会丢。就看你的产品设计能不能承受了。
：你觉得 eventual consistency 就是丢东西？
： |
w**z
发帖数: 8232 | 40 照你这说法，只要是软件，就会有 bug， 所以不存在保证 consistent 的东西。就是
全写进磁盘,磁盘也有可能坏，你可以备份，备份也有可能全坏了。
：只是丢东西算实现的好的了，冒出完全不存在的数据那才叫麻烦。Cassandra 的实现
算好的，貌似只是会丢东西。
： |
|
|
i*****9
发帖数: 3157 | 41 CP系统的特点就是如果系统Ack 了写操作是成功的，那么只要这个系统还有超过一半的
硬盘完好，那这个写入的信息就确定存在。当系统中超过一半的硬盘同时损坏，那么所
有数据是全部不可读的状态，只能从之前的镜像恢复。不存在一种数据部分可用的不一
致状态。
在这种状态下，任何一个时间点的系统镜像都是可 audit 的。这才能保证年终审计的
时候账目能对得上。
总之, Netflix 对一致性没要求，不代表所有公司都对一致性没要求。你用一致性没保
障的东西用得高兴，就继续用。但非说他对一致性有保障就没意思了。
：照你这说法，只要是软件，就会有 bug， 所以不存在保证 consistent 的东西。就是
：全写进磁盘,磁盘也有可能坏，你可以备份，备份也有可能全坏了。 |
l***p
发帖数: 358 | 42 可能我的理解有偏差，我觉得恰恰相反，social 这块 A 最重要，C相对而言无需最求
极致
tranaction才是强一致性应用场景，比如amzon你买一个东西
大多
【在 i*****9 的大作中提到】
: 对于 Netflix 或是 Amazon 来说确实足够了，对于 FB 来说就要慢慢和用户解释他发
: 的帖子真的不是被人工审核屏蔽了，而是真的被系统 bug 不小心弄丢了，然后就是祈
: 祷用户真的会信，不会被捅到媒体上。
: Amazon 的书评其实也有类似问题，不过 Amazon 显然属于债多不愁，技术上解决不了
: 就靠收购媒体来解决了。
:
: ：post, comments 为什么需要 strong consistency? eventual consistency 在绝大多
: ：数情况下只是delay 几个到几十 ms, 对于这些功能足够了。
|
l***p
发帖数: 358 | 43 同问，想听听这位自认看透一切的大牛是怎么理解的，他自己有没有出过什么大作
说说都是怎么教育的？
【在 s********k 的大作中提到】
: 说说都是怎么教育的？
|
i*****9
发帖数: 3157 | 44 transaction 类的应用，敢于去用Cassandra 这类产品的二逼公司不多。
social 上对A当然重要，所以也没人把social 的内容往传统SQL上放。但是，对C也不
是彻底没有要求。在P这一点不可讨论的前提下，最终都是AC和预算如何平衡的问题。
预算有限，规模不大的时候，当然是A优先于C。所以你要是小公司，在不涉及钱的应用
场景，用 Cassandra 是很好的选择。
但对于大规模的公司来说，尤其是GF这种核心业务要涉及钱了，就需要更多的投入在保
证C的前提下同时把A提高到六个9的水平甚至更高了。
：可能我的理解有偏差，我觉得恰恰相反，social 这块 A 最重要，C相对而言无需最求
：极致 |
w**z
发帖数: 8232 | 45 Cassandra 是 ap, 但是 consistency level is tunable.
：CP系统的特点就是如果系统Ack 了写操作是成功的，那么只要这个系统还有超过一半
的硬盘完好，那这个写入的信息就确定存在。当系统中超过一半的硬盘同时损坏，那么
所有数据是全部不可读的状态，只能从之前的镜像恢复。不存在一种数据部分可用的不
一致状态。
： |
w**z
发帖数: 8232 | 46 扯了半天，不还是 CAP?
你的最先论点是
然后就能想明白 Cassandra 要把锁逻辑集成到存储节点里来简化部署在真正 大规模部
署环境下有多不靠谱。
我举了 Netflix 的大规模部署例子,你又开始扯 consistency 不靠谱。 Cassandra
default 就是 ap 系统。不知道你想说什么。
：transaction 类的应用，敢于去用Cassandra 这类产品的二逼公司不多。
： |
i*****9
发帖数: 3157 | 47 他能tune 到的最高的 consistency level 都无法做到 consistent.
而他的架构使得这玩意要通过修改实现使得 consistency 可接受的话，大规模部署时
的 availability 就彻底不可接受。
所以任何大规模部署的系统，如果真的对 consistency 有要求，而不是"高兴就好
"的话，唯一的选择就是搭建在 zookeeper 上的系统。
所以，先想清楚产品到底是不是需要 consistency 是第一步。
：Cassandra 是 ap, 但是 consistency level is tunable.
： |
w**z
发帖数: 8232 | 48 你把Cassandra write and read consistency 都弄成 quorum, 它就是 strong
consistency.
Zookeeper 在大规模系统应用里，会是bottleneck， 这是业界公认的。 Zookeeper
通常是用来manage metadata, 这和DB 的 consistency level 根本就是两码事。
【在 i*****9 的大作中提到】
: 他能tune 到的最高的 consistency level 都无法做到 consistent.
: 而他的架构使得这玩意要通过修改实现使得 consistency 可接受的话，大规模部署时
: 的 availability 就彻底不可接受。
: 所以任何大规模部署的系统，如果真的对 consistency 有要求，而不是"高兴就好
: "的话，唯一的选择就是搭建在 zookeeper 上的系统。
: 所以，先想清楚产品到底是不是需要 consistency 是第一步。
:
: ：Cassandra 是 ap, 但是 consistency level is tunable.
: ：
|
