java怎么将数据库的数据做缓存,方便查找。
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了java怎么将数据库的数据做缓存,方便查找。相关的知识,希望对你有一定的参考价值。
最近做一个项目,需要平凡的在一张表根据不同条件查找数据,表中数据非常大。本人想在项目启动的时候将表里面的数据读入内存,然后就直接在内存中查找。请问该用什么结构记录这些数据。如果存入这些数据,又该根据不同的条件去查找数据,就像写sql的where条件一样去查找数据。求大神指教。
内存数据库有现成的redis,高效存取键值对,键设为你的查询条件,值设为你的查询结果转为字符串查询时先从redis取,没有再查数据库,并且设置redis的过期时间,这种方式需要项目对实时性要求不高,这样你才能用缓存,而且如果你的项目没有明显的热点,即没有某些内容确定会多次被查到,那你缓存就不会命中,添加缓存反而影响你得速度
redis是一种nosql的内存数据库,感兴趣你可以了解一下,优点就是性能强劲
数据查询请求多就把结果缓存下来,你查数据库再快也没有直接把结果从内存读出来快
同样的sql请求只有第一次查数据库,之后通通读内存
或者你干脆借助这种思想,创建一个全局的map对象,然后查询条件作key
,结果作value,就省去了了解redis的过程,把整个数据库装内存不太科学,你有多少条数据啊追问
一千多条,以后说不定上万条。这个做起来太恼火了。
追答一千多条数据很少啊,你不用缓存出现性能瓶颈了,你测过了?
追问不是数据大小的问题,而是访问数据库次数频繁,可能每秒上千次
不是数据大小的问题,而是访问数据库次数频繁,可能每秒上千次
参考技术A 你的数据非常大,那你写入内存会不会比较占资源,为什么不用异步刷新,让它显示不部分再慢慢加载追问所有的数据加载完应该只有几十M,最主要是对数据库的访问太平凡,可能1秒中有上千次,所以想做缓存。这和异步加载没关系
追答这个问题以前没做过,帮不了你了
追问还是谢谢了
参考技术B 这么频繁还用数据库干啥,就用内存得了查找Java字节数组的缓存行的开头
对于高性能阻塞布隆过滤器,我想将数据与高速缓存行对齐。 (我知道在C中做这样的技巧比较容易,但我想使用Java。)
我确实有一个解决方案,但我不确定它是否正确,或者是否有更好的方法。我的解决方案尝试使用以下算法查找缓存行的开头:
- 对于每个可能的偏移量o(0..63;我假设高速缓存行长度为64)
- 启动一个从数据[o]读取的线程并将其写入数据[o + 8]
- 在主线程中,将'1'写入数据[o],并等待直到数据[o + 8]结束(等待另一个线程)
- 重复一遍
然后,测量它的速度,基本上是100万个循环(在每个线程中)的增量。我的逻辑是,如果数据在不同的缓存行中,则速度较慢。
这是我的代码:
public static void main(String... args) {
for(int i=0; i<20; i++) {
int size = (int) (1000 + Math.random() * 1000);
byte[] data = new byte[size];
int cacheLineOffset = getCacheLineOffset(data);
System.out.println("offset: " + cacheLineOffset);
}
}
private static int getCacheLineOffset(byte[] data) {
for (int i = 0; i < 10; i++) {
int x = tryGetCacheLineOffset(data, i + 3);
if (x != -1) {
return x;
}
}
System.out.println("Cache line start not found");
return 0;
}
private static int tryGetCacheLineOffset(byte[] data, int testCount) {
// assume synchronization between two threads is faster(?)
// if each thread works on the same cache line
int[] counters = new int[64];
int testOffset = 8;
for (int test = 0; test < testCount; test++) {
for (int offset = 0; offset < 64; offset++) {
final int o = offset;
final Semaphore sema = new Semaphore(0);
Thread t = new Thread() {
public void run() {
try {
sema.acquire();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
for (int i = 0; i < 1000000; i++) {
data[o + testOffset] = data[o];
}
}
};
t.start();
sema.release();
data[o] = 1;
int counter = 0;
byte waitfor = 1;
for (int i = 0; i < 1000000; i++) {
byte x = data[o + testOffset];
if (x == waitfor) {
data[o]++;
counter++;
waitfor++;
}
}
try {
t.join();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
counters[offset] += counter;
}
}
Arrays.fill(data, 0, testOffset + 64, (byte) 0);
int low = Integer.MAX_VALUE, high = Integer.MIN_VALUE;
for (int i = 0; i < 64; i++) {
// average of 3
int avg3 = (counters[(i - 1 + 64) % 64] + counters[i] + counters[(i + 1) % 64]) / 3;
low = Math.min(low, avg3);
high = Math.max(high, avg3);
}
if (low * 1.1 > high) {
// no significant difference between low and high
return -1;
}
int lowCount = 0;
boolean[] isLow = new boolean[64];
for (int i = 0; i < 64; i++) {
if (counters[i] < (low + high) / 2) {
isLow[i] = true;
lowCount++;
}
}
if (lowCount != 8) {
// unclear
return -1;
}
for (int i = 0; i < 64; i++) {
if (isLow[(i - 1 + 64) % 64] && !isLow[i]) {
return i;
}
}
return -1;
}
它打印(示例):
offset: 16
offset: 24
offset: 0
offset: 40
offset: 40
offset: 8
offset: 24
offset: 40
...
所以Java中的数组似乎与8个字节对齐。
你知道GC可以移动对象......所以你完美对齐的数组可能会在以后错位。
我试试ByteBuffer
;我想,一个直接的对齐很多(对页面边界)。
不安全可以为您提供地址,使用JNI,您可以获得固定数组。
首先要做的事情 - java中的所有内容都是8字节对齐,而不仅仅是数组。有一个Java Object Layout的工具,你可以玩。这里的小东西(无关,但相关) - 在java-9
String
(s)内部存储为byte[]
缩小他们的空间为LATIN-1
,因为一切都是8字节对齐,有一个字段coder
(byte
)的添加没有使字符串的任何实例更大 - 有一个足够大的空隙来适应该字节。
您想要对齐的对象访问速度更快的想法是正确的。当多个线程试图访问该数据时,这更加明显,也称为false-sharing
(但我打赌你知道这一点)。顺便说一下,Unsafe
中有一些方法可以显示对象地址,但由于GC
可以移动它们,这对你的要求变得无用。
你会not be the first one试图克服这个。不幸的是,如果你阅读那篇博客文章 - 你会发现,即使是非常有经验的开发人员(我很钦佩)也会失败。众所周知,VM可以删除您认为某些地方需要的检查和代码,尤其是在JIT
C2
启动时。
你真正想要的是:
jdk.internal.vm.annotation.Contended
注解。这是保证缓存行对齐的唯一方法。如果你真的想要阅读可以做的所有其他“技巧”,那么Alekesy Shipilev's的例子就是你要找的那些。
以上是关于java怎么将数据库的数据做缓存,方便查找。的主要内容,如果未能解决你的问题,请参考以下文章