Why is database caching so important?

The more information you get in the database, the slower it slows down over time. Even database management systems carefully designed to support many concurrent requests will eventually reach their limits.

Database caching is one of the most common strategies for dealing with these performance issues. Caching involves storing the results of database queries in a faster, more accessible location. When done correctly, caching reduces query response time, reduces database load, and reduces costs.

However, caches also need to be handled with care, because they actually create another copy of information in another location. Keeping databases and caches in sync and up to date can be trickier than you might expect. In the next section, we’ll discuss some of the most common database caching strategies.

What are the different caching strategies?

Manual caching (also known as cache shelving strategy) involves directly managing the database and cache. Your application checks the cache before starting a database query and updates the cache after making any changes to the database.

While effective if implemented correctly, manual caching can be cumbersome, especially if you need to query multiple databases. For these reasons, developers have invented many alternative caching strategies.

Direct read cache policy

In the read cache, the application first queries the cache to see if the information it needs is internal. If not, it retrieves the information from the database and uses it to update the cache. The cache provider or cache library is responsible for querying and updating the cache’s detailed logic.

Read strategies are best suited to reading heavy workloads when applications repeatedly request the same data: for example, news sites that load the same articles over and over again.

One disadvantage of the read strategy is that the first query against the cache will always result in a miss because the requested information is guaranteed not to be internal. To get around this, developers often “heat up” the cache ahead of time with information that users might require.

Direct write cache policy

In a direct write cache, the cache is updated first and then the database is updated. There is a direct line from the application to the cache and from the cache to the database. When used in conjunction with direct reading caching, the direct write strategy ensures that your data remains consistent without manual cache invalidation.

Write after cache strategy

In a write-back cache (also known as a write-back cache), the application first writes data to the cache. After a set delay, the cache also writes this information to the database. The post-write cache is best for writing heavy workloads and performs well even with some failures and outages.

Java-based Redis cache with Redisson

Redis, one of the most popular options for NoSQL databases, uses a key-value system to store data. Redisson is a Redis client library in the Java programming language that allows easy access to Redis functionality using all familiar Java collections.

Redisson allows you to put data in a map in external storage. You can use this feature to cache databases, Web services, or any other data source.

Direct reading cache in Redis

Here is a Java example of how to use direct reading caching in Redis and Redisson.

If the requested entry does not exist in the cache, it will be loaded by the MapLoader object:

MapLoader<String, String> mapLoader = new MapLoader<String, String>() {
    @Override
    public Iterable<String> loadAllKeys() {
        List<String> list = new ArrayList<String>();
        Statement statement = conn.createStatement();
        try {
            ResultSet result = statement.executeQuery("SELECT id FROM student");
            while (result.next()) {
                list.add(result.getString(1));
            }
        } finally {
            statement.close();
        }
        return list;
    }
    @Override
    public String load(String key) {
        PreparedStatement preparedStatement = conn.prepareStatement("SELECT name FROM student where id = ?");
        try {
            preparedStatement.setString(1, key);
            ResultSet result = preparedStatement.executeQuery();
            if (result.next()) {
                return result.getString(1);
            }
            returnnull; } finally { preparedStatement.close(); }}};Copy the code

Configuration example:

MapOptions<K, V> options = MapOptions.<K, V>defaults()
                              .loader(mapLoader);
RMap<K, V> map = redisson.getMap("test", options);
// or
RMapCache<K, V> map = redisson.getMapCache("test", options);
// or with boost up to 45x times 
RLocalCachedMap<K, V> map = redisson.getLocalCachedMap("test", options);
// or with boost up to 45x times 
RLocalCachedMapCache<K, V> map = redisson.getLocalCachedMapCache("test", options);
Copy the code

Direct write cache in Redis

Here is a Java example of how to use MapWriter direct write caching in Redis.

The cache update method does not return until the MapWriter object updates the cache and database:

MapWriter<String, String> mapWriter = new MapWriter<String, String>() {
    @Override
    public void write(Map<String, String> map) {
        PreparedStatement preparedStatement = conn.prepareStatement("INSERT INTO student (id, name) values (? ,?) ");
        try {
            for (Entry<String, String> entry : map.entrySet()) {
                preparedStatement.setString(1, entry.getKey());
                preparedStatement.setString(2, entry.getValue());
                preparedStatement.addBatch();
            }
            preparedStatement.executeBatch();
        } finally {
            preparedStatement.close();
        }
    }
    @Override
    public void delete(Collection<String> keys) {
        PreparedStatement preparedStatement = conn.prepareStatement("DELETE FROM student where id = ?");
        try {
            for(String key : keys) { preparedStatement.setString(1, key); preparedStatement.addBatch(); } preparedStatement.executeBatch(); } finally { preparedStatement.close(); }}};Copy the code

Configuration example:

MapOptions<K, V> options = MapOptions.<K, V>defaults()
                              .writer(mapWriter)
                              .writeMode(WriteMode.WRITE_THROUGH);
RMap<K, V> map = redisson.getMap("test", options);
// or
RMapCache<K, V> map = redisson.getMapCache("test", options);
// or with boost up to 45x times 
RLocalCachedMap<K, V> map = redisson.getLocalCachedMap("test", options);
// or with boost up to 45x times 
RLocalCachedMapCache<K, V> map = redisson.getLocalCachedMapCache("test", options);
Copy the code

The afterwrite cache in Redis

The MapWriter interface is also used to asynchronously commit updates to Map objects (caches) and external storage (databases). All map updates are accumulated on a batch basis and written asynchronously at a defined delay.

writeBehindDelay

– Batch write or delete delay. The default value is 1000 milliseconds.

writeBehindBatchSize

– Batch size. Each batch contains a Map Entry write or delete command. The default value is 50.

Below, we see an example of a Java configuration based on the Redis post-write cache implementation in Redisson:

MapOptions<K, V> options = MapOptions.<K, V>defaults()
                              .writer(mapWriter)
                              .writeMode(WriteMode.WRITE_BEHIND)
                              .writeBehindDelay(5000)
                              .writeBehindBatchSize(100);
RMap<K, V> map = redisson.getMap("test", options);
// or
RMapCache<K, V> map = redisson.getMapCache("test", options);
// or with boost up to 45x times 
RLocalCachedMap<K, V> map = redisson.getLocalCachedMap("test", options);
// or with boost up to 45x times 
RLocalCachedMapCache<K, V> map = redisson.getLocalCachedMapCache("test", options);
Copy the code

All the discussed policies can be implemented using RMapCache, RLocalCachedMap, and RLocalCachedMapCache objects in Redisson. Using the latter two objects can make read operations in Redis 45 times faster.

dzone.com/articles/da…

Check out more articles: www.apexyun.com

Public id: Galaxy 1

Contact email: [email protected]

(Please do not reprint without permission)