r*0
2 楼
力挺up in the air了,哈哈哈哈。给我们点surprise吧。
l*k
3 楼
【 以下文字转载自 Chongqing 讨论区 】
发信人: lilybank (愉渝), 信区: Chongqing
标 题: 明月几时有
发信站: BBS 未名空间站 (Mon Sep 8 22:35:30 2014, 美东)
看女神下凡
最近到处都是此女神广告
Dior J'adore 因此热卖
女神美得如人间尤物,可惜此香水我不待见
记得刚到美国第一个月,收到第一份做TA的工资,冲到商场买了这瓶闻名中外的香水
还没喷过十次就被遗忘在某个角落,几年后在整理瓶瓶罐罐的时候发现,不知何时透明
的香水已经开始泛黄
经历了多种类型香水的尝试,在被鲜艳强烈的玫瑰侵袭占领后,才顿悟到为何如此独特
的jasmine被冷藏
欣赏光芒四射的女神,以此纪念我拥有的第一瓶香水
发信人: lilybank (愉渝), 信区: Chongqing
标 题: 明月几时有
发信站: BBS 未名空间站 (Mon Sep 8 22:35:30 2014, 美东)
看女神下凡
最近到处都是此女神广告
Dior J'adore 因此热卖
女神美得如人间尤物,可惜此香水我不待见
记得刚到美国第一个月,收到第一份做TA的工资,冲到商场买了这瓶闻名中外的香水
还没喷过十次就被遗忘在某个角落,几年后在整理瓶瓶罐罐的时候发现,不知何时透明
的香水已经开始泛黄
经历了多种类型香水的尝试,在被鲜艳强烈的玫瑰侵袭占领后,才顿悟到为何如此独特
的jasmine被冷藏
欣赏光芒四射的女神,以此纪念我拥有的第一瓶香水
h*i
4 楼
h*e
5 楼
感觉美版的便宜,不喜欢在taobao上买。
1)美版如果不刷机显示简体中文有没有问题?
2)如果需要刷机,可以直接上官网刷吗?
谢谢
1)美版如果不刷机显示简体中文有没有问题?
2)如果需要刷机,可以直接上官网刷吗?
谢谢
t*1
6 楼
本版令人堪忧呀。
c*6
7 楼
全新的,没开封。
有需要的站内联系。
有需要的站内联系。
q*x
10 楼
sf~
好美啊。。。
改天给你看我的小香水瓶啊,不过不多,就是好玩~
好美啊。。。
改天给你看我的小香水瓶啊,不过不多,就是好玩~
w*n
11 楼
人要解脱是因为人觉得苦
或者说人有不自在、不满足、不完整,限于流转生死,人生虽有短暂乐趣,但在轮回当
中你能感受苦乐便是报应
所以当证无上智慧,入涅磐寂静
另,我本身不赞成以上观点,以上观点仅基于我目前对佛教的肤浅理解给出
或者说人有不自在、不满足、不完整,限于流转生死,人生虽有短暂乐趣,但在轮回当
中你能感受苦乐便是报应
所以当证无上智慧,入涅磐寂静
另,我本身不赞成以上观点,以上观点仅基于我目前对佛教的肤浅理解给出
p*2
13 楼
貌似搞Java的都很钟爱这个。
l*k
20 楼
哎~女神脱鞋爬杆的样子都那么销魂~
完了,不爱嫦娥爱Dior女神了怎么办。。。
完了,不爱嫦娥爱Dior女神了怎么办。。。
l*s
23 楼
what is c*?
c*o
27 楼
my first hand experience for 1).
It seems to be fine. I can read chinese at home through wifi. But i tried
once at star buck and all of sudden Chinese did not show up correctly. I do
not know why myself either. Anyone has similar experience?
【在 h****e 的大作中提到】
: 感觉美版的便宜,不喜欢在taobao上买。
: 1)美版如果不刷机显示简体中文有没有问题?
: 2)如果需要刷机,可以直接上官网刷吗?
: 谢谢
It seems to be fine. I can read chinese at home through wifi. But i tried
once at star buck and all of sudden Chinese did not show up correctly. I do
not know why myself either. Anyone has similar experience?
【在 h****e 的大作中提到】
: 感觉美版的便宜,不喜欢在taobao上买。
: 1)美版如果不刷机显示简体中文有没有问题?
: 2)如果需要刷机,可以直接上官网刷吗?
: 谢谢
h*e
32 楼
have you updated the software and others through nokia website to try to
solve the problem yet?
do
【在 c*******o 的大作中提到】
: my first hand experience for 1).
: It seems to be fine. I can read chinese at home through wifi. But i tried
: once at star buck and all of sudden Chinese did not show up correctly. I do
: not know why myself either. Anyone has similar experience?
solve the problem yet?
do
【在 c*******o 的大作中提到】
: my first hand experience for 1).
: It seems to be fine. I can read chinese at home through wifi. But i tried
: once at star buck and all of sudden Chinese did not show up correctly. I do
: not know why myself either. Anyone has similar experience?
d*r
43 楼
如果不要求速度,可以吧
另外 Redis,不也经常当 message queue 用吗
另外 Redis,不也经常当 message queue 用吗
z*i
49 楼
你有包子先分了吧。省得便宜老刑
b*g
72 楼
傻逼太监又出来丢人了。这是cassandra最常见的time series.
time based UUID 做key, key扔入一个index CF 排序。index CF本身又可以sharding
分多行。
写是commit log, 根本不锁,完全并发。读的时候先读index CF, 给个start time
UUID, end
time UUID, 一次读出一行里的这些 key, 读column本身可以并发,然后拿这些key去读
纪录也是并发的。虽然没有写快。但是作为 MQ, 本身就是缓冲,不需要实时。
100K/s 写峰值完全没有压力。本质上就是无锁写,compaction的时候才sort. 读出的
时候已经排好了。
time based UUID 做key, key扔入一个index CF 排序。index CF本身又可以sharding
分多行。
写是commit log, 根本不锁,完全并发。读的时候先读index CF, 给个start time
UUID, end
time UUID, 一次读出一行里的这些 key, 读column本身可以并发,然后拿这些key去读
纪录也是并发的。虽然没有写快。但是作为 MQ, 本身就是缓冲,不需要实时。
100K/s 写峰值完全没有压力。本质上就是无锁写,compaction的时候才sort. 读出的
时候已经排好了。
b*g
86 楼
Messages are distributed but index key can be on one node (3 copy), which is
just a UUID and you can easily fetch 10K in a read for a few ms because
those rows are cached in memory too.
You don't read next, you get a batch of sort keys by specifying start and
end, read the corresponding
messages concurrently and you get a sorted queue.
【在 N********n 的大作中提到】
:
: QUEUE通常就是用DOUBLE LINKED LIST实现的吗。高并发的环境下MQ的存取
: 就变HOT SPOT了,不觉得用NOSQL能帮什么忙。
: NOSQL基本出发点是数据之间LOW COUPLING。这样才能SCALE OUT。而QUEUE
: 本身要求其数据FIRST IN FIRST OUT。这个FIFO就是一种COUPLING。
just a UUID and you can easily fetch 10K in a read for a few ms because
those rows are cached in memory too.
You don't read next, you get a batch of sort keys by specifying start and
end, read the corresponding
messages concurrently and you get a sorted queue.
【在 N********n 的大作中提到】
:
: QUEUE通常就是用DOUBLE LINKED LIST实现的吗。高并发的环境下MQ的存取
: 就变HOT SPOT了,不觉得用NOSQL能帮什么忙。
: NOSQL基本出发点是数据之间LOW COUPLING。这样才能SCALE OUT。而QUEUE
: 本身要求其数据FIRST IN FIRST OUT。这个FIFO就是一种COUPLING。
N*n
87 楼
So essentially those UUIDs are still maintained on one single spot,
which is no different from running on a single machine.
【在 b*******g 的大作中提到】
: Messages are distributed but index key can be on one node (3 copy), which is
: just a UUID and you can easily fetch 10K in a read for a few ms because
: those rows are cached in memory too.
: You don't read next, you get a batch of sort keys by specifying start and
: end, read the corresponding
: messages concurrently and you get a sorted queue.
N*n
90 楼
And what's the efficiency of this "specifying start and end" thing?
How to quickly locate the exact UUIDs for random start and end? Sounds
like an O(log N) operation, which is more expensive than a typical
ENQUEUE DEQUEUE or Hash Table access. Those are O(1).
【在 b*******g 的大作中提到】
: Messages are distributed but index key can be on one node (3 copy), which is
: just a UUID and you can easily fetch 10K in a read for a few ms because
: those rows are cached in memory too.
: You don't read next, you get a batch of sort keys by specifying start and
: end, read the corresponding
: messages concurrently and you get a sorted queue.
b*g
92 楼
There are different types of MQ, for us, events are generated in burst, it
can be as high as 100K/s and we can't lose them. We are optimizing for peak
write and C* works well for us there. Sink doesn't have to go as fast.
【在 N********n 的大作中提到】
:
: No magic here. Coupling and SCALABILITY cannot co-exist.
can be as high as 100K/s and we can't lose them. We are optimizing for peak
write and C* works well for us there. Sink doesn't have to go as fast.
【在 N********n 的大作中提到】
:
: No magic here. Coupling and SCALABILITY cannot co-exist.
b*g
93 楼
Cassandra is not an MQ, Cassandra is only a storage backing the MQ.
You can read one record at a time 100K times or you can read 100K records at
a time and put them in memory. We all know which one is faster.
While the keys are centralized (some sharding is possible too), they are
very small and messages are big. Concurrently retrieving messages from a
cluster is a big advantage as you won't have a hot spot.
【在 N********n 的大作中提到】
:
: No magic here. Coupling and SCALABILITY cannot co-exist.
You can read one record at a time 100K times or you can read 100K records at
a time and put them in memory. We all know which one is faster.
While the keys are centralized (some sharding is possible too), they are
very small and messages are big. Concurrently retrieving messages from a
cluster is a big advantage as you won't have a hot spot.
【在 N********n 的大作中提到】
:
: No magic here. Coupling and SCALABILITY cannot co-exist.
w*z
94 楼
为什么不直接用timestamp 做row key?每个ms里的message 是同一row 的columns?但
要求所有client的clock要用NTP sync
sharding
【在 b*******g 的大作中提到】
: 傻逼太监又出来丢人了。这是cassandra最常见的time series.
: time based UUID 做key, key扔入一个index CF 排序。index CF本身又可以sharding
: 分多行。
: 写是commit log, 根本不锁,完全并发。读的时候先读index CF, 给个start time
: UUID, end
: time UUID, 一次读出一行里的这些 key, 读column本身可以并发,然后拿这些key去读
: 纪录也是并发的。虽然没有写快。但是作为 MQ, 本身就是缓冲,不需要实时。
: 100K/s 写峰值完全没有压力。本质上就是无锁写,compaction的时候才sort. 读出的
: 时候已经排好了。
要求所有client的clock要用NTP sync
sharding
【在 b*******g 的大作中提到】
: 傻逼太监又出来丢人了。这是cassandra最常见的time series.
: time based UUID 做key, key扔入一个index CF 排序。index CF本身又可以sharding
: 分多行。
: 写是commit log, 根本不锁,完全并发。读的时候先读index CF, 给个start time
: UUID, end
: time UUID, 一次读出一行里的这些 key, 读column本身可以并发,然后拿这些key去读
: 纪录也是并发的。虽然没有写快。但是作为 MQ, 本身就是缓冲,不需要实时。
: 100K/s 写峰值完全没有压力。本质上就是无锁写,compaction的时候才sort. 读出的
: 时候已经排好了。
b*g
95 楼
With your schema, writing is about the same. And your read is even
faster.
We keep one message on one row to have some flexibility on the read. e.g. We
can have metadata and message body and we can read metadata only. When you
have multiple messages in one row, it's harder to achieve that.
I think it's all kind of tradeoff and it depends on your application.
【在 w**z 的大作中提到】
: 为什么不直接用timestamp 做row key?每个ms里的message 是同一row 的columns?但
: 要求所有client的clock要用NTP sync
:
: sharding
faster.
We keep one message on one row to have some flexibility on the read. e.g. We
can have metadata and message body and we can read metadata only. When you
have multiple messages in one row, it's harder to achieve that.
I think it's all kind of tradeoff and it depends on your application.
【在 w**z 的大作中提到】
: 为什么不直接用timestamp 做row key?每个ms里的message 是同一row 的columns?但
: 要求所有client的clock要用NTP sync
:
: sharding
w*z
96 楼
Makes sense.
Thanks.
We
you
【在 b*******g 的大作中提到】
: With your schema, writing is about the same. And your read is even
: faster.
: We keep one message on one row to have some flexibility on the read. e.g. We
: can have metadata and message body and we can read metadata only. When you
: have multiple messages in one row, it's harder to achieve that.
: I think it's all kind of tradeoff and it depends on your application.
Thanks.
We
you
【在 b*******g 的大作中提到】
: With your schema, writing is about the same. And your read is even
: faster.
: We keep one message on one row to have some flexibility on the read. e.g. We
: can have metadata and message body and we can read metadata only. When you
: have multiple messages in one row, it's harder to achieve that.
: I think it's all kind of tradeoff and it depends on your application.
N*n
97 楼
Well that's basically what the topic says - C* is not MQ - right?
Your app has a specific need of batch message reading that can be
solved w/ C*. That's fine. If, however, the requirement is a pure
FIFO queue then a doublely-linked list is what people will use.
Btw UUIDs themselves are hot spot as they have to be centralized
and sorted. Perhaps your app does not access it too frequently so
you don't care.
【在 b*******g 的大作中提到】
: Cassandra is not an MQ, Cassandra is only a storage backing the MQ.
: You can read one record at a time 100K times or you can read 100K records at
: a time and put them in memory. We all know which one is faster.
: While the keys are centralized (some sharding is possible too), they are
: very small and messages are big. Concurrently retrieving messages from a
: cluster is a big advantage as you won't have a hot spot.
p*2
98 楼
doublely-linked list
这个怎么scale?
【在 N********n 的大作中提到】
:
: Well that's basically what the topic says - C* is not MQ - right?
: Your app has a specific need of batch message reading that can be
: solved w/ C*. That's fine. If, however, the requirement is a pure
: FIFO queue then a doublely-linked list is what people will use.
: Btw UUIDs themselves are hot spot as they have to be centralized
: and sorted. Perhaps your app does not access it too frequently so
: you don't care.
b*g
99 楼
For the context, we are talking about 12306 where I saved the orders to C*.
C* is a DB, a DB is certainly not a MQ but it can be a MQ storage.
For a time series like that, you grab keys you read orders and you never
need to visit the same sorted keys in DB again. It's pretty much one write
and one read with read being offline and batch. It will work just fine.
【在 N********n 的大作中提到】
:
: Well that's basically what the topic says - C* is not MQ - right?
: Your app has a specific need of batch message reading that can be
: solved w/ C*. That's fine. If, however, the requirement is a pure
: FIFO queue then a doublely-linked list is what people will use.
: Btw UUIDs themselves are hot spot as they have to be centralized
: and sorted. Perhaps your app does not access it too frequently so
: you don't care.
C* is a DB, a DB is certainly not a MQ but it can be a MQ storage.
For a time series like that, you grab keys you read orders and you never
need to visit the same sorted keys in DB again. It's pretty much one write
and one read with read being offline and batch. It will work just fine.
【在 N********n 的大作中提到】
:
: Well that's basically what the topic says - C* is not MQ - right?
: Your app has a specific need of batch message reading that can be
: solved w/ C*. That's fine. If, however, the requirement is a pure
: FIFO queue then a doublely-linked list is what people will use.
: Btw UUIDs themselves are hot spot as they have to be centralized
: and sorted. Perhaps your app does not access it too frequently so
: you don't care.
相关阅读
gap很多年了读书,考试还是直接找工求Becker教材PDF题求建议甩卖!超便宜(什么都有:家具,电器,食品..)快进来吧!BEC考经亲们:有Ninja CPA materials "BEC" notes 请看过来!click it open the new job in 18 major U.S. cities (audit, CCAR, market risk, data, modeling, risk )代友问会计硕士选校请问最近有人用FACS评估的吗有申请过Golden Gate University MS Taxation的XDJM们进来一下还有人要团购becker 2016的吗?提供EY内部推荐for tax, audit and advisory, any locationBecker软件使用问题?2015-2016 Becker to Share (4 parts)求经验:洛杉矶地区找会计审计工作有没有人一起团2016 becker的材料如果跟第一个offer拉锯等第二个offer?大公司都用啥税务软件?公司急召accounting assistant求建议我的职业该如何规划