h*****u
发帖数: 204 | 1 Hadoop will run a lot of jobs by reading data from Hbase and writing data to
Hbase.
Suppose I have 100 nodes, there are two ways I can build my Hadoop/Hbase
cluster:
option1. 100 nodes hadoop & hbase cluster (1 big Hadoop&Hbase)
option2. Separate the Database(Hbase), then we have two clusters:
60 nodes Hadoop cluster and 40 nodes Hbase cluster (1 Hadoop + 1 Hbase)
which option is better? Why?
Thanks. |
|
z*******3
发帖数: 13709 | 2 我一直都认为c*和mongodb这些，不是一个层面的，跟hbase
hbase是非用不可，除非你不用hadoop
但是在这个之前，有无数种方式予以优化，c*只是其中一种
这个内森那篇文章介绍storm时候说得很好啊
他用了三个persistence
分别是c*，hbase和他自己写的elephonedb
其实把这里elephonedb换成postgresql也一样用
你们才用一个数据库或者nosql的产品吗？
我现在就用了三个了，hbase虽然也用，但是主要时间不是在hbase上
而是在c*这些更靠近前端的缓冲库上，还有db |
|
J****R
发帖数: 373 | 3 二爷说的是对的，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......... |
|
c*****a
发帖数: 1638 | 4 用了一段hadoop，还没开始做nosql的数据库这块（现在还只是mapreduce），看了一些
书，下面是我的基本理解，不知道对不对。
根据他们的具体实现，以下只是对于C×和hbase的相对性能比较，大家不用讨论绝对性
能：
C×在写的时候没有提供全局的一致性，所以写并发很高。但是作为补偿，必须在读的
时候进行一致性校验，这个会造成读的性能相对下降？
HBase写的时候保证了全局的一致性，在读的时候不需要额外校验，所以hbase相对于C
×在写的性能较低，但是读上面性能较高？
另外C*的sharding是推荐random的，所以相对不适合range范围？我不知道这里是不是
理解错了，如果不合适range的话，岂不是在做data warehouse的时候性能有问题？我
一直以为C*更常见用于数据仓库，还是我错了？
Hbase的partition有序的，所以相对更适合range范围？但是这个更容易带来更多的数
据sharding导致availability下降？ |
|
h*****4
发帖数: 4219 | 5 在本地有三个project，A 和C 都是maven dependent on B， 在B里有关于连接HBase读
写操作的API。他们用的是同样的hbase-site.xml，hdfs-site.xml和core-site.xml，
但现在B和C都可以成功连接并读写而A不行。A里面返回NoServerForRegionException.
查了他们的config，在HBaseConfiguration.create时B是有yarn-default.xml和yarn-
site.xml而A没有，还没有测试C里面有没有...
请问版上大牛们，这个yarn跟HBase的连接有关吗？再一个怀疑点时hbase-env.sh需要
放在test/resources里面吗？在B里面放着不过A和C应该都没放。 谢谢指点 |
|
h*****a
发帖数: 1718 | 6 我们最早也没有用Hbase，都是mysql。用Hbase我猜一个原因是我们有几个人对
zookeeper和Hbase比较熟。现在Hbase所有的东西（cluster，软件，wrapper service)
也就是差不多3个人在弄，更早的时候就是一个人。 |
|
f*******t
发帖数: 7549 | 7 1.row key是byte[]，不管你里面想写什么，最终都要转成它。
2.可以，scan.setStartRow(),scan.setStopRow()
3.hbase以及所有BigTable衍生数据库性能最差的操作是random get，二分查找一个
keyvalue复杂度是O(logN)。数据大了hbase的block cache效率还是不够高。实际应用
中请尽量多使用scan，避免random get，实在不行可能得上memcache和其它优化。另外
hbase会对邻近的数据编码以节省存储空间，random get在读取每个keyvalue的时候都
要解码整个block，性能损失很大。
4和5是同一个问题。每个client的htable.multiput会把不同region的数据分开提交给
对应的服务器。这样如果有多个client，各服务器的负载更平均，对hbase cluster的
整体性能肯定有帮助。
6.你想问的是分成很多个小段的scan吗？scan的时候server会对每个client生成
scanner object，读取的时候互相之间可能有lock contenti... 阅读全帖 |
|
w***g
发帖数: 5958 | 8 请贴benchmark结果。感觉C*是强在scalability。机器多了以后HBase的
头节点会成为瓶颈，C*没这个问题。还有就是HBase中间夹了一层HDFS，
比如冗余机制就是靠HDFS实现的。比如C*要写两个copy，客户端直接
定位两台机器，写果去就完了。HBase要写两个copy，其实在到region
server之前都是1个copy，然后写入HDFS的时候才变成两个。中间多隔
一台机器，还会牵扯到Hadoop的namenode。
如果你的app就那么点数据，其实应该和MySQL比，应该比C*和Hbase都强。 |
|
b******A
发帖数: 4967 | 9 请问一下各位大神，有木有办法可以通过一次indexing两个HBase table
目前我的morphline-hbase-mapper.xml长这个样子，这个需要怎么改额，任何建议都非
常感谢！
$ vim morphline-hbase-mapper.xml
阅读全帖 |
|
z*******3
发帖数: 13709 | 10 主要是hadoop用了hbase吧
一开始fb用mysql，然后自己发明了c*，最后发现周围公司都在hadoop
于是就换到hbase去了
把c*贡献给了apache，apache把c*改造成了一个ap system
就非常适合搞缓存这种了，如果cp system，当然上来就是hbase了
这也没啥好考虑的 |
|
z*******3
发帖数: 13709 | 11 主要是hadoop用了hbase吧
一开始fb用mysql，然后自己发明了c*，最后发现周围公司都在hadoop
于是就换到hbase去了
把c*贡献给了apache，apache把c*改造成了一个ap system
就非常适合搞缓存这种了，如果cp system，当然上来就是hbase了
这也没啥好考虑的 |
|
a*f
发帖数: 1790 | 12 fb不是因为c*的实时数据durability有很多问题最后改成hbase了吗。现在fb, Twitter
, Yahoo, 游戏Supercell, Machine Zone等都主要在用hbase，应该是如日中天不算过
时吧？
现在开发application不十分care后台用什么数据库吧，只要保证实时数据写入的一致
性和查询的低延迟。对开发人员来说更关心从接口取到数据后，怎么用到商业流程里面。
Spark看上去是和MR/YARN竞争的。Spark+HBase也是一种组合，这两个的生态环境可以
不冲突的。 |
|
a****r
发帖数: 87 | 13 我的理解是。HBase is based on HDFS. From HBase's perspective, the HFile only
need to store one copy. HDFS保存多分来实现data failure. 所以从hbase角度。是
strong consistent. |
|
z*******3
发帖数: 13709 | 14 hadoop mature了吗？
需要定义mature
在我看来整个nosql market都很不mature
如果mature的话，那很多东西就不用做了
hdfs也许还ok，但是hbase的market就一塌糊涂了
c*理论上是跟hbase有一定交集，而非file system，比如hdfs
而c*是ap系统，ap可以tune成cp，但是反过来，cp要想tune成ap
就困难异常，我怀疑能不能做到，从这一点上说
c*的设计有天然的优势，天然就是cp系统的超集
hadoop是先行者，就像当年的ejb一样
但是jvm世界里后来居上反嗜的大有人在，比如spring
我同样看好vert.x干掉akka，以及c*干掉hbase
实际上这两个已经隐隐约约有这种迹象了，需要的只是时间
到时候现在做得一切系统都会被legacy化，到时候维护都是问题
然后一堆startup靠着这些新兴简单的技术来参与市场竞争
历史总是会这样重复
them. |
|
J****R
发帖数: 373 | 15 本来我这benchmark做完，明显C*比Hbase强几条街。结果早晨跟别的组architect开会
，被各种挑刺，说他们的benchmark看到hbase的query 也就是miliseconds，不算慢。
希望我们跟他们一样用hbase, 拿出用C*就很难和其他组做integration 的大帽子，搞
得PM也不知道怎么办了。 |
|
A*******e
发帖数: 2419 | 16 【 以下文字转载自 Programming 讨论区 】
发信人: AlphaCode (Alpha), 信区: Programming
标 题: 大量读HBase的任务该加线程还是进程？
发信站: BBS 未名空间站 (Tue Jul 28 23:02:18 2015, 美东)
有一个任务，需要大量读HBase，处理后写到磁盘上。处理本身很简单。
现在是两个任务/进程，每个任务四个线程。想增加吞吐量，是应该加线程，还是加进
程？ |
|
f*******t
发帖数: 7549 | 17 选hbase能学到更多的东西，kafka毕竟结构简单多了。但hbase是昨日黄花，尽量学一
整套生态系统比较好（比如加上spark） |
|
p*****2
发帖数: 21240 | 18
多谢大牛。
我们现在用storm real time 得到kafka上的event。另外有的组把kafka上的event写到
了HBase里。你觉得我们直接query HBase如何？是不是要query一个range，这个好用吗
？效率如何？ |
|
n****1
发帖数: 1136 | 19 俺一直觉得logic layer与persistence layer之间严格分开的做法, 甚至放在不同的进
程里面, 这样overhead太大. 所以一直对PL/SQL procedure programming很有兴趣, 可
惜这样做会被Oracle vendor locking.
俺个人对MapReduce的理解就是分布式的PL/SQL procedure, mapper/reducer是把业务
逻辑植入到persistence layer里面以提高性能. 这也应该是Cassandra和Hbase之间的
主要区别. Cassandra基本就是个key-value storage with random partition, 而
Hbase则与mapreduce概念结合更密切, 甚至提供coprocessor用来实现传统数据库中的
trigger等功能. Coprocessor应该就是个long standing mapper/reducer吧.
大家觉得这种架构可行吗? |
|
n****1
发帖数: 1136 | 20 那Hbase coprocessor这个方案呢? 毕竟Hbase就是分布式的. |
|
z*******3
发帖数: 13709 | 21 不过不对啊
你们不是早就hadoop了么？
hadoop难道不是用hbase做persistence？
c*大多数时候我们是用来存一些非重要性数据
比如log这些，当典型的nosql用
主要目的是读写快，反正牺牲掉了短期的consistent
hbase更多的是一种db的替代
就是没有transaction就是了
只要你不update历史数据，都没啥问题 |
|
p*****2
发帖数: 21240 | 22
我是搞过一点，可是问题太多了，一个接一个不断，有那时间我都学了cassandra，项
目做好了。感觉hbase很java呀。
这个板上的hbase大牛是fan神。你问问他吧。 |
|
p*****2
发帖数: 21240 | 23 hbase的主要优势就是hadoop
spark支持很多db hbase只是其中一种
现在用cassandra的越来越多 |
|
z****e
发帖数: 54598 | 24 这种nosql就不需要jpa了，直接就可以取object出来了
hbase也许你写一个hello world没啥区别，但是nodes一多
hbase和cassandra的performance的区别应该还是很明显的 |
|
h*****a
发帖数: 1718 | 25 我们都是在HBase上面包上一层自己的storage service layer，目前来说application
engineers不需要关心HBase的细节。 |
|
p*****2
发帖数: 21240 | 26 我们以前用 是公司的标配
现在从标配上remove了
半海他们用 貌似主要是engineer对hbase熟悉就上了
facebook用的也挺多 fan神可以讲讲
不过感觉legacy原因居多 现在有spark了对hbase应该影响很大
大数据还不愿意compromise c的话 有点太理想化了 牺牲c追求a目前的技术水平下大概
已经算共识了 |
|
a*f
发帖数: 1790 | 27 对开发应用系统的人员来说应该不是很关心后台的数据库平台把，不管用HBase，
MongoDB，Riak还是换成Spark，数据服务层下面如果加个adapter layer可以比较自由
转换数据库平台，上面应用代码几乎可以一模一样。hbase在consistency上面可能比c
更好一点，更适合mmorpg游戏类要求low latency的信息更新，spark可能更好。如果瓶
颈主要在硬件io，spark也快不了多少。 |
|
t**r
发帖数: 3428 | 28 有懂bigtable ,hbase，c*的么？问一个timestamp的问题
bigtable里面timestamp的用法在hbase,c*里有么？
比如:by specifiying timestamp, I can get value of latest version that is
earlier than a specified timestamp. |
|
J****R
发帖数: 373 | 29 记得二爷推崇c*, 说过多次hbase已死。
最近做benchmark， 没感觉cassandra 比hbase好在哪里。相反，cassandra的cql
query限制非常多。
两个DB的performance 也区别不大。
有大牛能展开说说自己的看法吗？非常感谢！ |
|
w***g
发帖数: 5958 | 30 hdfs本来备用做hadoop的存储层，用来做大块文件读写。
如果每次从hdfs读写几百兆的块，最近几个版本的Hadoop性能是没啥问题的。
（早期也很屎，后来改进了。）
在hdfs上做HBase本来就是一个很傻B的设计, 本来也不是用来做实时应用的。
后来用的人多了，用的范围大了，
engineering投入进去，性能补救了一点上去而已。但别人C*很自然就能做到
的性能，在HBase上就成了challenge。 |
|
z****e
发帖数: 54598 | 31 脚本引擎肯定有各种限制
但是hbase连脚本引擎都不存在
你想想你自己实现一个hql会有多麻烦
cql虽然比不上sql，但是比起没有ql的hbase，那还是要强一点 |
|
g*****g
发帖数: 34805 | 32 C* 读写快，scale容易，维护容易，多数据中心支持，适合 online. Hbase主要好处是
支持 range query, 跟 hadoop整合好。我们完全用 s3 替代 Hbase. |
|
w**z
发帖数: 8232 | 33 不是很确定Hbase怎么做的，根据Google big table
应该是用 Memtable and LSM trees
Cassandra 里叫SSTable， 用 compaction 把SSTable compact起来。没有compact的就
在query 的时候merge
Hbase 应该同样的原理。 |
|
J****R
发帖数: 373 | 34 我也希望事情能简单一点，但是设计数据库的时候，有些底层的东西不得不考虑。之前
跟一些用C* 和Hbase的人求教过经验。基本上比较一致的结论就是目前为止compaction
不管在哪，都还是很头疼的一件事情，另一件事情就是schema design，这一点C*尤其
需要谨慎。
Hbase 里面minor compaction 就不提了。major compaction 中并不是所有的HFile都
会参与，尤其是当存储的是immutable data。当某个region 中 Hfile 被合并到region
maxsize上限，会trigger region split。这之后原来的region中可能就不会再写入数
据，因为row key可能不会再映射到这个region.
如果schema设计成了每隔一段时间就在每一行都加一个新的column，那么已经存储的所
有Hfile都会被涉及到，做compaction的时候，这些文件都需要merge甚至trigger
region split。存储的数据多了以后，这个代价就相当大了。 |
|
|
f*******t
发帖数: 7549 | 36 实际上rocksdb sucks，都不稳定。hbase相当稳定，很少crash |
|
r**o
发帖数: 430 | 37 明天要跟老板谈开始后的project，估计应该是做Hbase或者Kafka(或者有可能是spark
，看cover的范围)，请问应该选哪个比较好些呢？多谢哈。 |
|
|
s*****r
发帖数: 43070 | 39 显然卡夫卡啊，hbase是什么东东
spark |
|
r**o
发帖数: 430 | 40 能不能细说下hbase为甚是昨日黄花了？kafka涉及的东西少很多啊，spark的话好些从
系统角度考虑没什么东西。 |
|
D***n
发帖数: 149 | 41 请问这个方向的工作好找吗？ 小弟平时用Hadoop,HBase写一些mapreduce,,然后做
一些data mining和analytics,对cloud infrastructure有一定的了解...
求大牛推荐机会.... lol |
|
m******t
发帖数: 635 | 42 是不是可以有个二爷定律：
凡是二爷都觉得难用的，都是真的难用和没有前途的。
目前待验证的列表：
Scala, HBase
haha |
|
f*******t
发帖数: 7549 | 43 mongodb占50%市场份额。
hbase各种配置学习成本挺高的，不过我觉得谈不上难用。 |
|
p*****2
发帖数: 21240 | 44
我只是reader。我怀疑我们公司可能没能力maintain HBASE。 |
|
y***y
发帖数: 295 | 45 【 以下文字转载自 Java 讨论区 】
发信人: ylyly (转回原点), 信区: Java
标 题: 这里有人玩hadoop/hbase么？
发信站: BBS 未名空间站 (Fri Sep 12 19:56:28 2008)
赫赫
交流一下 |
|
|
p*****w
发帖数: 429 | 47 我不知道hbase里面叫什么,就是mysql里面要有slaves. 你们一份数据有多少复制?假设
你们肯定也是网站应用. |
|
f*******t
发帖数: 7549 | 48 我们有三种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 | 49 他们本身有一个KV store，现在开始转向跟G丢出来的rocksdb（原名levelDB），C++派
大概不愿意用HBase |
|
p*****2
发帖数: 21240 | 50 靠。HBase快把我搞死了。怪不得三驾马车里排行末位呢。一晚上没整work。 |
|
