p*i
2 楼
问题简化下是这样：
有一个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
不知道有人用过吗？ 能有效解决我的问题吗？
谢谢！
有一个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
不知道有人用过吗？ 能有效解决我的问题吗？
谢谢！
A*2
3 楼
竹枝
t*a
4 楼
也别大改了，就再建个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
: 请各位高手指点
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
: 请各位高手指点
p*a
5 楼
不错，背景稍显脏，欠变化
J*n
6 楼
K1, K2保证存在，且都是unique吗？
A*2
7 楼
恩，对。谢谢：）
【在 p*****a 的大作中提到】
: 不错，背景稍显脏，欠变化
【在 p*****a 的大作中提到】
: 不错，背景稍显脏，欠变化
p*i
8 楼
不是很合用啊 最后的hashtable size很大的
【在 t***a 的大作中提到】
: 也别大改了，就再建个ConcurrentHashMap> 来提高2号
: query的效率。和你原来的map一起用，就当是维护俩索引
【在 t***a 的大作中提到】
: 也别大改了，就再建个ConcurrentHashMap
: query的效率。和你原来的map一起用，就当是维护俩索引
d*w
9 楼
画得挺有意思的，不觉得脏啊
p*i
10 楼
都存在
单个都不unique
嗯 或许k2可以简化成 unique的
有什么想法吗？
【在 J*******n 的大作中提到】
: K1, K2保证存在，且都是unique吗？
单个都不unique
嗯 或许k2可以简化成 unique的
有什么想法吗？
【在 J*******n 的大作中提到】
: K1, K2保证存在，且都是unique吗？
H*9
11 楼
画的很不错啊
【在 A********2 的大作中提到】
: 三角梅
【在 A********2 的大作中提到】
: 三角梅
g*g
12 楼
这个其实就相当个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
: 请各位高手指点
三个index
算法上都是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
: 请各位高手指点
p*a
13 楼
看第二幅瓶子周围，第一副的天有点小脏。个人觉得现在背景的处理方式有点板，如果
再灵动点就完美
了。
【在 d*****w 的大作中提到】
: 画得挺有意思的，不觉得脏啊
再灵动点就完美
了。
【在 d*****w 的大作中提到】
: 画得挺有意思的，不觉得脏啊
t*a
14 楼
对，其实就是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都是可以考虑的选择。
k1,k2 combine一个，k2再做一个
如果只query k1, 一样可以用那个combine的index做index search
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
:
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
f*g
15 楼
喜欢这种简洁风的！
ps，第一个瓶子，如果是圆的，底部的椭圆两端好像应该再圆一些。
ps，第一个瓶子，如果是圆的，底部的椭圆两端好像应该再圆一些。
p*i
16 楼
我目前的思路也是这样
但觉得不是特别好
要求我的维护三个maps
这个hashtable同时非常同态
增加删除的频率很高
维护开销会比较大
还有更好的方法吗？
btw 你用过multikeymap吗？
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
:>, >, , V>
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
但觉得不是特别好
要求我的维护三个maps
这个hashtable同时非常同态
增加删除的频率很高
维护开销会比较大
还有更好的方法吗？
btw 你用过multikeymap吗？
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
:
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
s*h
17 楼
赞
【在 A********2 的大作中提到】
: 三角梅
【在 A********2 的大作中提到】
: 三角梅
g*g
18 楼
你要深度优化，就得说明你的数据量大小，读写的频度，读写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吗？
然你在考虑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吗？
d*w
19 楼
哈，要求太高了，不过要拿完美来要求，我同意你。
如果一定要找毛病，我觉得第一幅瓶子的投影和高光可能有些生硬了，影响意境，但是
整体还是很协调的。
【在 p*****a 的大作中提到】
: 看第二幅瓶子周围，第一副的天有点小脏。个人觉得现在背景的处理方式有点板，如果
: 再灵动点就完美
: 了。
如果一定要找毛病，我觉得第一幅瓶子的投影和高光可能有些生硬了，影响意境，但是
整体还是很协调的。
【在 p*****a 的大作中提到】
: 看第二幅瓶子周围，第一副的天有点小脏。个人觉得现在背景的处理方式有点板，如果
: 再灵动点就完美
: 了。
p*i
20 楼
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。多
: 半不是你想要的。
数据量并没有太大， 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
21 楼
这个级别没啥好折腾的，就像我说的调一下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呢
写个测试测一下，再考虑是否需要进一步优化。我的预测是平均每个操作低于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
22 楼
你说的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会导致性能问题，你们
: 多半用了。
这个级别对我们这个应用来说太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
23 楼
如果你要追求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
，从硬件到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
24 楼
看过一些文章，说Java搞Real time确实不是个好的选择
w*z
25 楼
+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不是我熟悉的范畴。
), 竟然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
26 楼
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呢
latency is in microseconds .
【在 p****i 的大作中提到】
: thanks
: 数据量并没有太大， 2Million records， 总共大约500Mbytes，
: 现在追求的是micro－second级别的性能优化
: 题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
: 不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
: production级别的性能。
: 现在也在想replace呢
p*i
27 楼
用不用JAVA不是我说了算啊。。。
确实我们这个领域通常是用C，现在学人赶时髦。。。
【在 J*******n 的大作中提到】
: 看过一些文章，说Java搞Real time确实不是个好的选择
确实我们这个领域通常是用C，现在学人赶时髦。。。
【在 J*******n 的大作中提到】
: 看过一些文章，说Java搞Real time确实不是个好的选择
p*i
28 楼
这个看起来应该可以将将符合我们的要求：
写大约要求 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 .
写大约要求 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
29 楼
介绍一下啥系统需要200K write TPS吧
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
p*i
30 楼
网络处理相关的
【在 g**e 的大作中提到】
: 介绍一下啥系统需要200K write TPS吧
【在 g**e 的大作中提到】
: 介绍一下啥系统需要200K write TPS吧
g*g
31 楼
你这个看似应该直接上专用硬件，C写firmware。成本还低。
twitter每秒处理200K tweets，是几百个结点的并行处理，不是
单个结点串行每个tweet 5微妙。Java做不到那么低的延迟。
你的数据小，读写频度那么高，应该比较接近路由。
【在 p****i 的大作中提到】
: 网络处理相关的
twitter每秒处理200K tweets，是几百个结点的并行处理，不是
单个结点串行每个tweet 5微妙。Java做不到那么低的延迟。
你的数据小，读写频度那么高，应该比较接近路由。
【在 p****i 的大作中提到】
: 网络处理相关的
w*z
32 楼
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
500m, 全放memory 吧， 不需要用cassandra .
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
g*g
33 楼
单机内存放得下，但支持不了这个级别latency这么低的读写。
【在 w**z 的大作中提到】
: 200k wps, total 2m records？重复update the same records?
: 500m, 全放memory 吧， 不需要用cassandra .
【在 w**z 的大作中提到】
: 200k wps, total 2m records？重复update the same records?
: 500m, 全放memory 吧， 不需要用cassandra .
w*z
34 楼
如果是对同一个record 重复update ,不知道哪个软件可以做到那么大的量
【在 g*****g 的大作中提到】
: 单机内存放得下，但支持不了这个级别latency这么低的读写。
【在 g*****g 的大作中提到】
: 单机内存放得下，但支持不了这个级别latency这么低的读写。
p*i
35 楼
问题简化下是这样：
有一个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
不知道有人用过吗？ 能有效解决我的问题吗？
谢谢！
有一个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
36 楼
也别大改了，就再建个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
: 请各位高手指点
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
37 楼
K1, K2保证存在，且都是unique吗？
p*i
38 楼
不是很合用啊 最后的hashtable size很大的
【在 t***a 的大作中提到】
: 也别大改了，就再建个ConcurrentHashMap> 来提高2号
: query的效率。和你原来的map一起用，就当是维护俩索引
【在 t***a 的大作中提到】
: 也别大改了，就再建个ConcurrentHashMap
: query的效率。和你原来的map一起用，就当是维护俩索引
p*i
39 楼
都存在
单个都不unique
嗯 或许k2可以简化成 unique的
有什么想法吗？
【在 J*******n 的大作中提到】
: K1, K2保证存在，且都是unique吗？
单个都不unique
嗯 或许k2可以简化成 unique的
有什么想法吗？
【在 J*******n 的大作中提到】
: K1, K2保证存在，且都是unique吗？
g*g
40 楼
这个其实就相当个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
: 请各位高手指点
三个index
算法上都是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
41 楼
对，其实就是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都是可以考虑的选择。
k1,k2 combine一个，k2再做一个
如果只query k1, 一样可以用那个combine的index做index search
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
:
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
p*i
42 楼
我目前的思路也是这样
但觉得不是特别好
要求我的维护三个maps
这个hashtable同时非常同态
增加删除的频率很高
维护开销会比较大
还有更好的方法吗？
btw 你用过multikeymap吗？
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
:>, >, , V>
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
但觉得不是特别好
要求我的维护三个maps
这个hashtable同时非常同态
增加删除的频率很高
维护开销会比较大
还有更好的方法吗？
btw 你用过multikeymap吗？
【在 g*****g 的大作中提到】
: 这个其实就相当个DB query。对两个key分别做index是基本的做法。你也可以简单的做
: 三个index
:
: 算法上都是O(1)的实现。实际上追求效率的话，区别一个在于最初建立
: ConcurrentHashMap的原始大小，你希望resize越少越好，另一个在于Key hashcode的
: 实现。
: 如果你的数据量大到内存放不下，Distributed Cache，DB都是可以考虑的选择。
g*g
43 楼
你要深度优化，就得说明你的数据量大小，读写的频度，读写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吗？
然你在考虑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
44 楼
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。多
: 半不是你想要的。
数据量并没有太大， 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
45 楼
这个级别没啥好折腾的，就像我说的调一下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呢
写个测试测一下，再考虑是否需要进一步优化。我的预测是平均每个操作低于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
46 楼
你说的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会导致性能问题，你们
: 多半用了。
这个级别对我们这个应用来说太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
47 楼
如果你要追求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
，从硬件到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
48 楼
看过一些文章，说Java搞Real time确实不是个好的选择
w*z
49 楼
+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不是我熟悉的范畴。
), 竟然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
50 楼
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呢
latency is in microseconds .
【在 p****i 的大作中提到】
: thanks
: 数据量并没有太大， 2Million records， 总共大约500Mbytes，
: 现在追求的是micro－second级别的性能优化
: 题外话： 我们另一个应用用的就是cluster based cassandra， 我觉得性能很差啊，
: 不同node之间的synchronize非常耗时， 而且状态很不稳定。可以用但是远达不到
: production级别的性能。
: 现在也在想replace呢
p*i
51 楼
用不用JAVA不是我说了算啊。。。
确实我们这个领域通常是用C，现在学人赶时髦。。。
【在 J*******n 的大作中提到】
: 看过一些文章，说Java搞Real time确实不是个好的选择
确实我们这个领域通常是用C，现在学人赶时髦。。。
【在 J*******n 的大作中提到】
: 看过一些文章，说Java搞Real time确实不是个好的选择
p*i
52 楼
这个看起来应该可以将将符合我们的要求：
写大约要求 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 .
写大约要求 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
53 楼
介绍一下啥系统需要200K write TPS吧
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
p*i
54 楼
网络处理相关的
【在 g**e 的大作中提到】
: 介绍一下啥系统需要200K write TPS吧
【在 g**e 的大作中提到】
: 介绍一下啥系统需要200K write TPS吧
g*g
55 楼
你这个看似应该直接上专用硬件，C写firmware。成本还低。
twitter每秒处理200K tweets，是几百个结点的并行处理，不是
单个结点串行每个tweet 5微妙。Java做不到那么低的延迟。
你的数据小，读写频度那么高，应该比较接近路由。
【在 p****i 的大作中提到】
: 网络处理相关的
twitter每秒处理200K tweets，是几百个结点的并行处理，不是
单个结点串行每个tweet 5微妙。Java做不到那么低的延迟。
你的数据小，读写频度那么高，应该比较接近路由。
【在 p****i 的大作中提到】
: 网络处理相关的
w*z
56 楼
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
500m, 全放memory 吧， 不需要用cassandra .
【在 p****i 的大作中提到】
: 这个看起来应该可以将将符合我们的要求：
: 写大约要求 200K Write Per Second
: 读还好， millisecond应该可以满足了
: 看了下twitter的数据， 他们的要求是100k WPS
: 各位大拿， in memory 的java database性能数据有吗？
: 谢谢
:
: write
g*g
57 楼
单机内存放得下，但支持不了这个级别latency这么低的读写。
【在 w**z 的大作中提到】
: 200k wps, total 2m records？重复update the same records?
: 500m, 全放memory 吧， 不需要用cassandra .
【在 w**z 的大作中提到】
: 200k wps, total 2m records？重复update the same records?
: 500m, 全放memory 吧， 不需要用cassandra .
w*z
58 楼
如果是对同一个record 重复update ,不知道哪个软件可以做到那么大的量
【在 g*****g 的大作中提到】
: 单机内存放得下，但支持不了这个级别latency这么低的读写。
【在 g*****g 的大作中提到】
: 单机内存放得下，但支持不了这个级别latency这么低的读写。
p*i
59 楼
update这个一下，最后痛定思痛，
彻底重作design， 把这个multilevel的hashmap彻底不用了
【在 w**z 的大作中提到】
: 如果是对同一个record 重复update ,不知道哪个软件可以做到那么大的量
彻底重作design， 把这个multilevel的hashmap彻底不用了
【在 w**z 的大作中提到】
: 如果是对同一个record 重复update ,不知道哪个软件可以做到那么大的量
m*r
60 楼
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呢
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呢
相关阅读
JAX-RPC 是否支持MTOM这样会如何？请问一下about builder pattern问一个Java题Is there shortcut key for expand all in search view for ecl问个设计问题写文件受限的问题看到一个让我~!@#$%^&*的codeA Servlet query string questionjunit test问题问个Spring Framework的数据库设置的问题学struts对学hibernate, spring有触类旁通的作用吗？怎么把其他form加到richtext box( FCKeditor)?问一个Java regexp的题Maven questionthread safe Singleton 的几种方法？问个HttpClient 的问题IntelliJ IDEA 9.0 is released, and with free community editeclipse 做gui问题