|
T********i
发帖数: 2416 | 2 现在就算丫的亮出自己的牌子，工作证明，W2，大家也不会信丫的了。 |
|
g*****g
发帖数: 34805 | 3 这板上最熟悉C*就wwzz和我，那天怎么打脸的你忘了，还没完了。
本来就不需要实时读，无限scalability的是写。
scalability。 |
|
T********i
发帖数: 2416 | 4 又犯错误了是不是？
读的时候需要不需要保持次序？ |
|
g*****g
发帖数: 34805 | 5 读的时候怎么不保持顺序了？你完全不懂C*怎么工作的。 |
|
T********i
发帖数: 2416 | 6 你告诉我读的时候怎么能保持次序。
让大家评一下是你不懂还是我不懂。 |
|
|
T********i
发帖数: 2416 | 8 你就别扯淡了。
你要求我有票100%出票。而且我还是实时的。每秒1M票你还嫌少。
你贴一个有票100%出票的好了。可以非实时。我倒要看你怎么Index CF。Schema贴出来
。6000台机器，能做到100K/s么？ |
|
g*****g
发帖数: 34805 | 9 我都说得那么清楚了，任何对C*有一点点经验的人都知道怎么回事。
你学不会我就必须教吗。 |
|
T********i
发帖数: 2416 | 10 不用你教。看下面的要求。
你敢号称你能做到100K/s么？
敢还是不敢。给个痛快话就好了么！
你要求我有票100%出票。而且我还是实时的。每秒1M票你还嫌少。
你贴一个有票100%出票的好了。可以非实时。6000台机器，能做到100K/s么？ |
|
g*****g
发帖数: 34805 | 11 写是实时的，读不需要实时。你这么脑残想不明白怎么弄，就想着等够时间，读出来，
再排序，该用多久用多久。 |
|
T********i
发帖数: 2416 | 12 PA只能证明你下流。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
|
w**z
发帖数: 8232 | 13 C* 也可以shard, 不同票db，可以用不同的CF，这样就能scale
. 当然你说100k 每秒抢的同一车次的票，那我也没辙。 good bug 一个msg 一个row，
有其他考量。 也可以time stamp 做rowkey. |
|
g*****g
发帖数: 34805 | 14 这些跟C*什么关系？傻逼你脑子实在糊涂的很。
transaction |
|
T********i
发帖数: 2416 | 15 PA只能证明你下流。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？
能？还是不能？简单回答！ |
|
g*****g
发帖数: 34805 | 16 本来就是离线出票的，所有的分布式架构只是为了降低延迟。前端能实时写单就行了。
太监你实在很糊涂。拿C*出来叫板，被打脸又转进了？
transaction |
|
T********i
发帖数: 2416 | 17 你他妈的用6000台机器，问一下你处理能力不过分吧？
就问你能不能达到100K/s。要求高么？
PA只能证明你下流。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
|
g*****g
发帖数: 34805 | 18 后端我哪怕只有1台机器加一个数据库也能保证100%出票呀。反正离线的。我从没说出
票要100K/s. 前端写单1M/s都没问题。
transaction |
|
N********n
发帖数: 8363 | 19
读出来再排序那还算什么QUEUE？那就是一个LIST。而且这种读是啥效率？
肯定快不了。估计也不能随机指定读区间。 |
|
g*****g
发帖数: 34805 | 20 这就是举个例子，怎么弄都行。C*太监不懂，你让我怎么解释。
为啥1+1=2呀，你来解释一个。 |
|
N********n
发帖数: 8363 | 21
怎么都行的数据结构是不存在的。QUEUE要保证FIFO，ENQUEUE、DEQUEUE都
是O(1)，看不出C*怎么能做到。FIFO本身就是一种紧耦合，觉得拿啥NOSQL
来都没戏，只能这里妥协一下、那里妥协一下。 |
|
z****e
发帖数: 54598 | 22 我们干活不都是做trade off么？
如果真的一台机器啥都能做，也就不用trade off了 |
|
N********n
发帖数: 8363 | 23
本来就是要把TRADE OFF讨论清楚。一个不排序的LIST当成QUEUE来读那是
啥效率？如果随意制定一个时间段[A, B]来读，这个LIST都不排序怎么保
证把所有在A、B之间MSG读出来？
老魏上礼拜说的就是这个意思，拿HASH TABLE做QUEUE面试的时候要秒据。 |
|
|
N********n
发帖数: 8363 | 25
"用timestamp 做rowkey"本身就是问题。假设时间区间[A, B]，A的TIMESTAMP
如果不在TABLE里面怎么办。你怎样快速找到下一个离A最近的MSG? 这里没有
取巧，一旦要搜索你的DEQUEUE效率就不是O(1)。
先说TIMESTAMP，其他问题肯定也不少。总之这个数据结构不能当QUEUE用。 |
|
z****e
发帖数: 54598 | 26 我觉得queue本身是用来对付实际需要的
实际需要千差万别，谁也没说这个需求只能用mq做不是？
真要换的话，随便找个rabbitmq上就是了
只是觉得这里不见得一定要用mq罢了 |
|
g*****g
发帖数: 34805 | 27 Of course with index CF you have it. Again, until you guys have fundamentals
of C* there's no point to argue here. You just don't understand how it
works.
The sorting is done as part of compaction, since data is in SSTable. Not on
write, not on read, it's a
background process that can impact read. Then again, read is not required
to be real-time, exactly why you use an MQ. When the data are read out, they
are already sorted. |
|
N********n
发帖数: 8363 | 28
All you are saying is that you have a specific use case where you
read in batch and don't read very often so you can get away with
background sorting and thus C* works for you. Fine, but that's not
the general use case of a MQ. |
|
g*****g
发帖数: 34805 | 29 And who said this is the general case of MQ, we are talking about 12306 and
offline batch order processing for god's sake.
I didn't even call it MQ, some retarded did. |
|
N********n
发帖数: 8363 | 30
I don't assume. I'm merely explaining the known principles. Giving
a range of [A, B], key-value pair data structure can quickly tell
you if A or B is in the table but it cannot as quickly find all the
elements b/t A and B for you. It has to search, and that takes time,
ergo not exactly suitable for a MQ.
If you just so happen to not need to read fast or often then fine. |
|
T********i
发帖数: 2416 | 31 What ever you call it.
As long as 100% correctness is required. You are not even confident with
100k/s rate, no matter how many machine you are going to use.
Are you going to deny it?
Come on. Be a man.
and |
|
w**z
发帖数: 8232 | 32 If we are talking about C*, then you need to know the internal of it. the
way C* stores data makes it efficient to do the sorting. that is why it is
so good at handling time series data. |
|
T********i
发帖数: 2416 | 33 再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
|
T********i
发帖数: 2416 | 34 goodbug，要脸的话就回答我的问题。或者你认个错也就算了。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
|
N********n
发帖数: 8363 | 35
The fact C* needs to "sort" tells me it's not as efficient as an
ordinary MQ b/c MQ does not need to sort as it merely appends a new
element at the tail. It's already sorted by time of arrival. If C*
needs to sort first then it has to delay the read till the sorting is
done, and that's not exactly "efficent" if I need to read on the fly. |
|
T********i
发帖数: 2416 | 36 NeverLearn，请不要打扰goodbug回答重要问题，谢谢。
goodbug，要脸的话就回答我的问题。或者你认个错也就算了。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
|
w**z
发帖数: 8232 | 37 跟你没法说，C＊ 有个叫compaction 的东西，所有的SSTable 都是immutable after
written to disk. 如果你没兴趣了解一下C＊的internal， 就没有必要再讨论了。我
已经说
的够多了，你不想花时间学一下，就在这瞎喷，抬杠，俺没功夫陪你了，你说C＊不能
用，就不能用，随意。反正俺们用的好好的。 |
|
|
g*****g
发帖数: 34805 | 39 C* is not a simple database, and it's very different from RDBMS.
Until you have at least gone through some tutorials, it's like discussing
how to efficiently model a system without you knowing SQL. |
|
k********e
发帖数: 702 | 40 谢谢大佬。看来还是得先学学 C* for dummies. |
|
z****e
发帖数: 54598 | 41 来自主题: Programming版 - 开源的轮子 大路货没有问题
问题在于，你会大路货没有意义，没有竞争优势
就像你会db，会sql，没什么大不了的
谁都会，除非你不会，那这个问题小严重
你要会nosql那几个东东才有竞争优势
但是你要会nosql的时候，你会面临着巨大的麻烦
因为文档不全不说，还一堆错的，而这个时候，你就只能靠你自己的经验
去猜，去蒙，甚至不得不去看源代码，给源代码去纠错
很正常，这就是最痛苦的时候，就跟战场一样
你永远都不知道前面会发生什么，什么都有可能发生
出现意料之外的情况太正常不过了，这个时候就看谁能搞定
高手的水平就在于，出现意外，他一样能达到目标
废材就体现于，一个小意外，就能让他全盘皆输
而且压力也很明显，搞不定，老板随时会换人
外面一堆人排着队等着呢，这就是netflix模式
对netflix稍微关注过的都知道，这家公司对cassandra有一种狂热
什么都想往这上面搬，这个其实理由也很简单，因为不用钱
谁都知道oracle db好用，文档多，还有support，问题在于
oracle db要钱还要很多钱，所以老板为了省钱，用c*，你咋办？
如果你是古德霸，manager找你过来，说，明天开始，我们把... 阅读全帖 |
|
d*******r
发帖数: 3299 | 42 二爷你们要从 MongoDB 转 Cassandra 了? 还是只是把高并发的部分 (e.g. 大量log)
转成 Cassandra ? |
|
|
z****e
发帖数: 54598 | 44 反正我是从来没有听说过什么nosql三架马车
更不要说这里面hbase,cassandra在不同时段出现在同一个位置
感觉这个完全是mongodb,couchbase的人吹出来给自己脸上贴金的
hbase, cassandra现在是hadoop ecosystem的两员大将
还有其他七八个什么pig, zookeeper之类的，现在spark也加入了
http://hadoop.apache.org/
相比之下，mongo也好，couch也罢，ecosystem差了十万八千里远
去哪里来的并驾齐驱？这纯粹是匪夷所思的事
所以我很怀疑这个是某些人编造出来忽悠用的
恰好我用过一段时间的couchdb，虽然couchbase比couchdb更完整一点
但是也远没有达到hadoop eco那个规模
mongodb就更不要扯了，这个目的只是替换传统mysql这些而已
如果说市场的话，这里面mongodb还算不错
但是couchbase相比之下那个市场简直就是一个零头
远不如redis这些，我就没看到有几个用couchbase的
甚至couchdb都比couchbase有市场
所谓的market ... 阅读全帖 |
|
|
d*******r
发帖数: 3299 | 46 那你们公司是 HBase, Cassandra 都在用了？
为啥要这么用呢？还是其他人在用 HBase, 你准备用 Cassandra 了 |
|
p*****2
发帖数: 21240 | 47 官网上有两个
Cascal*
Cascal is a simple Cassandra library built on the Scala language.
Phantom
Asynchronous Scala DSL for Apache Cassandra
第一个看着貌似很粗糙，第二个看的有点莫名其妙。
然后Twitter有个Cassie，看着更靠谱一点，但是官网上怎么没有Cassie呢？
大家用哪个？ |
|
c******o
发帖数: 1277 | 48 其实现在觉得，要是你不怕学东西，mongodb ＋ cassandra + mysql都用是最好的。
mongodb 做一般储存，cassandra 做log＋BI, mysql 做payment和强transaction/
relation的data |
|
g*****g
发帖数: 34805 | 49 http://tech.huanqiu.com/per/2013-08/4307208_2.html
我们作为创业公司总结了一些经验和教训跟大家分享一下：
1、保持简单，这对创业公司来讲非常重要，一个简单的系统出错的可能性就很小
，出错以后解决问题的可能性就变得很大。保持简单我们认为对创业公司来说是非常关
键的问题。
2、我们认为一项技术的超级用户遇到的难度是远远大于普通用户的。我们知道大
家今天都在用一些开元软件，这些开元软件是逐步发展的过程，很多软件在早期并没有
经历过很大的压力测试，在一定的流量基础上他们都工作的非常少，但是超过一定流量
的话都有各种各样的问题。如果你作为超级用户，你可能接触到的问题是前人完全没有
遇到的，你很难在社区里得到任何求助，需要自己读它的代码，去看是不是我能解决，
如果解决不了的话怎么办？如果解决了当然是可以去改一下它的代码，如果解决不了的
话，有的时候构架的限制解决不了是很麻烦的问题。
3、新技术往往看上去很美。这个话其实有两层意思，一种是真的看上去很美，如
果看上去不美也不能叫新技术了。第二层意思是往往只是看上去很美，真正用起来并不
美。我们知道一项... 阅读全帖 |
|
z****e
发帖数: 54598 | 50 行业trend是cassandra
现在把hibernate放简历上
加分有限，cassandra比较热
至少nosql这个热点就算过了巅峰
也还没过去太久 |
|
