T********i
发帖数: 2416 | 1 其实当MQ用也可以。
但是你不能一方面默认排序，用time based UUID，另一方面又claim无限scalability。
这才是明显的错误。拉出来了。摆在那里。抵赖也没用。
你真的懂Cassandra么？让大伙说说你真的懂么？ |
b******y
发帖数: 9224 | |
T********i
发帖数: 2416 | 3 现在就算丫的亮出自己的牌子，工作证明，W2，大家也不会信丫的了。 |
g*****g
发帖数: 34805 | 4 这板上最熟悉C*就wwzz和我，那天怎么打脸的你忘了，还没完了。
本来就不需要实时读，无限scalability的是写。
scalability。
【在 T********i 的大作中提到】
: 其实当MQ用也可以。
: 但是你不能一方面默认排序，用time based UUID，另一方面又claim无限scalability。
: 这才是明显的错误。拉出来了。摆在那里。抵赖也没用。
: 你真的懂Cassandra么？让大伙说说你真的懂么？
|
T********i
发帖数: 2416 | 5 又犯错误了是不是？
读的时候需要不需要保持次序？
【在 g*****g 的大作中提到】
: 这板上最熟悉C*就wwzz和我，那天怎么打脸的你忘了，还没完了。
: 本来就不需要实时读，无限scalability的是写。
:
: scalability。
|
g*****g
发帖数: 34805 | 6 读的时候怎么不保持顺序了？你完全不懂C*怎么工作的。
【在 T********i 的大作中提到】
: 又犯错误了是不是？
: 读的时候需要不需要保持次序？
|
T********i
发帖数: 2416 | 7 你告诉我读的时候怎么能保持次序。
让大家评一下是你不懂还是我不懂。
【在 g*****g 的大作中提到】
: 读的时候怎么不保持顺序了？你完全不懂C*怎么工作的。
|
g*****g
发帖数: 34805 | 8 我都说了index CF，你就继续糊涂吧。
【在 T********i 的大作中提到】
: 你告诉我读的时候怎么能保持次序。
: 让大家评一下是你不懂还是我不懂。
|
T********i
发帖数: 2416 | 9 你就别扯淡了。
你要求我有票100%出票。而且我还是实时的。每秒1M票你还嫌少。
你贴一个有票100%出票的好了。可以非实时。我倒要看你怎么Index CF。Schema贴出来
。6000台机器，能做到100K/s么？ |
g*****g
发帖数: 34805 | 10 我都说得那么清楚了，任何对C*有一点点经验的人都知道怎么回事。
你学不会我就必须教吗。
【在 T********i 的大作中提到】
: 你就别扯淡了。
: 你要求我有票100%出票。而且我还是实时的。每秒1M票你还嫌少。
: 你贴一个有票100%出票的好了。可以非实时。我倒要看你怎么Index CF。Schema贴出来
: 。6000台机器，能做到100K/s么？
|
|
|
T********i
发帖数: 2416 | 11 不用你教。看下面的要求。
你敢号称你能做到100K/s么？
敢还是不敢。给个痛快话就好了么！
你要求我有票100%出票。而且我还是实时的。每秒1M票你还嫌少。
你贴一个有票100%出票的好了。可以非实时。6000台机器，能做到100K/s么？
【在 g*****g 的大作中提到】
: 我都说得那么清楚了，任何对C*有一点点经验的人都知道怎么回事。
: 你学不会我就必须教吗。
|
g*****g
发帖数: 34805 | 12 写是实时的，读不需要实时。你这么脑残想不明白怎么弄，就想着等够时间，读出来，
再排序，该用多久用多久。
【在 T********i 的大作中提到】
: 不用你教。看下面的要求。
: 你敢号称你能做到100K/s么？
: 敢还是不敢。给个痛快话就好了么！
: 你要求我有票100%出票。而且我还是实时的。每秒1M票你还嫌少。
: 你贴一个有票100%出票的好了。可以非实时。6000台机器，能做到100K/s么？
|
T********i
发帖数: 2416 | 13 PA只能证明你下流。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？
【在 g*****g 的大作中提到】
: 写是实时的，读不需要实时。你这么脑残想不明白怎么弄，就想着等够时间，读出来，
: 再排序，该用多久用多久。
|
w**z
发帖数: 8232 | 14 C* 也可以shard, 不同票db，可以用不同的CF，这样就能scale
. 当然你说100k 每秒抢的同一车次的票，那我也没辙。 good bug 一个msg 一个row，
有其他考量。 也可以time stamp 做rowkey.
【在 T********i 的大作中提到】
: 不用你教。看下面的要求。
: 你敢号称你能做到100K/s么？
: 敢还是不敢。给个痛快话就好了么！
: 你要求我有票100%出票。而且我还是实时的。每秒1M票你还嫌少。
: 你贴一个有票100%出票的好了。可以非实时。6000台机器，能做到100K/s么？
|
g*****g
发帖数: 34805 | 15 这些跟C*什么关系？傻逼你脑子实在糊涂的很。
transaction
【在 T********i 的大作中提到】
: PA只能证明你下流。
: 再问你一次，能保证有票100%出票么？能达到100K/s么？
: 能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
: 的话就变成50万/s了。
: 你那个6000台能保证有票100%出票么？能达到100K/s么？
|
T********i
发帖数: 2416 | 16 PA只能证明你下流。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？
能？还是不能？简单回答！
【在 g*****g 的大作中提到】
: 这些跟C*什么关系？傻逼你脑子实在糊涂的很。
:
: transaction
|
g*****g
发帖数: 34805 | 17 本来就是离线出票的，所有的分布式架构只是为了降低延迟。前端能实时写单就行了。
太监你实在很糊涂。拿C*出来叫板，被打脸又转进了？
transaction
【在 T********i 的大作中提到】
: PA只能证明你下流。
: 再问你一次，能保证有票100%出票么？能达到100K/s么？
: 能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
: 的话就变成50万/s了。
: 你那个6000台能保证有票100%出票么？能达到100K/s么？
: 能？还是不能？简单回答！
|
T********i
发帖数: 2416 | 18 你他妈的用6000台机器，问一下你处理能力不过分吧？
就问你能不能达到100K/s。要求高么？
PA只能证明你下流。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？
【在 g*****g 的大作中提到】
: 本来就是离线出票的，所有的分布式架构只是为了降低延迟。前端能实时写单就行了。
: 太监你实在很糊涂。拿C*出来叫板，被打脸又转进了？
:
: transaction
|
g*****g
发帖数: 34805 | 19 后端我哪怕只有1台机器加一个数据库也能保证100%出票呀。反正离线的。我从没说出
票要100K/s. 前端写单1M/s都没问题。
transaction
【在 T********i 的大作中提到】
: 你他妈的用6000台机器，问一下你处理能力不过分吧？
: 就问你能不能达到100K/s。要求高么？
: PA只能证明你下流。
: 再问你一次，能保证有票100%出票么？能达到100K/s么？
: 能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
: 的话就变成50万/s了。
: 你那个6000台能保证有票100%出票么？能达到100K/s么？
|
N********n
发帖数: 8363 | 20
读出来再排序那还算什么QUEUE？那就是一个LIST。而且这种读是啥效率？
肯定快不了。估计也不能随机指定读区间。
【在 g*****g 的大作中提到】
: 写是实时的，读不需要实时。你这么脑残想不明白怎么弄，就想着等够时间，读出来，
: 再排序，该用多久用多久。
|
|
|
g*****g
发帖数: 34805 | 21 这就是举个例子，怎么弄都行。C*太监不懂，你让我怎么解释。
为啥1+1=2呀，你来解释一个。
【在 N********n 的大作中提到】
:
: 读出来再排序那还算什么QUEUE？那就是一个LIST。而且这种读是啥效率？
: 肯定快不了。估计也不能随机指定读区间。
|
N********n
发帖数: 8363 | 22
怎么都行的数据结构是不存在的。QUEUE要保证FIFO，ENQUEUE、DEQUEUE都
是O(1)，看不出C*怎么能做到。FIFO本身就是一种紧耦合，觉得拿啥NOSQL
来都没戏，只能这里妥协一下、那里妥协一下。
【在 g*****g 的大作中提到】
: 这就是举个例子，怎么弄都行。C*太监不懂，你让我怎么解释。
: 为啥1+1=2呀，你来解释一个。
|
z****e
发帖数: 54598 | 23 我们干活不都是做trade off么？
如果真的一台机器啥都能做，也就不用trade off了
【在 N********n 的大作中提到】
:
: 怎么都行的数据结构是不存在的。QUEUE要保证FIFO，ENQUEUE、DEQUEUE都
: 是O(1)，看不出C*怎么能做到。FIFO本身就是一种紧耦合，觉得拿啥NOSQL
: 来都没戏，只能这里妥协一下、那里妥协一下。
|
N********n
发帖数: 8363 | 24
本来就是要把TRADE OFF讨论清楚。一个不排序的LIST当成QUEUE来读那是
啥效率？如果随意制定一个时间段[A, B]来读，这个LIST都不排序怎么保
证把所有在A、B之间MSG读出来？
老魏上礼拜说的就是这个意思，拿HASH TABLE做QUEUE面试的时候要秒据。
【在 z****e 的大作中提到】
: 我们干活不都是做trade off么？
: 如果真的一台机器啥都能做，也就不用trade off了
|
w**z
发帖数: 8232 | 25 用timestamp 做rowkey， timeuuid 做columnkey， C＊的column 存储就是用
columnkey 排序的。如果量不大，可以用 second，minute， hour， day， year。。
。 做rowkey， 用C＊ 处理 time series data 很常用，看看这个：
http://www.datastax.com/dev/blog/advanced-time-series-with-cass
不懂再来问
【在 N********n 的大作中提到】
:
: 本来就是要把TRADE OFF讨论清楚。一个不排序的LIST当成QUEUE来读那是
: 啥效率？如果随意制定一个时间段[A, B]来读，这个LIST都不排序怎么保
: 证把所有在A、B之间MSG读出来？
: 老魏上礼拜说的就是这个意思，拿HASH TABLE做QUEUE面试的时候要秒据。
|
w**z
发帖数: 8232 | 26 netflix probably has the biggest C* deployment out there.
Here is some information:
http://www.slideshare.net/acunu/cassandra-eu-2012-netflixs-cass
It was bit old information. I heard from last year's C* summit, Netflix's
biggest C* cluster was 144 nodes...total close to 1000 nodes.
Disclaim: I don't work for Netflix and I don't know goodbug in person!
【在 w**z 的大作中提到】
: 用timestamp 做rowkey， timeuuid 做columnkey， C＊的column 存储就是用
: columnkey 排序的。如果量不大，可以用 second，minute， hour， day， year。。
: 。 做rowkey， 用C＊ 处理 time series data 很常用，看看这个：
: http://www.datastax.com/dev/blog/advanced-time-series-with-cass
: 不懂再来问
|
N********n
发帖数: 8363 | 27
"用timestamp 做rowkey"本身就是问题。假设时间区间[A, B]，A的TIMESTAMP
如果不在TABLE里面怎么办。你怎样快速找到下一个离A最近的MSG? 这里没有
取巧，一旦要搜索你的DEQUEUE效率就不是O(1)。
先说TIMESTAMP，其他问题肯定也不少。总之这个数据结构不能当QUEUE用。
【在 w**z 的大作中提到】
: 用timestamp 做rowkey， timeuuid 做columnkey， C＊的column 存储就是用
: columnkey 排序的。如果量不大，可以用 second，minute， hour， day， year。。
: 。 做rowkey， 用C＊ 处理 time series data 很常用，看看这个：
: http://www.datastax.com/dev/blog/advanced-time-series-with-cass
: 不懂再来问
|
z****e
发帖数: 54598 | 28 我觉得queue本身是用来对付实际需要的
实际需要千差万别，谁也没说这个需求只能用mq做不是？
真要换的话，随便找个rabbitmq上就是了
只是觉得这里不见得一定要用mq罢了
【在 N********n 的大作中提到】
:
: "用timestamp 做rowkey"本身就是问题。假设时间区间[A, B]，A的TIMESTAMP
: 如果不在TABLE里面怎么办。你怎样快速找到下一个离A最近的MSG? 这里没有
: 取巧，一旦要搜索你的DEQUEUE效率就不是O(1)。
: 先说TIMESTAMP，其他问题肯定也不少。总之这个数据结构不能当QUEUE用。
|
g*****g
发帖数: 34805 | 29 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 的大作中提到】
:
: "用timestamp 做rowkey"本身就是问题。假设时间区间[A, B]，A的TIMESTAMP
: 如果不在TABLE里面怎么办。你怎样快速找到下一个离A最近的MSG? 这里没有
: 取巧，一旦要搜索你的DEQUEUE效率就不是O(1)。
: 先说TIMESTAMP，其他问题肯定也不少。总之这个数据结构不能当QUEUE用。
|
w**z
发帖数: 8232 | 30 As goodbug noted, C* doesn't support range scan on row key if you use
RandomPartitioner which is suggested. (unless you are brave enought to try
ByteOrderedPartitioner, http://www.datastax.com/docs/1.1/cluster_architecture/partitioning#byteorderedpartitioner)
You can use an index cf. for sparse data, if you can afford use day as row
key, don't need index CF. The trick is that the columns are stored in C* in
order.
Read this one if you are interested in knowing the internals and details.
http://doanduyhai.wordpress.com/2012/07/05/apache-cassandra-tri
There are plenty of information there if you want to understand it. Don't
make assumption without knowing the details.
【在 N********n 的大作中提到】
:
: "用timestamp 做rowkey"本身就是问题。假设时间区间[A, B]，A的TIMESTAMP
: 如果不在TABLE里面怎么办。你怎样快速找到下一个离A最近的MSG? 这里没有
: 取巧，一旦要搜索你的DEQUEUE效率就不是O(1)。
: 先说TIMESTAMP，其他问题肯定也不少。总之这个数据结构不能当QUEUE用。
|
|
|
N********n
发帖数: 8363 | 31
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 的大作中提到】
: 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.
|
g*****g
发帖数: 34805 | 32 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 的大作中提到】
:
: 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.
|
N********n
发帖数: 8363 | 33
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.
【在 w**z 的大作中提到】
: As goodbug noted, C* doesn't support range scan on row key if you use
: RandomPartitioner which is suggested. (unless you are brave enought to try
: ByteOrderedPartitioner, http://www.datastax.com/docs/1.1/cluster_architecture/partitioning#byteorderedpartitioner)
: You can use an index cf. for sparse data, if you can afford use day as row
: key, don't need index CF. The trick is that the columns are stored in C* in
: order.
: Read this one if you are interested in knowing the internals and details.
: http://doanduyhai.wordpress.com/2012/07/05/apache-cassandra-tri
: There are plenty of information there if you want to understand it. Don't
: make assumption without knowing the details.
|
T********i
发帖数: 2416 | 34 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
【在 g*****g 的大作中提到】
: 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.
|
w**z
发帖数: 8232 | 35 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.
【在 N********n 的大作中提到】
:
: 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 | 36 再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
T********i
发帖数: 2416 | 37 goodbug，要脸的话就回答我的问题。或者你认个错也就算了。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
N********n
发帖数: 8363 | 38
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.
【在 w**z 的大作中提到】
: 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 | 39 NeverLearn，请不要打扰goodbug回答重要问题，谢谢。
goodbug，要脸的话就回答我的问题。或者你认个错也就算了。
再问你一次，能保证有票100%出票么？能达到100K/s么？
能还是不能？什么叫该用多久用多久？我单机100万票/s你还要无耻什么算transaction
的话就变成50万/s了。
你那个6000台能保证有票100%出票么？能达到100K/s么？ |
w**z
发帖数: 8232 | 40 跟你没法说，C＊ 有个叫compaction 的东西，所有的SSTable 都是immutable after
written to disk. 如果你没兴趣了解一下C＊的internal， 就没有必要再讨论了。我
已经说
的够多了，你不想花时间学一下，就在这瞎喷，抬杠，俺没功夫陪你了，你说C＊不能
用，就不能用，随意。反正俺们用的好好的。
【在 N********n 的大作中提到】
:
: 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.
|
|
|
k********e
发帖数: 702 | 41 无经验小白求大侠教一教
【在 g*****g 的大作中提到】
: 我都说得那么清楚了，任何对C*有一点点经验的人都知道怎么回事。
: 你学不会我就必须教吗。
|
g*****g
发帖数: 34805 | 42 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 的大作中提到】
: 无经验小白求大侠教一教
|
k********e
发帖数: 702 | 43 谢谢大佬。看来还是得先学学 C* for dummies.
【在 g*****g 的大作中提到】
: 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.
|
