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吧
|