p*****2
发帖数: 21240 | 1
刚才随便看了一下怎么发现cassandra好像不怎么乐观呀。说Facebook自己用的也不多
，Twitter也停用了。 |
|
r*******k
发帖数: 44 | 2
hbase 没有spof, for sure.
从那里听说的？你是说facebook 的系统不scalable?
this is by design, to guarantee strong consistency. HBase chooses CP of CAP
and cassandra chooses AP of CAP. It's their design choices.
cassandra's gossip protocol sounds ideal, but the real throughput would be a
big issue. That's why FB dropped cassandra and adopted hbase in their
production systems.
不明白，有不支持adhoc query 的nosql ? 你说的是secondary indexing?
distributed indexing for large scale distributed DB is not that easy.
cassandra was st... 阅读全帖 |
|
r*******k
发帖数: 44 | 3 I heard from a conference keynote speak given by a fb engineer that facebook
is not using cassandra for ANY of their product. all about mysql, memcache
and hbase now.
twitter used to try out cassandra in 2010, but failed (just like digg). now
they're using redis + mysql for their tweets, and investigating hbase now (
told by their engineering director) |
|
|
|
p*****2
发帖数: 21240 | 6
facebook
memcache
now
多谢大牛。 |
|
t*******e
发帖数: 684 | 7 Brisk， Hadoop on CFS，不过不是apache搞的。Besides, Cassandra can work
natively as a hadoop data source or sink.
：现在apache已经开始整合cassandra跟hadoop了
没有的事儿。怎么整合？cassandra on hdfs? mapred optimization on cassandra?
凑合粘乎一下还行，整合就不可能了。 |
|
t*******e
发帖数: 684 | 8
NameNode is SPOF.
Cassandra is more efficiency with respect to scalability。
CAP
Cassandra allows you to trade between consistency and availability.
Consistency level can be tuned per each read/write operation.
a
Key value store, column family-based NoSQL falls short on ad hoc query
capability. |
|
t*******e
发帖数: 684 | 9 To developers, Mongodb acts much like a relational db. Column family dbs are
different animals. Coding with column family is obviously more involving. |
|
t*******e
发帖数: 684 | 10 我自己没实际比较过hbase cassandra。不过google一下最近的评价，很多从hbase转
cassandra的。
goodbug 在用cassandra，能不能给讲讲最不满意的地方。 |
|
t*******e
发帖数: 684 | 11 淘宝的马工对my sql cluster不满意，还抓了几个bugs。 |
|
|
w**z
发帖数: 8232 | 13 we use Cassandra in production. No big complain, except for some operational
stuff, like repair and compaction which slows down the system a bit. there
are some big installations such as netflix, ebay, spotify, ooyala. To
compare nosql solution, do some homework, and understand your use case, HA
, latency requirement, do benchmark. ...
hard to say which one is better than another. |
|
t*******e
发帖数: 684 | 14 NOSQL不是relational有个SQL93，没有规范，每个都完全不同。都试一遍，几年时间就
过去了。而且简单的use case很多时候不能说明问题。不可能都亲自尝试的情况下，先
看看别人的经验就能避免走弯路。简单的而言key value stores一般不支持ad hoc
query，document dbs基本都支持，如果use case必须要支持，那就从document db中选
。又如你要有multi-row transaction, 大部分NOSQL都不支持。 |
|
p*****2
发帖数: 21240 | 15
operational
there
HA
大牛说说ooyala这个公司到底咋样呀？ |
|
|
r*******k
发帖数: 44 | 17 我估计您只读过一些过时blog, 网文之类，没有hands on experience. （sorry,
really not nice）
NameNode HA 在2012年中已经比较成熟，我知道的多数公司2012年底已经upgrade
their production systems to use Namenode HA. 如果你听说过spof of NN，那是
2013年前的事情了，以后千万别提了。
这个领域的特点，所有的事情的都在moving around。如果你不肯定，请不要乱说。
这里不适合讨论cassandra hbase 实现细节一类，理论上的东西和实际差远了，看似美
好的东西实际实现两码事，你需要做很多的妥协来实现这些美好的目标，而cassandra
需要妥协的地方的太多了。不要以为fb, twitter ，还有其他一些公司drop cassandra
是没有strong reason的。再踢一次，cassandra 是fb 最早开发的，现在他们已经退
出很久了。
关于mapred on CFS，that's my point, 只是粘合: cassandra imp... 阅读全帖 |
|
t*******e
发帖数: 684 | 18 你正在做hbase, 自然是知道多。NN是SPOF，直到2012年间还是事实，变成是我乱说的
，不是update-to-date knowledge是另外一回事。理论上cassandra的确比hbase美好，
同意实际上可能不是一回事。
论坛本来就是让大家讨论的，没有人能保证自己什么都正确，包括你在内。建议你也把
基础打打好，先搞懂什么是ad hoc query。
cassandra
cassandra |
|
z****e
发帖数: 54598 | 19 经验论一般说不超过2.0都不算稳定
write throughput的原因给zkss？
最后一个我看cassandra已经被列为hadoop的关联项目
排在hbase之前，现在还不算很快，但是逐步会被优化
只是凑合黏糊一下就好了，就怕整合太彻底，以后想拆开都难
hbase其实就很难搞，如果不用hadoop的话 |
|
z****e
发帖数: 54598 | 20 说明不稳定
这块新发展出来的，各种产品都有其不如意的地方 |
|
z****e
发帖数: 54598 | 21 hbase貌似是waterloo那群人在牵头搞？
cassandra
cassandra |
|
p*****2
发帖数: 21240 | 22
ad hoc query到底啥意思呀？刚才看到自己想了一下没想清楚 |
|
t*******e
发帖数: 684 | 23 简单地说就是支持随意的general purpose query。现实OLTP一般都要求。column
family NOSQL则是query driven schema design。先把query想好了，再设计column
families, 特别是rowkey。本质上column family db只能search by rowkey，full
table scan太慢。cassandra 0.7开始支持native secondary index, 尽管还有局限，
添加ad hoc query based on column values就比较容易了。Hbase最新版不知道，（有
人说我 乱说了，放个disclaimer），老板的一般通过coprocessor做，估计是在client
side生 成。总之两者都不如mongodb，relational的方便。 |
|
r*******k
发帖数: 44 | 24 我现在不做hbase，只是恰巧在big data 和open source 领域，因为我们的项目有这些
需求，所以任何项目都会涉及一点。
兄弟，我真要吐血了。(我对你没有个人意见，我也不知你是谁，如果之前说话不太
nice 请见谅。)
big data 领域，我们一般提 ad-hoc query 时，与知相对的是所谓的 batch
processing。batch processing 一般指run mapreduce job 或其他job比如scan 一个
巨大的文件，无论一个小时还是一晚上得到结果, doesn't matter. ad-hoc 相对的，
指随机的查询，很快的得到结果(<1sec)，比如query user data by user id. 对于单
机DB小数据来说，这根本不是问题，但对于distributed file system, 我们需要相应
的技术来实现这种需求，所以才有bigtable 以及后来者。举个例子，在100TB数据中找
到一个user id，极相应记录，只有nosql 可以在1秒内办到。
given a key, to get the valu... 阅读全帖 |
|
r*******k
发帖数: 44 | 25 不会。即便现在spring/hibernate也不是必备的。 :)
说说我的观察：
现在 hadoop/big data 的确很热：我前两天随便看了一下一些hot公司招聘信息，比如
box.net, dropbox, square, twitter, pinterest, 都有hadoop positions, 方向也很
多。
但从另一个角度，这方面有经验的人很少，我们去年面试了n多hadoop engineer
candidates, (还有一个twitter的)没一个合适的，最后还是花大价钱挖熟人添坑，现
在还有2个没fill。
原因之一是之前大家采取观望的居多，导致有 hands on experience的人少，比如
dropbox 要找他们 first hadoop engineer，你早干嘛去了？
这个技术应用的范围来看，主力当然是web company，传统enterprise 厂商也不少，比
如emc, intel, 还有一大票专业公司。 |
|
g*****g
发帖数: 34805 | 26 The main beef is that you need to create your own index and maintain it for
everything. Secondary index has performance issue and it's not recommended.
And you really really have to plan your query, while you can change your
schema without downtime, it also means every time you change your mind, you
have to migrate your data.
On the pro side, a peer to peer structure is really made for cloud. The
built-in multi-DC capability is very useful. |
|
t*******e
发帖数: 684 | 27
"given a key, to get the value(s), 本身就是最典型的ad-hoc query. 是每个nosql
最基本的功能，否则要他做什么？distributed file system 就可以了。你说nosql
not support ad-hoc query, 任何相关领域的人都得和你急。"
如果你这么认识ad hoc query，我也无语了。另外你举的Digg的例子，没见人说是
cassandra failed the project，都说是inadequate test导致的。我没用过HBase, 但
google hbase vs cassandra 出来的结果和你说差别很大。不相信可以自己试试，不要
说这些人也都不如你hands on。
我现在在evalute NoSQL databases，决定前就想多看点，避免一面之词。 |
|
z****e
发帖数: 54598 | 28 现在这块还没怎么稳定下来，还有大量生手的机会
时间一久，各种问题都搞定了，产品也就成熟了，到时候就不会有太多生手的机会了
任何一个领域都是这样
你现在去做传统的挨踢，至少spring是必备的，不会spring可不行
web公司因为在拓展领域，所以生手和熟手差距不大，但是差距会逐步拉大 |
|
t*******e
发帖数: 684 | 29 Is there a dedicated DBA team to manage the production environment, or
developers play dual roles?
for
you |
|
w**z
发帖数: 8232 | 30 depends on the company. we have Tech Op team, but I did all the
installation, implementation, monitoring , maintenance for our first
cluster. It was pretty fun. If your Tech op team doesn't have much
experience on Cassandra , you better know how to do it yourself. Eventually
, they will ask you to fix the problems. |
|
g*****g
发帖数: 34805 | 31 We have a small Cassandra ops team doing backup, version upgrade etc. But we
have several hundred clusters. We also have a small cloud DB team, with a
couple of DBA giving consultation on all kinds of cloud db option. But it's
mostly on your own. |
|
t*******e
发帖数: 684 | 32 两位如果不介意的话，能介绍一下use cases, cassandra当OLTP用，还是OLAP，或
batch data processing? |
|
w**z
发帖数: 8232 | 33 We use Cassandra to store friends, persistent notifications and newsfeed.
You can't really call it OLTP since it doesn't have transaction.
We don't do analytical processing (yet), you can set up a cluster just for
data analyze. The integration with Hadoop is not great, but it works for
someone.
You can subscribe to the cassandra user group, u**[email protected]
and you can also join IRC channel: #cassandra channel on irc.freenode.net.
People there are really helpful.
And Datastax is a great... 阅读全帖 |
|
t*******e
发帖数: 684 | 34 Thanks for sharing. "cassandra integration with hadoop is not great." Is it
due to the lack of data locality? |
|
w**z
发帖数: 8232 | 35 You can buy Datastax enterprise version and it comes with Hadoop and solr
integration. We haven't tried yet since we run hadoop off scribe log data.
Cassandra doesn't use HDFS as its file system, so you will have to transfer
data in/our of Cassandra. I am not expert on Hadoop, so don't want to give
you wrong information. But as I know, the biggest advantage of HBase is that
Hbase runs on on HDFS, so Hadoop integration is much easier.
it |
|
t*******e
发帖数: 684 | 36 thrift是为bigdata开发的RPC，没有scalability的要求不需要用。 |
|
M***r
发帖数: 79 | 37 公司中等规模位于南湾Santa Clara. 主要有Analytics和Recommendation两个teams.
平台主要有Hadoop, Spark, Kafka. 编程语言主要是Scala, 不过不是必须的. 会Java
或Ruby都可以. 是个学习大收据的好机会. 如有兴趣，请把Resume发给我.
补充一下：这是个Engineer职位，不是Data Scientist。最好有公司经验(junior or
senior)。有经验会优先考虑。谢谢大家的简历。我就不逐个回复了。
Email: [email protected]/* */ |
|
q********y
发帖数: 162 | 38 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也
就是事实上跟os绑定了。而且作为公司来说，也不在意这种os绑定,又不是终端消费者
，变来变去的。
对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊？
对客户的承诺 “compile once, run everywhere”主要是针对front end 和
Application
developper 的吧？ 作为backend infrastructure，就像你常说的，各个大公司都是定
制的，
什么“os绑定”，“compile once, run everywhere”应该没人在意吧？ |
|
mw
发帖数: 525 | 39 这里每天这个好哪个好，争论个没完
谁在gft里面做的，给说说，现在这些新锐的bigdata公司都是用什么语言？ |
|
x*j
发帖数: 271 | 40 有点无知者无畏了。我就是做SCOPE的。HIVE真心不行。SCOPE这一套不敢说性能第一，
秒杀HADOOP还是分分秒秒的事。易用性和可扩展性，用过的人应该都知道。现在的HIVE
PIG在扩展性上就是渣。写个UDF还要先DDL注册才能用都是什么年代的了。SCOPE里面
对C#的integration我真心在BIGDATA的世界里没有见过第二家。我不是吓吹牛用过的人
都知道。 |
|
x*j
发帖数: 271 | 41 有点无知者无畏了。我就是做SCOPE的。HIVE真心不行。SCOPE这一套不敢说性能第一，
秒杀HADOOP还是分分秒秒的事。易用性和可扩展性，用过的人应该都知道。现在的HIVE
PIG在扩展性上就是渣。写个UDF还要先DDL注册才能用都是什么年代的了。SCOPE里面
对C#的integration我真心在BIGDATA的世界里没有见过第二家。我不是吓吹牛用过的人
都知道。 |
|
z****e
发帖数: 54598 | 42 传统db就是设计得过份了
不给一般应用留活路，啥都要上最牛逼的那一套
这是不对滴，bigdata主要是慢，自己要去做各种优化
但是只要知道概念，其实操作big data的东西比操作db要简单点 |
|
c******o
发帖数: 1277 | 43 from what I know the recent BD wave begin from G/F/T (Google BigTable is the
root of many NoSQL)
Look at how they used it,
Google => web indexing, "My Search History", Google Earth, Google Code
hosting, Orkut, YouTube, and Gmail
Facebook => Inbox Search, Instagram unit, primary big data analytical store,
messages and monitoring (still mainly use sharded MySQL though, with a lot
of optimization and not really use a lot of relational logic)
Twitter =>Analytical data (like Facebook, still mostly... 阅读全帖 |
|
e*******o
发帖数: 4654 | 44 主要放schema less data比较方便。这是我所在的公司用这个的主要原因。小公司，没
啥bigdata。 |
|
p*****2
发帖数: 21240 | 45 python确实能full stack。但是未来的web端是node的天下。可是JS的弱点很明显，就
是做后端太勉强了，所以就需要寻找另外的平台，那一般就选JVM了。而且startup需要
productivity，这也是为什么倾向于脚本的原因，而JVM上的脚本又可以做后端很自然
就选Clojure了。JVM的优势，python还是不能比的。
现在的几个大趋势
1. mobile， 这个一般选node
2. bigdata，这个一般JVM
3. cloud，一般C++/JVM，python就是有个open stack，不过也是胶水，不是什么核心
技术
对于startup来说，1，2做的最多，因为3的门槛比较高，除非是goodbug说的SAAS这些
，比如workday。所以从1，2来说也看不出来python的优势。 |
|
p*****2
发帖数: 21240 | 46
bigdata这块有的镐头。现在目前的技术都不算成熟。 |
|
w***g
发帖数: 5958 | 47 bigdata本身更主要是一个商业概念，根本就没有多少科学性可言。各种应用的需求各不
相同，凑到一块其实没什么共同语言。但是人类离singularity真的只有一步之遥了。迈
出这一步的那个人我觉得可能都已经出生了。 |
|
|
|
|
