h*******3
发帖数: 122 | 1 大牛说它比C*复杂多了,所以不好用
但hadoop的系统很多还是用hbase吧 |
p*****2
发帖数: 21240 | 2 hadoop用hdfs居多
【在 h*******3 的大作中提到】
: 大牛说它比C*复杂多了,所以不好用
: 但hadoop的系统很多还是用hbase吧
|
z****e
发帖数: 54598 | 3 我一直在琢磨，到底谁在用hbase
上次有同学说是游戏公司用得多
我在想为什么，问了coltzhao，貌似没有太多信息 |
p*****2
发帖数: 21240 | 4 我们以前用 是公司的标配
现在从标配上remove了
半海他们用 貌似主要是engineer对hbase熟悉就上了
facebook用的也挺多 fan神可以讲讲
不过感觉legacy原因居多 现在有spark了对hbase应该影响很大
大数据还不愿意compromise c的话 有点太理想化了 牺牲c追求a目前的技术水平下大概
已经算共识了
【在 z****e 的大作中提到】
: 我一直在琢磨，到底谁在用hbase
: 上次有同学说是游戏公司用得多
: 我在想为什么，问了coltzhao，貌似没有太多信息
|
m******e
发帖数: 201 | 5 造出c*的fb用，造出hadoop的yahoo也用
【在 z****e 的大作中提到】
: 我一直在琢磨，到底谁在用hbase
: 上次有同学说是游戏公司用得多
: 我在想为什么，问了coltzhao，貌似没有太多信息
|
g*****g
发帖数: 34805 | 6 你去看看C* Summit上的speakers都是那些公司出来的，就知道是不是三流公司才用了。
苹果在用的最大的cluster有7万个结点，现有的开源方案没有其他DB可能做到。
NoSQL上也就Mongo还有一争，HBase差多了。
【在 m******e 的大作中提到】
: 造出c*的fb用，造出hadoop的yahoo也用
|
a*f
发帖数: 1790 | 7 对开发应用系统的人员来说应该不是很关心后台的数据库平台把，不管用HBase，
MongoDB，Riak还是换成Spark，数据服务层下面如果加个adapter layer可以比较自由
转换数据库平台，上面应用代码几乎可以一模一样。hbase在consistency上面可能比c
更好一点，更适合mmorpg游戏类要求low latency的信息更新，spark可能更好。如果瓶
颈主要在硬件io，spark也快不了多少。 |
z****e
发帖数: 54598 | 8 c*的成功跟fb没啥关系
fb没有能力让c*成功
养不活这么好一个孩子
所以过继给了apache
在apache的呵护下，c*变废为宝
发光发热，成为炙手可热的新星
apache就是牛
【在 m******e 的大作中提到】
: 造出c*的fb用，造出hadoop的yahoo也用
|
a*f
发帖数: 1790 | 9 变成宝后还是没被生母领回去，说明还不够宝
【在 z****e 的大作中提到】
: c*的成功跟fb没啥关系
: fb没有能力让c*成功
: 养不活这么好一个孩子
: 所以过继给了apache
: 在apache的呵护下，c*变废为宝
: 发光发热，成为炙手可热的新星
: apache就是牛
|
z****e
发帖数: 54598 | 10 这种东西哪有可能领回去的道理
一旦交给了开源组织，never go back
要不然apache贡献的那些代码怎么算？
那才是大头
【在 a*f 的大作中提到】
: 变成宝后还是没被生母领回去，说明还不够宝
|
|
|
a*f
发帖数: 1790 | 11 有人在这里提过fb内部说c有其他的问题，具体也没说明
【在 z****e 的大作中提到】
: 这种东西哪有可能领回去的道理
: 一旦交给了开源组织，never go back
: 要不然apache贡献的那些代码怎么算？
: 那才是大头
|
z****e
发帖数: 54598 | 12 这还不好理解
当时fb搞不定呗
轮子哪里是个人就能造
所以说，很多人自以为牛逼，有造轮子的水平
其实不过是民科和行艺
【在 a*f 的大作中提到】
: 有人在这里提过fb内部说c有其他的问题，具体也没说明
|
c******o
发帖数: 1277 | 13 我刚问过， 我们内部现在新游戏都是统一stack
Unity/Node.js/mongodb
不过有抱怨node.js 内存管理不好，复杂逻辑没戏。 |
z****e
发帖数: 54598 | 14 那怎么办？
游戏复杂逻辑在app上
真正复杂逻辑应该在你们平台组吧？
一般app对于后台要求就是能转移出数据，把数据交给你们就完事了
【在 c******o 的大作中提到】
: 我刚问过， 我们内部现在新游戏都是统一stack
: Unity/Node.js/mongodb
: 不过有抱怨node.js 内存管理不好，复杂逻辑没戏。
|
c******o
发帖数: 1277 | 15 不知道，实在不行再分层吧？
不是我管，我也不清楚。
他们就说>1G heap会 crash
【在 z****e 的大作中提到】
: 那怎么办？
: 游戏复杂逻辑在app上
: 真正复杂逻辑应该在你们平台组吧？
: 一般app对于后台要求就是能转移出数据，把数据交给你们就完事了
|
p*****2
发帖数: 21240 | 16
我也碰到这情况了。没怎么研究，直接转scala了。当然一般的应用也不会用到这么大
内存的。
【在 c******o 的大作中提到】
: 不知道，实在不行再分层吧？
: 不是我管，我也不清楚。
: 他们就说>1G heap会 crash
|
z****e
发帖数: 54598 | 17 是网游吗？
就是一万人什么国战那种
那这种可能会复杂点
一般单机app，不会那么麻烦了
【在 c******o 的大作中提到】
: 不知道，实在不行再分层吧？
: 不是我管，我也不清楚。
: 他们就说>1G heap会 crash
|
a*f
发帖数: 1790 | 18 是这样的结构吗？
Unity-》XCode-》REST-》access_token(OAuth)-》Spring Security-》Java
Container-》MongoDB
【在 c******o 的大作中提到】
: 我刚问过， 我们内部现在新游戏都是统一stack
: Unity/Node.js/mongodb
: 不过有抱怨node.js 内存管理不好，复杂逻辑没戏。
|
z****e
发帖数: 54598 | 19 应该不是
他们应该每一层都有一个自己的persistence和cache
【在 a*f 的大作中提到】
: 是这样的结构吗？
: Unity-》XCode-》REST-》access_token(OAuth)-》Spring Security-》Java
: Container-》MongoDB
|
c******o
发帖数: 1277 | 20 no, simpler
Unity (only do xcode if really need native code) -> Restful API on Node.js -
> MongoDB
OAuth/Or anything API reated really not language specific.
【在 a*f 的大作中提到】
: 是这样的结构吗？
: Unity-》XCode-》REST-》access_token(OAuth)-》Spring Security-》Java
: Container-》MongoDB
|
|
|
a*f
发帖数: 1790 | 21 Node的REST API URL暴露给public吗？用openID做验证还是用spring security之类的
轮子？
-
【在 c******o 的大作中提到】
: no, simpler
: Unity (only do xcode if really need native code) -> Restful API on Node.js -
: > MongoDB
: OAuth/Or anything API reated really not language specific.
|
z****e
发帖数: 54598 | 22 oauth也就是一个md5加密的字符串，你自己做也没多麻烦
【在 a*f 的大作中提到】
: Node的REST API URL暴露给public吗？用openID做验证还是用spring security之类的
: 轮子？
:
: -
|
c******o
发帖数: 1277 | 23 Node js 有OAuth轮子。再说authentication可以有很多种，和语言没啥关系。 |
w**z
发帖数: 8232 | 24 fb 应该是 C＊ pre 0.6, 现在都2.1了，code base 改了好多， fb 的看法对现在的C
＊没有任何意义。
【在 a*f 的大作中提到】
: 有人在这里提过fb内部说c有其他的问题，具体也没说明
|
g*********9
发帖数: 1285 | 25 HBase code quality比hadoop差得不是一点半点，应该说比较烂，
那个major compaction说来就来，会整得你蛋痛，不缺银子的话，
上aerospike.
【在 h*******3 的大作中提到】
: 大牛说它比C*复杂多了,所以不好用
: 但hadoop的系统很多还是用hbase吧
|
