{"id":46583,"date":"2018-03-20T00:00:00","date_gmt":"2018-03-20T07:00:00","guid":{"rendered":"https:\/\/griddb-linux-hte8hndjf8cka8ht.westus-01.azurewebsites.net\/blog\/timeseries-benchmark-comparison-griddb-influxdb\/"},"modified":"2025-11-13T12:54:43","modified_gmt":"2025-11-13T20:54:43","slug":"timeseries-benchmark-comparison-griddb-influxdb","status":"publish","type":"post","link":"https:\/\/www.griddb.net\/en\/blog\/timeseries-benchmark-comparison-griddb-influxdb\/","title":{"rendered":"Time Series Benchmark Comparison with GridDB and InfluxDB"},"content":{"rendered":"

Introduction<\/h2>\n

Fixstars recently performed benchmarks that compared time series databases GridDB<\/a> and InfluxDB<\/a> using one AWS<\/a> instance with a CentOS 6.9 image<\/a>. The tests were done using YCSB-TS<\/a> framework, a fork of YCSB benchmarking tool meant for testing Time Series databases. The tests were ran with two datasets: one which could be held primarily in-memory (100M records) and one that would require performing disk I\/O (400M records).<\/p>\n

Benchmark Results<\/h3>\n

\"\"<\/a><\/p>\n

GridDB’s in-memory oriented architecture outperformed InfluxDB by a noticeable margin. The results provide strong evidence of GridDB being the stronger Time Series<\/a> database. GridDB provided superior performance in both in-memory and out-of-memory operations. Results are shown below.<\/p>\n

GridDB proved to be much more scalable than InfluxDB when the size of the database rose from 100M to 400M records. GridDB was able to maintain the same relative LOAD throughput through this increase. As the size of the database grew, GridDB\u2019s LOAD throughput was also over 6 times higher<\/strong> than InfluxDB. GridDB\u2019s read throughput dropped by around 74%<\/strong> while InfluxDB\u2019s throughput dropped by over 81%<\/strong>. When comparing scan performance, GridDB\u2019s throughput dropped by 60%<\/strong> while InfluxDB\u2019s throughput dropped by over 75%<\/strong>.<\/p>\n

It is also important to note that on average GridDB used less<\/strong> CPU resources than InfluxDB while still managing to provide higher throughput and lower latencies in query (read and scan queries<\/em>) operations.<\/p>\n

Read Performance<\/h4>\n

The read phase of our testing on YCSB-TS performed a series of read queries that would search for rows with a specific TIMESTAMP<\/strong> key. These timestamp keys would be generated by YCSB-TS<\/strong>.<\/p>\n

\n \"\"<\/a> <\/p>\n
\n \u00a0\n <\/div>\n<\/div>\n

When comparing read operations using the 100M record dataset, GridDB had over 8 times<\/strong> the throughput than that InfluxDB. For the 400M record dataset, GridDB had up to 10 times<\/strong> the throughput of InfluxDB. It should also be noted that GridDB had around 10-11%<\/strong> the latency of InfluxDB for read operations.<\/p>\n

Scan Performance<\/h4>\n

The scan workload would perform a series of general Scan<\/em> queries or aggregation queries such as AVERAGE, SUM, and COUNT. All scan operations would use a random time-range<\/em> generated by YCSB-TS<\/strong>.<\/p>\n

\n\"\"<\/a>
\n \u00a0\n <\/div>\n<\/div>\n

YCSB-TS measured the throughput for all scan operations (SCAN, COUNT, AVERAGE, SUM) during testing. On the 100 million record dataset, GridDB had around 5 times<\/strong> the throughput of InfluxDB. With a dataset of 400 million records, GridDB maintained 4 times<\/strong> the throughput of InfluxDB.<\/p>\n

For general SCAN operations (not an aggregation operation<\/em>), GridDB had only 13%-26%<\/strong> the latency of InfluxDB. In the case of aggregation operations<\/em>, GridDB had 15%-26%<\/strong> the latency of InfluxDB.<\/p>\n

Testing Process<\/h3>\n

A single C4.2xLarge AWS instance was used to run both YCSB-TS and the database that was being tested. Benchmarks began by loading a database of either 100 or 400 million 50 byte records into both GridDB and InfluxDB. Once the load phase completed, YCSB-TS would perform a series of read or scan operations. The data would be distributed amongst 8 containers<\/strong> using 128 threads<\/strong>.<\/p>\n

Reference<\/h3>\n