p****i
发帖数: 6135 | 1 问题简化下是这样：
有一个hash表， key 由两部分组成： K1 and K2
query hash表的时候希望可以满足以下要求：
1 query by K1=V1 only， 返回所有K1=V1的records K2 不计
2 query by K2=V2 only， 返回所有K2＝V2的records， K1 不计
3 query by K1+K2， 正常。
现在的实现是用
ConcurrentHashMap（K1， concurrentHashMap（K2， object））
想在这个基础上再优化， 提高efficiency
请各位高手指点
网上搜到 multikeymap
不知道有人用过吗？ 能有效解决我的问题吗？
谢谢！ |
t***a
发帖数: 416 | 2 也别大改了，就再建个ConcurrentHashMap> 来提高2号
query的效率。和你原来的map一起用，就当是维护俩索引
【在 p****i 的大作中提到】
: 问题简化下是这样：
: 有一个hash表， key 由两部分组成： K1 and K2
: query hash表的时候希望可以满足以下要求：
: 1 query by K1=V1 only， 返回所有K1=V1的records K2 不计
: 2 query by K2=V2 only， 返回所有K2＝V2的records， K1 不计
: 3 query by K1+K2， 正常。
: 现在的实现是用
: ConcurrentHashMap（K1， concurrentHashMap（K2， object））
: 想在这个基础上再优化， 提高efficiency
: 请各位高手指点
|
J*******n
发帖数: 2901 | |
p****i
发帖数: 6135 | 4 不是很合用啊 最后的hashtable size很大的
【在 t***a 的大作中提到】
: 也别大改了，就再建个ConcurrentHashMap> 来提高2号
: query的效率。和你原来的map一起用，就当是维护俩索引
|
p****i
发帖数: 6135 | 5 都存在
单个都不unique
嗯 或许k2可以简化成 unique的
有什么想法吗？
【在 J*******n 的大作中提到】
: K1, K2保证存在，且都是unique吗？
|
g*****g
发帖数: 34805 | 6 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
三个index
>, >, , V>
算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
实现。
如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
【在 p****i 的大作中提到】
: 问题简化下是这样：
: 有一个hash表， key 由两部分组成： K1 and K2
: query hash表的时候希望可以满足以下要求：
: 1 query by K1=V1 only， 返回所有K1=V1的records K2 不计
: 2 query by K2=V2 only， 返回所有K2＝V2的records， K1 不计
: 3 query by K1+K2， 正常。
: 现在的实现是用
: ConcurrentHashMap（K1， concurrentHashMap（K2， object））
: 想在这个基础上再优化， 提高efficiency
: 请各位高手指点
|
t***a
发帖数: 416 | 7 对，其实就是index的思路，如果想省一点，可以只做两个index
k1,k2 combine一个，k2再做一个
如果只query k1, 一样可以用那个combine的index做index search
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
: >, >, , V>
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
|
p****i
发帖数: 6135 | 8 我目前的思路也是这样
但觉得不是特别好
要求我的维护三个maps
这个hashtable同时非常同态
增加删除的频率很高
维护开销会比较大
还有更好的方法吗？
btw 你用过multikeymap吗？
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
: >, >, , V>
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
|
g*****g
发帖数: 34805 | 9 你要深度优化，就得说明你的数据量大小，读写的频度，读写latency分别的要求。既
然你在考虑ConcurrentHashMap，我猜想数据量并不算太大，单机能放得下。经验上
ConcurrentHashMap足够了。你需要的是个benchmark test，然后调试一下
ConcurrentHashMap constructor上那三个不同参数，以及hashcode的算法。虽然你要
维护3个map，但性能瓶颈不会在这里，你甚至可以起3个线程同时进行3个map的维护。
如果并行读写很频繁，你多半会发现瓶颈在CPU上。如果不够快，你需要一个cluster。
如果数据量太大，你需要的是像Cassandra的DB。即便到Pegabytes数据量，每秒一万次
读写的级别，也可以把读写控制在几个ms，Twitter就是那么做的。
我不知道你说得是哪个MultiKeyMap的实现，Apache Commons的那个不thread safe。多
半不是你想要的。
【在 p****i 的大作中提到】
: 我目前的思路也是这样
: 但觉得不是特别好
: 要求我的维护三个maps
: 这个hashtable同时非常同态
: 增加删除的频率很高
: 维护开销会比较大
: 还有更好的方法吗？
: btw 你用过multikeymap吗？
|
p****i
发帖数: 6135 | 10 thanks
数据量并没有太大， 2Million records， 总共大约500Mbytes，
现在追求的是micro－second级别的性能优化
题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
production级别的性能。
现在也在想replace呢
【在 g*****g 的大作中提到】
: 你要深度优化，就得说明你的数据量大小，读写的频度，读写latency分别的要求。既
: 然你在考虑ConcurrentHashMap，我猜想数据量并不算太大，单机能放得下。经验上
: ConcurrentHashMap足够了。你需要的是个benchmark test，然后调试一下
: ConcurrentHashMap constructor上那三个不同参数，以及hashcode的算法。虽然你要
: 维护3个map，但性能瓶颈不会在这里，你甚至可以起3个线程同时进行3个map的维护。
: 如果并行读写很频繁，你多半会发现瓶颈在CPU上。如果不够快，你需要一个cluster。
: 如果数据量太大，你需要的是像Cassandra的DB。即便到Pegabytes数据量，每秒一万次
: 读写的级别，也可以把读写控制在几个ms，Twitter就是那么做的。
: 我不知道你说得是哪个MultiKeyMap的实现，Apache Commons的那个不thread safe。多
: 半不是你想要的。
|
|
|
g*****g
发帖数: 34805 | 11 这个级别没啥好折腾的，就像我说的调一下ConcurrentHashmap和hashcode足以。你先
写个测试测一下，再考虑是否需要进一步优化。我的预测是平均每个操作低于1ms，CPU
是瓶颈。
Cassandra性能很好，关键是你们会不会用。replication factor, consistency level
都有讲究。
Indexing也很有讲究，比如secondary index, Row range query会导致性能问题，你们
多半用了。
【在 p****i 的大作中提到】
: thanks
: 数据量并没有太大， 2Million records， 总共大约500Mbytes，
: 现在追求的是micro－second级别的性能优化
: 题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
: 不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
: production级别的性能。
: 现在也在想replace呢
|
p****i
发帖数: 6135 | 12 你说的1ms 是millisecond级别的吧
这个级别对我们这个应用来说太corse了
hashcode sounds like a potential way, let me check.
CPU
level
【在 g*****g 的大作中提到】
: 这个级别没啥好折腾的，就像我说的调一下ConcurrentHashmap和hashcode足以。你先
: 写个测试测一下，再考虑是否需要进一步优化。我的预测是平均每个操作低于1ms，CPU
: 是瓶颈。
: Cassandra性能很好，关键是你们会不会用。replication factor, consistency level
: 都有讲究。
: Indexing也很有讲究，比如secondary index, Row range query会导致性能问题，你们
: 多半用了。
|
g*****g
发帖数: 34805 | 13 如果你要追求Microsecond的latency，你需要的就不只是算法了。需要的是整个stack
，从硬件到OS的调优。Oracle的JVM也不合适，你需要realtime JVM，否则一个full GC
多半超时。或者就不该选择Java。
Major stock exchange的latency也要几百纳秒，通常纯C/C++写得，软硬件网络都优化
过。Real time不是我熟悉的范畴。
【在 p****i 的大作中提到】
: 你说的1ms 是millisecond级别的吧
: 这个级别对我们这个应用来说太corse了
: hashcode sounds like a potential way, let me check.
:
: CPU
: level
|
J*******n
发帖数: 2901 | 14 看过一些文章，说Java搞Real time确实不是个好的选择 |
w**z
发帖数: 8232 | 15 +1, 昨天晚上一个Cassandra node 差点oom, trigger full gc, (cms failed mode
), 竟然40秒pause.
stack
GC
【在 g*****g 的大作中提到】
: 如果你要追求Microsecond的latency，你需要的就不只是算法了。需要的是整个stack
: ，从硬件到OS的调优。Oracle的JVM也不合适，你需要realtime JVM，否则一个full GC
: 多半超时。或者就不该选择Java。
: Major stock exchange的latency也要几百纳秒，通常纯C/C++写得，软硬件网络都优化
: 过。Real time不是我熟悉的范畴。
|
w**z
发帖数: 8232 | 16 Cassandra read latency is in millionseconds unless you use row cache. write
latency is in microseconds .
【在 p****i 的大作中提到】
: thanks
: 数据量并没有太大， 2Million records， 总共大约500Mbytes，
: 现在追求的是micro－second级别的性能优化
: 题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
: 不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
: production级别的性能。
: 现在也在想replace呢
|
p****i
发帖数: 6135 | 17 用不用JAVA不是我说了算啊。。。
确实我们这个领域通常是用C，现在学人赶时髦。。。
【在 J*******n 的大作中提到】
: 看过一些文章，说Java搞Real time确实不是个好的选择
|
p****i
发帖数: 6135 | 18 这个看起来应该可以将将符合我们的要求：
写大约要求 200K Write Per Second
读还好， millisecond应该可以满足了
看了下twitter的数据， 他们的要求是100k WPS
各位大拿， in memory 的java database性能数据有吗？
谢谢
write
【在 w**z 的大作中提到】
: Cassandra read latency is in millionseconds unless you use row cache. write
: latency is in microseconds .
|
g**e
发帖数: 6127 | 19 介绍一下啥系统需要200K write TPS吧
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
|
p****i
发帖数: 6135 | 20 网络处理相关的
【在 g**e 的大作中提到】
: 介绍一下啥系统需要200K write TPS吧
|
|
|
g*****g
发帖数: 34805 | 21 你这个看似应该直接上专用硬件，C写firmware。成本还低。
twitter每秒处理200K tweets，是几百个结点的并行处理，不是
单个结点串行每个tweet 5微妙。Java做不到那么低的延迟。
你的数据小，读写频度那么高，应该比较接近路由。
【在 p****i 的大作中提到】
: 网络处理相关的
|
w**z
发帖数: 8232 | 22 200k wps, total 2m records？重复update the same records?
500m, 全放memory 吧， 不需要用cassandra .
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
|
g*****g
发帖数: 34805 | 23 单机内存放得下，但支持不了这个级别latency这么低的读写。
【在 w**z 的大作中提到】
: 200k wps, total 2m records？重复update the same records?
: 500m, 全放memory 吧， 不需要用cassandra .
|
w**z
发帖数: 8232 | 24 如果是对同一个record 重复update ,不知道哪个软件可以做到那么大的量
【在 g*****g 的大作中提到】
: 单机内存放得下，但支持不了这个级别latency这么低的读写。
|
p****i
发帖数: 6135 | 25 问题简化下是这样：
有一个hash表， key 由两部分组成： K1 and K2
query hash表的时候希望可以满足以下要求：
1 query by K1=V1 only， 返回所有K1=V1的records K2 不计
2 query by K2=V2 only， 返回所有K2＝V2的records， K1 不计
3 query by K1+K2， 正常。
现在的实现是用
ConcurrentHashMap（K1， concurrentHashMap（K2， object））
想在这个基础上再优化， 提高efficiency
请各位高手指点
网上搜到 multikeymap
不知道有人用过吗？ 能有效解决我的问题吗？
谢谢！ |
t***a
发帖数: 416 | 26 也别大改了，就再建个ConcurrentHashMap> 来提高2号
query的效率。和你原来的map一起用，就当是维护俩索引
【在 p****i 的大作中提到】
: 问题简化下是这样：
: 有一个hash表， key 由两部分组成： K1 and K2
: query hash表的时候希望可以满足以下要求：
: 1 query by K1=V1 only， 返回所有K1=V1的records K2 不计
: 2 query by K2=V2 only， 返回所有K2＝V2的records， K1 不计
: 3 query by K1+K2， 正常。
: 现在的实现是用
: ConcurrentHashMap（K1， concurrentHashMap（K2， object））
: 想在这个基础上再优化， 提高efficiency
: 请各位高手指点
|
J*******n
发帖数: 2901 | |
p****i
发帖数: 6135 | 28 不是很合用啊 最后的hashtable size很大的
【在 t***a 的大作中提到】
: 也别大改了，就再建个ConcurrentHashMap> 来提高2号
: query的效率。和你原来的map一起用，就当是维护俩索引
|
p****i
发帖数: 6135 | 29 都存在
单个都不unique
嗯 或许k2可以简化成 unique的
有什么想法吗？
【在 J*******n 的大作中提到】
: K1, K2保证存在，且都是unique吗？
|
g*****g
发帖数: 34805 | 30 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
三个index
>, >, , V>
算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
实现。
如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
【在 p****i 的大作中提到】
: 问题简化下是这样：
: 有一个hash表， key 由两部分组成： K1 and K2
: query hash表的时候希望可以满足以下要求：
: 1 query by K1=V1 only， 返回所有K1=V1的records K2 不计
: 2 query by K2=V2 only， 返回所有K2＝V2的records， K1 不计
: 3 query by K1+K2， 正常。
: 现在的实现是用
: ConcurrentHashMap（K1， concurrentHashMap（K2， object））
: 想在这个基础上再优化， 提高efficiency
: 请各位高手指点
|
|
|
t***a
发帖数: 416 | 31 对，其实就是index的思路，如果想省一点，可以只做两个index
k1,k2 combine一个，k2再做一个
如果只query k1, 一样可以用那个combine的index做index search
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
: >, >, , V>
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
|
p****i
发帖数: 6135 | 32 我目前的思路也是这样
但觉得不是特别好
要求我的维护三个maps
这个hashtable同时非常同态
增加删除的频率很高
维护开销会比较大
还有更好的方法吗？
btw 你用过multikeymap吗？
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
: >, >, , V>
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
|
g*****g
发帖数: 34805 | 33 你要深度优化，就得说明你的数据量大小，读写的频度，读写latency分别的要求。既
然你在考虑ConcurrentHashMap，我猜想数据量并不算太大，单机能放得下。经验上
ConcurrentHashMap足够了。你需要的是个benchmark test，然后调试一下
ConcurrentHashMap constructor上那三个不同参数，以及hashcode的算法。虽然你要
维护3个map，但性能瓶颈不会在这里，你甚至可以起3个线程同时进行3个map的维护。
如果并行读写很频繁，你多半会发现瓶颈在CPU上。如果不够快，你需要一个cluster。
如果数据量太大，你需要的是像Cassandra的DB。即便到Pegabytes数据量，每秒一万次
读写的级别，也可以把读写控制在几个ms，Twitter就是那么做的。
我不知道你说得是哪个MultiKeyMap的实现，Apache Commons的那个不thread safe。多
半不是你想要的。
【在 p****i 的大作中提到】
: 我目前的思路也是这样
: 但觉得不是特别好
: 要求我的维护三个maps
: 这个hashtable同时非常同态
: 增加删除的频率很高
: 维护开销会比较大
: 还有更好的方法吗？
: btw 你用过multikeymap吗？
|
p****i
发帖数: 6135 | 34 thanks
数据量并没有太大， 2Million records， 总共大约500Mbytes，
现在追求的是micro－second级别的性能优化
题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
production级别的性能。
现在也在想replace呢
【在 g*****g 的大作中提到】
: 你要深度优化，就得说明你的数据量大小，读写的频度，读写latency分别的要求。既
: 然你在考虑ConcurrentHashMap，我猜想数据量并不算太大，单机能放得下。经验上
: ConcurrentHashMap足够了。你需要的是个benchmark test，然后调试一下
: ConcurrentHashMap constructor上那三个不同参数，以及hashcode的算法。虽然你要
: 维护3个map，但性能瓶颈不会在这里，你甚至可以起3个线程同时进行3个map的维护。
: 如果并行读写很频繁，你多半会发现瓶颈在CPU上。如果不够快，你需要一个cluster。
: 如果数据量太大，你需要的是像Cassandra的DB。即便到Pegabytes数据量，每秒一万次
: 读写的级别，也可以把读写控制在几个ms，Twitter就是那么做的。
: 我不知道你说得是哪个MultiKeyMap的实现，Apache Commons的那个不thread safe。多
: 半不是你想要的。
|
g*****g
发帖数: 34805 | 35 这个级别没啥好折腾的，就像我说的调一下ConcurrentHashmap和hashcode足以。你先
写个测试测一下，再考虑是否需要进一步优化。我的预测是平均每个操作低于1ms，CPU
是瓶颈。
Cassandra性能很好，关键是你们会不会用。replication factor, consistency level
都有讲究。
Indexing也很有讲究，比如secondary index, Row range query会导致性能问题，你们
多半用了。
【在 p****i 的大作中提到】
: thanks
: 数据量并没有太大， 2Million records， 总共大约500Mbytes，
: 现在追求的是micro－second级别的性能优化
: 题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
: 不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
: production级别的性能。
: 现在也在想replace呢
|
p****i
发帖数: 6135 | 36 你说的1ms 是millisecond级别的吧
这个级别对我们这个应用来说太corse了
hashcode sounds like a potential way, let me check.
CPU
level
【在 g*****g 的大作中提到】
: 这个级别没啥好折腾的，就像我说的调一下ConcurrentHashmap和hashcode足以。你先
: 写个测试测一下，再考虑是否需要进一步优化。我的预测是平均每个操作低于1ms，CPU
: 是瓶颈。
: Cassandra性能很好，关键是你们会不会用。replication factor, consistency level
: 都有讲究。
: Indexing也很有讲究，比如secondary index, Row range query会导致性能问题，你们
: 多半用了。
|
g*****g
发帖数: 34805 | 37 如果你要追求Microsecond的latency，你需要的就不只是算法了。需要的是整个stack
，从硬件到OS的调优。Oracle的JVM也不合适，你需要realtime JVM，否则一个full GC
多半超时。或者就不该选择Java。
Major stock exchange的latency也要几百纳秒，通常纯C/C++写得，软硬件网络都优化
过。Real time不是我熟悉的范畴。
【在 p****i 的大作中提到】
: 你说的1ms 是millisecond级别的吧
: 这个级别对我们这个应用来说太corse了
: hashcode sounds like a potential way, let me check.
:
: CPU
: level
|
J*******n
发帖数: 2901 | 38 看过一些文章，说Java搞Real time确实不是个好的选择 |
w**z
发帖数: 8232 | 39 +1, 昨天晚上一个Cassandra node 差点oom, trigger full gc, (cms failed mode
), 竟然40秒pause.
stack
GC
【在 g*****g 的大作中提到】
: 如果你要追求Microsecond的latency，你需要的就不只是算法了。需要的是整个stack
: ，从硬件到OS的调优。Oracle的JVM也不合适，你需要realtime JVM，否则一个full GC
: 多半超时。或者就不该选择Java。
: Major stock exchange的latency也要几百纳秒，通常纯C/C++写得，软硬件网络都优化
: 过。Real time不是我熟悉的范畴。
|
w**z
发帖数: 8232 | 40 Cassandra read latency is in millionseconds unless you use row cache. write
latency is in microseconds .
【在 p****i 的大作中提到】
: thanks
: 数据量并没有太大， 2Million records， 总共大约500Mbytes，
: 现在追求的是micro－second级别的性能优化
: 题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
: 不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
: production级别的性能。
: 现在也在想replace呢
|
|
|
p****i
发帖数: 6135 | 41 用不用JAVA不是我说了算啊。。。
确实我们这个领域通常是用C，现在学人赶时髦。。。
【在 J*******n 的大作中提到】
: 看过一些文章，说Java搞Real time确实不是个好的选择
|
p****i
发帖数: 6135 | 42 这个看起来应该可以将将符合我们的要求：
写大约要求 200K Write Per Second
读还好， millisecond应该可以满足了
看了下twitter的数据， 他们的要求是100k WPS
各位大拿， in memory 的java database性能数据有吗？
谢谢
write
【在 w**z 的大作中提到】
: Cassandra read latency is in millionseconds unless you use row cache. write
: latency is in microseconds .
|
g**e
发帖数: 6127 | 43 介绍一下啥系统需要200K write TPS吧
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
|
p****i
发帖数: 6135 | 44 网络处理相关的
【在 g**e 的大作中提到】
: 介绍一下啥系统需要200K write TPS吧
|
g*****g
发帖数: 34805 | 45 你这个看似应该直接上专用硬件，C写firmware。成本还低。
twitter每秒处理200K tweets，是几百个结点的并行处理，不是
单个结点串行每个tweet 5微妙。Java做不到那么低的延迟。
你的数据小，读写频度那么高，应该比较接近路由。
【在 p****i 的大作中提到】
: 网络处理相关的
|
w**z
发帖数: 8232 | 46 200k wps, total 2m records？重复update the same records?
500m, 全放memory 吧， 不需要用cassandra .
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
|
g*****g
发帖数: 34805 | 47 单机内存放得下，但支持不了这个级别latency这么低的读写。
【在 w**z 的大作中提到】
: 200k wps, total 2m records？重复update the same records?
: 500m, 全放memory 吧， 不需要用cassandra .
|
w**z
发帖数: 8232 | 48 如果是对同一个record 重复update ,不知道哪个软件可以做到那么大的量
【在 g*****g 的大作中提到】
: 单机内存放得下，但支持不了这个级别latency这么低的读写。
|
p****i
发帖数: 6135 | 49 update这个一下，最后痛定思痛，
彻底重作design， 把这个multilevel的hashmap彻底不用了
【在 w**z 的大作中提到】
: 如果是对同一个record 重复update ,不知道哪个软件可以做到那么大的量
|
m****r
发帖数: 6639 | 50 for what i understand what you are working on, cassandra is obviously not a
good choice. my feeling is, the kind of performance you need cannot be
achieved by depending on another service over the network.
【在 p****i 的大作中提到】
: thanks
: 数据量并没有太大， 2Million records， 总共大约500Mbytes，
: 现在追求的是micro－second级别的性能优化
: 题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
: 不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
: production级别的性能。
: 现在也在想replace呢
|
