z*******3
发帖数: 13709 | 1 正常，哈哈
这是trade off
让你用couchbase的话，估计你不爽在后面
hbase好歹免费的文档多 |
|
|
p*****w
发帖数: 429 | 3 我不知道hbase里面叫什么,就是mysql里面要有slaves. 你们一份数据有多少复制?假设
你们肯定也是网站应用. |
|
f*******t
发帖数: 7549 | 4 我们有三种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 | 5 他们本身有一个KV store，现在开始转向跟G丢出来的rocksdb（原名levelDB），C++派
大概不愿意用HBase |
|
p*****2
发帖数: 21240 | 6 靠。HBase快把我搞死了。怪不得三驾马车里排行末位呢。一晚上没整work。 |
|
z*******3
发帖数: 13709 | 7 正常，哈哈
这是trade off
让你用couchbase的话，估计你不爽在后面
hbase好歹免费的文档多 |
|
|
c********l
发帖数: 8138 | 9 好像根本就是不一样的东西，
HBase侧重于大数据的存储
Cassandra侧重于query/analysis
如果说得不对请轻拍 |
|
p*****2
发帖数: 21240 | 10 希望这样 准备上cassandra可了 HBase 比Java还无聊 |
|
z****e
发帖数: 54598 | 11 你是对的
hbase更像传统的data warehouse
而c*则更像是传统的db，甚至比db还要靠前
像cache |
|
p*****2
发帖数: 21240 | 12
MongoDB
没研究过这个。考虑过用couchbase替换redis。你研究一下过来给讲讲？
我看C*对各种语言支持都还不错。感觉Node.js和Clojure都有还可以的library，所以
估计上Java的可能性很小吧。如果上HBase的话倒是可能不用Node了。 |
|
z****e
发帖数: 54598 | 13 问题在于没有选择呀
用hadoop的还能选啥？
除了hbase的话
总不能说不用hadoop吧
不过本来big data就没那么多人需要
这个泡沫是时候下来了 |
|
g*****g
发帖数: 34805 | 14 不同的东西。hbase基本上跟hadoop一起用，就是个offline得东西。cassandra就是个
online DB. 部分替代传统DB的。 |
|
p*****2
发帖数: 21240 | 15
hbase号称是hadoop的real time部分。 |
|
|
p*****2
发帖数: 21240 | 17 Node跟Cassandra配合不要太容易了
HBase用Clojure做都搞不定
看来CANE stack要流行了。 |
|
|
h*****4
发帖数: 4219 | 19 二爷也搞过hbase？能不能指点下迷津...现在搞的我很晕，debug很久也就研究出这些
信息... |
|
p*****2
发帖数: 21240 | 20 hbase就是这问题 一般人玩不转 所以不是大牛的话 最好敬而远之 |
|
|
|
|
p*****2
发帖数: 21240 | 24 开发app的话cassandra要比hbase简单10倍
Twitter
面。 |
|
a*f
发帖数: 1790 | 25 数据层现在都有SQL或者JPA接口，比如Apache Phoenix已经用JDBC封装了Hbase，不存
在很多差异。应用系统在数据层上面几乎都是一样的 |
|
z****e
发帖数: 54598 | 26 c*你可以tune成象hbase那样
但是一般不这么做，没有必要了
大多数时候，尤其是web环境下
eventually consistent足够了 |
|
a*f
发帖数: 1790 | 27 Supercell这些MMORPG游戏对realtime写入的consistency要求更高一些，可能这就是为
什么游戏类更偏爱HBase。另外，“HTablePool has no limit on pool size.”，这个
很牛，2Billion连接上限。 |
|
z****e
发帖数: 54598 | 28 游戏类的收费的项目多一些
所以对consistency的要求也略高
其实c*也可以做到就是了，不过选择hbase也不能说是错的
毕竟这就是设计用来这么做的，社交类的就对这个要求低点
游戏你可以问那个coltzhao |
|
p*****2
发帖数: 21240 | 29
service)
那肯定是比较熟了。hbase还是有些learning curve的。 |
|
a*f
发帖数: 1790 | 30 怎么验证客户端的用户session
服务器端是HBase + Java client + REST
客户端可以是Web或者Mobile用户
必须用OAuth/OID或者类似的方法吗？
服务器端必须要写管理用户session的代码吗？ |
|
t**r
发帖数: 3428 | 31 mongo,dynamo,cassandra,hbase 谁会是赢家，谁会落寞？ |
|
p*****2
发帖数: 21240 | 32 c*
hbase会输
mongo startup专用 |
|
h*******3
发帖数: 122 | 33 大牛说它比C*复杂多了,所以不好用
但hadoop的系统很多还是用hbase吧 |
|
z****e
发帖数: 54598 | 34 我一直在琢磨，到底谁在用hbase
上次有同学说是游戏公司用得多
我在想为什么，问了coltzhao，貌似没有太多信息 |
|
g*****g
发帖数: 34805 | 35 你去看看C* Summit上的speakers都是那些公司出来的，就知道是不是三流公司才用了。
苹果在用的最大的cluster有7万个结点，现有的开源方案没有其他DB可能做到。
NoSQL上也就Mongo还有一争，HBase差多了。 |
|
g*********9
发帖数: 1285 | 36 HBase code quality比hadoop差得不是一点半点，应该说比较烂，
那个major compaction说来就来，会整得你蛋痛，不缺银子的话，
上aerospike. |
|
g****v
发帖数: 971 | 37 大牛能不能讨论下cassandra， Hbase， MongoDB的对比 |
|
|
h*****a
发帖数: 1718 | 39 我们一直用HBase，好像还挺好的。不过我不太了解细节。 |
|
h*****a
发帖数: 1718 | 40 也许，我们有差不多3个人manage HBase. 不过这也是一个tradeoff吧，肯定有好的地
方。 |
|
g*********9
发帖数: 1285 | 41 HBASE就是一个字，烂。看看源代码就知道了，比HADOOP源代码差大了。 |
|
|
A*******e
发帖数: 2419 | 43 【 以下文字转载自 JobHunting 讨论区 】
发信人: AlphaCode (Alpha), 信区: JobHunting
标 题: 问个HBase的问题
发信站: BBS 未名空间站 (Sat Mar 14 03:58:42 2015, 美东)
如果row key既有字符串，又有数字，然后字符串按字符串排序，数字按数字排序，能
做到吗？
比如按字典排序会是这样：
abc:1
abc:10
abc:2
...
abc:9
但我希望做到这样：
abc:1
abc:2
...
abc:9
abc:10 |
|
A*******e
发帖数: 2419 | 44 谢谢解答。有些问题能否进一步澄清？
但是string转换成的byte[]和int转成的byte[]可以不一样，这样对数据排序不会有影
响吗？
比如0到10，按字符和按数字排序，结果不同。
但是对一个block里的连续数据一个个get，解码只需一次，因为后续都在cache里，对
吗？
这个问题其实是这样。要读一组排好序的row key K = {k0, k1, ..., kn}。可以scan
X = [k0, kn]，然后在客户端判断x是否属于K。也可以get k0, k1, k2, ..., kn。前
者可能多读了很多数据，后者单个操作比较慢。如何根据K.spread和K.size来决定策略
，要看实际情况？
还有一个新问题。HBase只能在客户端做aggregation？SQL是可以在服务器端完成count
/sum等。 |
|
f*******t
发帖数: 7549 | 45 Hbase里有，get时可以指定一个timestamp |
|
|
k****i
发帖数: 128 | 47 用的公司还是挺多的，其实系统间大致idea都是想通的。C*就是hbase的data model和
dynamo的consistency model |
|
k****i
发帖数: 128 | 48 hbase就是apache version of big table |
|
p*****2
发帖数: 21240 | 49
我们没用HBase，这东西太难用了。
其他组用的，说是read上百ms了，C＊我们基本就是1ms |
|
|
