a*f
发帖数: 1790 | 1 像Coc这样的游戏每次发送同步数据的时候后台是直接从Pool里面写Table数据还是通过
DataNucleus之类的走JPA写数据？ |
a*f
发帖数: 1790 | |
p*****2
发帖数: 21240 | 3 这个技术本版已经过时了吧
【在 a*f 的大作中提到】
: Hbase大牛们请指指路哈
|
y**********u
发帖数: 6366 | 4 hbase很好啊，听说Pin就用这个啊
【在 p*****2 的大作中提到】
: 这个技术本版已经过时了吧
|
p*****2
发帖数: 21240 | 5 spark火了hbase就差多了
【在 y**********u 的大作中提到】
: hbase很好啊，听说Pin就用这个啊
|
f*******t
发帖数: 7549 | 6 这俩不是一类东西啊
【在 p*****2 的大作中提到】
: spark火了hbase就差多了
|
z****e
发帖数: 54598 | 7 没有人觉得cp系统位置有些尴尬？
不如ap系统那么灵活，可以自由地tune
也不如ac系统那么严谨，提供各种transaction等非常critical功能
上不上，下不下，我反正感觉我用cp系统的次数是越来越少了
应该说本来就用得不多 |
a*f
发帖数: 1790 | 8 一句话就说清楚了。大牛们都只用后台的MR做数据分析，没人开发前端的application？
【在 p*****2 的大作中提到】
: 这个技术本版已经过时了吧
|
p*****2
发帖数: 21240 | 9 hbase的主要优势就是hadoop
spark支持很多db hbase只是其中一种
现在用cassandra的越来越多
【在 f*******t 的大作中提到】
: 这俩不是一类东西啊
|
p*****2
发帖数: 21240 | 10 我们用cassandra
application？
【在 a*f 的大作中提到】
: 一句话就说清楚了。大牛们都只用后台的MR做数据分析，没人开发前端的application？
|
|
|
a*f
发帖数: 1790 | 11 fb不是因为c*的实时数据durability有很多问题最后改成hbase了吗。现在fb, Twitter
, Yahoo, 游戏Supercell, Machine Zone等都主要在用hbase，应该是如日中天不算过
时吧？
现在开发application不十分care后台用什么数据库吧，只要保证实时数据写入的一致
性和查询的低延迟。对开发人员来说更关心从接口取到数据后，怎么用到商业流程里面。
Spark看上去是和MR/YARN竞争的。Spark+HBase也是一种组合，这两个的生态环境可以
不冲突的。
【在 p*****2 的大作中提到】
: 我们用cassandra
:
: application？
|
p*****2
发帖数: 21240 | 12 开发app的话cassandra要比hbase简单10倍
Twitter
面。
【在 a*f 的大作中提到】
: fb不是因为c*的实时数据durability有很多问题最后改成hbase了吗。现在fb, Twitter
: , Yahoo, 游戏Supercell, Machine Zone等都主要在用hbase，应该是如日中天不算过
: 时吧？
: 现在开发application不十分care后台用什么数据库吧，只要保证实时数据写入的一致
: 性和查询的低延迟。对开发人员来说更关心从接口取到数据后，怎么用到商业流程里面。
: Spark看上去是和MR/YARN竞争的。Spark+HBase也是一种组合，这两个的生态环境可以
: 不冲突的。
|
a*f
发帖数: 1790 | 13 数据层现在都有SQL或者JPA接口，比如Apache Phoenix已经用JDBC封装了Hbase，不存
在很多差异。应用系统在数据层上面几乎都是一样的
【在 p*****2 的大作中提到】
: 开发app的话cassandra要比hbase简单10倍
:
: Twitter
: 面。
|
p*****2
发帖数: 21240 | 14 架构太复杂了
我们没人搭架构 全靠自己
另外phoenix只支持java吧？我们node用的很多。 cassandra多语言支持很好。
【在 a*f 的大作中提到】
: 数据层现在都有SQL或者JPA接口，比如Apache Phoenix已经用JDBC封装了Hbase，不存
: 在很多差异。应用系统在数据层上面几乎都是一样的
|
z****e
发帖数: 54598 | 15 这种nosql就不需要jpa了，直接就可以取object出来了
hbase也许你写一个hello world没啥区别，但是nodes一多
hbase和cassandra的performance的区别应该还是很明显的
【在 a*f 的大作中提到】
: 数据层现在都有SQL或者JPA接口，比如Apache Phoenix已经用JDBC封装了Hbase，不存
: 在很多差异。应用系统在数据层上面几乎都是一样的
|
a*f
发帖数: 1790 | 16 嗯，就是想知道这样的答案，直接从pool里面读写table。
【在 z****e 的大作中提到】
: 这种nosql就不需要jpa了，直接就可以取object出来了
: hbase也许你写一个hello world没啥区别，但是nodes一多
: hbase和cassandra的performance的区别应该还是很明显的
|
z****e
发帖数: 54598 | 17 c*你可以tune成象hbase那样
但是一般不这么做，没有必要了
大多数时候，尤其是web环境下
eventually consistent足够了
【在 a*f 的大作中提到】
: 嗯，就是想知道这样的答案，直接从pool里面读写table。
|
a*f
发帖数: 1790 | 18 Supercell这些MMORPG游戏对realtime写入的consistency要求更高一些，可能这就是为
什么游戏类更偏爱HBase。另外，“HTablePool has no limit on pool size.”，这个
很牛，2Billion连接上限。
【在 z****e 的大作中提到】
: c*你可以tune成象hbase那样
: 但是一般不这么做，没有必要了
: 大多数时候，尤其是web环境下
: eventually consistent足够了
|
z****e
发帖数: 54598 | 19 游戏类的收费的项目多一些
所以对consistency的要求也略高
其实c*也可以做到就是了，不过选择hbase也不能说是错的
毕竟这就是设计用来这么做的，社交类的就对这个要求低点
游戏你可以问那个coltzhao
【在 a*f 的大作中提到】
: Supercell这些MMORPG游戏对realtime写入的consistency要求更高一些，可能这就是为
: 什么游戏类更偏爱HBase。另外，“HTablePool has no limit on pool size.”，这个
: 很牛，2Billion连接上限。
|
p*****2
发帖数: 21240 | 20
他们用的mongo吧。
【在 z****e 的大作中提到】
: 游戏类的收费的项目多一些
: 所以对consistency的要求也略高
: 其实c*也可以做到就是了，不过选择hbase也不能说是错的
: 毕竟这就是设计用来这么做的，社交类的就对这个要求低点
: 游戏你可以问那个coltzhao
|
|
|
c******o
发帖数: 1277 | 21 mongodb就是cp啊。。
scale的代价是比较大，devops也复杂。
【在 z****e 的大作中提到】
: 没有人觉得cp系统位置有些尴尬？
: 不如ap系统那么灵活，可以自由地tune
: 也不如ac系统那么严谨，提供各种transaction等非常critical功能
: 上不上，下不下，我反正感觉我用cp系统的次数是越来越少了
: 应该说本来就用得不多
|
c******o
发帖数: 1277 | 22 其实现在觉得，要是你不怕学东西，mongodb ＋ cassandra + mysql都用是最好的。
mongodb 做一般储存，cassandra 做log＋BI, mysql 做payment和强transaction/
relation的data |
g*****g
发帖数: 34805 | 23 Whatever you want to put in MongoDB, you can probably split between
Cassandra and MySQL. It can be a little bit more coding, but you gain
scalability (if in Cassandra), easy maintenance (compared to Mongo), strong
tooling (if in mysql). Add Elastic Search you are set.
I can't think of a strong case where MongoDB is a must. It feels like a half
-hearted solution. Iterate fast while scale reasonably well. It may be a
good thing for startup as a drop-in replacement of MySQL but it may come
back and bite you hard. A clear split between Cassandra and MySQL force you
to think about your data's characteristics first.
【在 c******o 的大作中提到】
: 其实现在觉得，要是你不怕学东西，mongodb ＋ cassandra + mysql都用是最好的。
: mongodb 做一般储存，cassandra 做log＋BI, mysql 做payment和强transaction/
: relation的data
|
c******o
发帖数: 1277 | 24 Document db in json format has its wonderful things. It can be replaceable,
but everything is replaceable.
You are right about elastic search, yes, a search engine is needed in most
companies, solr also can be useful here.
strong
half
you
【在 g*****g 的大作中提到】
: Whatever you want to put in MongoDB, you can probably split between
: Cassandra and MySQL. It can be a little bit more coding, but you gain
: scalability (if in Cassandra), easy maintenance (compared to Mongo), strong
: tooling (if in mysql). Add Elastic Search you are set.
: I can't think of a strong case where MongoDB is a must. It feels like a half
: -hearted solution. Iterate fast while scale reasonably well. It may be a
: good thing for startup as a drop-in replacement of MySQL but it may come
: back and bite you hard. A clear split between Cassandra and MySQL force you
: to think about your data's characteristics first.
|
g*****g
发帖数: 34805 | 25 Well, when scalability issue hits, it hits hard and drives you off the cliff
. Easy of use in Mongo is nice, but that's a much simpler problem to solve.
If you are using Mongo as the only store, it makes sense. If you are already
using Cassandra + MySQL for other things, I don't see why you need Mongo as
well.
,
【在 c******o 的大作中提到】
: Document db in json format has its wonderful things. It can be replaceable,
: but everything is replaceable.
: You are right about elastic search, yes, a search engine is needed in most
: companies, solr also can be useful here.
:
: strong
: half
: you
|
c******o
发帖数: 1277 | 26 we are now in fact looking into request volume increased to 15-20 times
higher at end of year (to several M per minute), basically, just more shards
(3 -> 6 or even more), better machines (i2 series if needed).
Which all not easy, but can still be done without downtime at all on mongodb
, I am in fact pretty amazed by mongodb.
cliff
.
already
as
【在 g*****g 的大作中提到】
: Well, when scalability issue hits, it hits hard and drives you off the cliff
: . Easy of use in Mongo is nice, but that's a much simpler problem to solve.
: If you are using Mongo as the only store, it makes sense. If you are already
: using Cassandra + MySQL for other things, I don't see why you need Mongo as
: well.
:
: ,
|
h*****a
发帖数: 1718 | 27 我们都是在HBase上面包上一层自己的storage service layer，目前来说application
engineers不需要关心HBase的细节。
【在 p*****2 的大作中提到】
: 开发app的话cassandra要比hbase简单10倍
:
: Twitter
: 面。
|
p*****2
发帖数: 21240 | 28
application
对呀。这个就是P的规模起来了。如果像当初几个人的时候就没法这么搞了。我们的情
况恰恰就是几个人做事情的时候。
【在 h*****a 的大作中提到】
: 我们都是在HBase上面包上一层自己的storage service layer，目前来说application
: engineers不需要关心HBase的细节。
|
h*****a
发帖数: 1718 | 29 我们最早也没有用Hbase，都是mysql。用Hbase我猜一个原因是我们有几个人对
zookeeper和Hbase比较熟。现在Hbase所有的东西（cluster，软件，wrapper service)
也就是差不多3个人在弄，更早的时候就是一个人。
【在 p*****2 的大作中提到】
:
: application
: 对呀。这个就是P的规模起来了。如果像当初几个人的时候就没法这么搞了。我们的情
: 况恰恰就是几个人做事情的时候。
|
p*****2
发帖数: 21240 | 30
service)
那肯定是比较熟了。hbase还是有些learning curve的。
【在 h*****a 的大作中提到】
: 我们最早也没有用Hbase，都是mysql。用Hbase我猜一个原因是我们有几个人对
: zookeeper和Hbase比较熟。现在Hbase所有的东西（cluster，软件，wrapper service)
: 也就是差不多3个人在弄，更早的时候就是一个人。
|
|
|
h*****a
发帖数: 1718 | 31 很多人都是工作中学起来。有的东西上手有难度，但后面有些事情容易些，有些相反。
【在 p*****2 的大作中提到】
:
: service)
: 那肯定是比较熟了。hbase还是有些learning curve的。
|
p*****2
发帖数: 21240 | 32
确实。有些时候需要赶紧上，就选容易的。成功了就可以慢慢搞。
【在 h*****a 的大作中提到】
: 很多人都是工作中学起来。有的东西上手有难度，但后面有些事情容易些，有些相反。
|
a*f
发帖数: 1790 | 33 这个自己的storage service layer是简单的DAO layer，还是类似Apache Phoenix一样
的封装？当初不用开源库的出发点是什么？
application
【在 h*****a 的大作中提到】
: 我们都是在HBase上面包上一层自己的storage service layer，目前来说application
: engineers不需要关心HBase的细节。
|
p*****2
发帖数: 21240 | 34 可能在google做过类似的东西
【在 a*f 的大作中提到】
: 这个自己的storage service layer是简单的DAO layer，还是类似Apache Phoenix一样
: 的封装？当初不用开源库的出发点是什么？
:
: application
|
h*****a
发帖数: 1718 | 35 是针对P的application的特点进行的封装，加入了新的feature。比如Zen, http://qconsf.com/presentation/zen-pinterests-graph-storage-service. 这样可以让application developers 不需要直接和存储layer打交道，实现feature更方便。
【在 a*f 的大作中提到】
: 这个自己的storage service layer是简单的DAO layer，还是类似Apache Phoenix一样
: 的封装？当初不用开源库的出发点是什么？
:
: application
|
p*****2
发帖数: 21240 | 36
这个不错。有没有相关资料可以看看呢，现在。
【在 h*****a 的大作中提到】
: 是针对P的application的特点进行的封装，加入了新的feature。比如Zen, http://qconsf.com/presentation/zen-pinterests-graph-storage-service. 这样可以让application developers 不需要直接和存储layer打交道，实现feature更方便。
|
h*****a
发帖数: 1718 | 37 好像还没有。
【在 p*****2 的大作中提到】
:
: 这个不错。有没有相关资料可以看看呢，现在。
|
