SQL Server as key-value store versus Redis

| category: Testing | author: st
Tags: , ,

Any considerations and improvements of this test are welcome.

Motivation

Redis is a performant solution for application level cache. However, when a system have already running instances of SQL Server, do you really need Redis in addition?

The main argument I expected to hear is the Redis performance. Let's check if this statement has some proofs.

Environment

As an SQL Server certified expert I could up its performance results for specific cases. However, it is not the goal. Let's take both products "out of the box".

For the fair results I just take:

  • SQL Server container: version 2022 (16.x) under Linux Ubuntu 22.04 LTS
  • Redis container: version 7.1.4 "latest" under Debian 12 (Bookworm slim)
  • run these two containers on a laptop PC

Host PC:

  • CPU i7-1370P: 12 cores, hyperthreading is off
  • RAM 32 GB
  • OS Ubuntu 22.04 LTS
  • Docker version 20.10.21, build 20.10.21-0ubuntu1~22.04.3

Testing scenario

Both databases contain one million "key-value" pair. The key is of UUID (GUID) type, and the values are randomly generated strings of 100 characters of length.

The test performs random access concurrent readings from N threads in cycles of M requests.

Example of SQL Server query (pseudo code):

v = Exec("SELECT v FROM kv WHERE k = <UUID>").Scalar()

Example of Redis query:

v = db.StringGet(uuid)

Testing program

Full sources are available on my GitHub repository.

Initializing of testing data is written as SQL Server script 00_prepare_data.sql that:

  • creates a test SQL Server database
  • creates a key-value table
  • fill table with test data (data is persistent)

Testing program is written on C#, framework version is 8.0.404.

Build:

$ dotnet build -c Release

Running parameters

$ ./MSSQLvsRedis [Number of threads] [requests per thread]
  • Number of threads is 10 by default
  • Requests per thread is 1000 by default

Pay attention that the very first run will takes a time: the program is loading data to Redis store. BTW, SQL Server loading of these data is much faster (bulk load), but this is not the test subject.

Results

For the random access concurrent reading test SQL Server is generally faster than Redis.

It does not mean that "SQL Server is better", but apparently you need other technical arguments to approve Redis usage in addition to existing DBMS. Remember also that SQL Server performance is not gratis, and other "free" (free of license charges) DBMS would be much less performant.

You may take a look on the full results in the results.xlsx file.

Notes

There are several ways to improve SQL Server performance.

First of all, Redis is expected to be running inside a container, whereas SQL Server is running usually on the dedicated server (even hardware server).

Secondly, GUID type for the keys is not the best choice, and its performance is about 30% lower than for integer value keys. Testing GUIDs are also fragmented, there is an option to use newsequentialid() function to avoid it.

Furthermore, SQL server performance under the Linux OS may be lower than under "native" Windows regardless the SQL OS implemented inside the DBMS.


blog comments powered by Disqus