OpenTSDB is a scalable distributed time series database service that uses Apache HBase for underlying storage. OpenTSDB is a typical time series database service that is developed based on general-purpose storage. OpenTSDB was one of the first time series database services available and is recognized in time series database markets. Lindorm Time Series Database (TSDB) is highly compatible with OpenTSDB protocols. TSDB uses methods that are developed by Alibaba Cloud to provide powerful capabilities to process time series data. The methods include indexing, data models, and streaming aggregation. This topic describes the advantages of TSDB over OpenTSDB based on operations, administration and management, features, costs, and performance.

Background information

OpenTSDB TSDB
Operations, administration and management Service availability You must create clusters and add dependencies of components to ensure that your service is available. 99.9%
Data durability You must create clusters and add dependencies of components to ensure that your service is available. 99.9999%
Software and hardware costs The cost of database servers is high. You do not need to deploy software or hardware. You are charged based on the resources that you use.
Maintenance costs You must hire database administrators (DBAs) to maintain your TSDB databases. This requires high labor costs. TSDB allows you to deploy managed databases.
Deployment and expansion You must purchase hardware, host your databases in data centers, and deploy database servers. This requires a long period of time. TSDB can be activated in a few clicks. You can deploy and expand TSDB databases within a few minutes.
Management of component dependencies You must add component dependencies, such as the AysncHBase and HBase dependencies. This increases maintenance costs. You do not need to perform O&M operations on TSDB databases.
Parameter tuning You must use multiple parameters to configure database settings. For example, you use parameters to configure the salt, the number of connections, the synchronous flushing mode, and the compaction setting. Default parameter settings are configured for your business scenario based on best practices.
Statements that are used to create tables O&M operations must be performed on static statements that are used to create tables. TSDB can help you manage statements that are used to create tables. The process is transparent to users.
Monitoring and alerting systems You must use external tools to build a monitoring system. TSDB provides a built-in complete monitoring system.
Features Data models OpenTSDB supports only the single-value model. TSDB supports the multi-value and single-value models.
SDK OpenTSDB SDK is an open source tool that cannot be used to query data. TSDB SDK for Java provides robust and stable features.
Support for data types OpenTSDB supports numeric data types. TSDB supports multiple data types, such as numeric, Boolean, and string.
SQL queries OpenTSDB does not support SQL queries. TSDB allows you to execute SQL statements to analyze and query data.
Management console OpenTSDB provides a built-in system to display data in simple graphs. Multiple features are available in the TSDB console, such as multidimensional data visualization, data management, and insights into time series data.
Support for Chinese characters OpenTSDB supports only letters. TSDB supports letters and Chinese characters.
Single dimension (the tags parameter) The tags parameter is required. The tags parameter is optional.
Number of tag keys A maximum of eight tag keys are supported. A maximum of 16 tag keys are supported.
Integration capabilities OpenTSDB is an open source database service that cannot be fully integrated into Alibaba Cloud services. TSDB supports various ecosystems and can be fully integrated into Flink and IoT Platform.
Costs Data compression OpenTSDB uses common compression algorithms that return a low compression ratio. TSDB uses a compression algorithm that is dedicated to time series data to ensure a high compression ratio.
Stability Data read OpenTSDB couples data reads and writes. This can exhaust the connection resources and increase the risk of read/write failures. TSDB separates read threads from write threads by using different thread pools. This simplifies connection management and delivers stable performance for read and write operations.
Aggregators OpenTSDB uses in-memory aggregation. This can cause out of memory exception errors. TSDB uses streaming aggregation and fine-grained memory management to ensure that you can manage all features.

Compatibility with OpenTSDB protocols

The underlying technical architecture of TSDB is significantly different from that of OpenTSDB. TSDB may be incompatible with the API operations that are provided by OpenTSDB for O&M. For example, TSDB is incompatible with the API endpoints /api/tree and /api/uid that are provided by OpenTSDB to manage metadata information. For more information about the API endpoints that are provided by OpenTSDB, visit http://opentsdb.net/docs/build/html/api_http/index.html. The following table describes the compatibility of TSDB with OpenTSDB.

API endpoint in OpenTSDB Compatible with TSDB
/s No
/api/aggregators Yes
/api/annotation No
/api/config Yes
/api/dropcaches No
/api/put Yes
/api/rollup No
/api/histogram No
/api/query Yes
/api/query/last Yes
/api/search/lookup Yes
/api/serializers Yes
/api/stats Yes
/api/suggest Yes
/api/tree No
/api/uid No
/api/version Yes

TSDB also provides custom API endpoints for time series data. The following table describes the custom API endpoints.

Custom API endpoint in TSDB Description
/api/mput Writes multi-value data.
/api/mquery Queries multi-value data.
/api/query/mlast Queries the most recent data points from time series that use the multi-value data model.
/api/dump_meta Queries tag values that are paired with a tag key.
/api/ttl Specifies the time to live (TTL) for data.
/api/delete_data Deletes data.
/api/delete_meta Deletes a time series.

Performance comparison

Test data description

This section uses a dataset as an example to test the query performance. The data that is used in the performance test is described by using the following parameters:

metric

The name of each metric is prefixed with m.

tagkv

The following table lists five tag key-value pairs. For the first four tag key-value pairs, a total of 2,000,000 time series can be created based on the equation 10 × 20 × 100 × 100 = 2,000,000. The last tag key ip corresponds to 2,000,000 time series, and the tag value increases in increments of 1.

tag_k tag_v
zone z1~z10
cluster c1~c20
group g1~100
app a1~a100
ip ip1~ip2000000

value

Each metric value is a random value that ranges from 1 to 100.

interval

The collection interval is 10 seconds, and data is collected for three consecutive hours. In this case, the total number of data points that can be collected is calculated based on the following equation: 3 × 60 × 60/10 × 2,000,000 = 2,160,000,000.

Statistical result

The following table describes the configuration items of stress testing.

Configuration item Value Description
Stress testing duration (minutes) 3
Stress testing mode Fixed In fixed mode, the concurrency of the stress testing is not adjusted. In layered and pulse modes, the concurrency is adjusted.
Number of stress testers 5
Transactions per second (TPS) per stress tester 1000
Timeout period for obtaining connection details (milliseconds) 600000
Timeout period for establishing connections (milliseconds) 600000
Timeout period for querying data (milliseconds) 600000 Large queries are time-consuming. A timeout exception error can cause inaccurate TPS statistical results.
Calling method Synchronous

The database service is restarted before each stress test is performed. This prevents previous stress tests from using resources. Preloading is also performed for the test operations. If preloading is not performed, an exceedingly long period of time may be required to respond to the first request. This affects the accuracy of response time (RT) statistical results.

Test environment description

Server configurations

Server for write operations: 2 cores and 8 GB memory

Server for data queries: 64 cores and 256 GB memory

ApsaraDB for HBase server: 8 cores and 16 GB memory (a total of five servers)

Database versions

OpenTSDB: OpenTSDB V2.3.2 and ApsaraDB for HBase V1.5.0.1

TSDB: TSDB V2.4.2

Write performance comparison

Scenarios

If the preceding stress test configurations are used, five stress testers are available and the TPS of each stress tester is 1,000. In this case, a maximum of 5,000 data points can be written every second during stress testing. To ensure that the test results show the actual database performance, perform synchronous write operations on TSDB and OpenTSDB databases. The feature that is used to flush data to disks must be enabled for TSDB databases and OpenTSDB databases. TSDB and OpenTSDB use the following formula to calculate the timestamps of data points: Timestamp = Specified time (base_time) + Interval × N. In this formula, N specifies the number of operation calls, and base_time specifies the specified point in time at which a data point is collected. The base_time value increases when the N value increases. TSDB and OpenTSDB collect data points at different intervals.

Interval (seconds) Metric Tag
Scenario 1 10 1 4tagk * 2500tagv
Scenario 2 10 10 4tagk * 2500tagv
Scenario 3 60 1 4tagk * 2500tagv
Scenario 4 60 10 4tagk * 2500tagv

Test results in TSDB

Scenario TPS RT(ms) MinRT MaxRT 80%RT 95%RT 99%RT
Scenario 1 4194.23 149.91 36.9 1808.0 210.42 239.11 250.38
Scenario 2 4223.09 148.4 37.2 474.22 209.74 238.32 248.52
Scenario 3 4225.24 150.37 37.09 645.57 211.22 239.01 249.88
Scenario 4 4227.01 148.61 37.4 888.72 209.93 238.68 249.38

Test results in OpenTSDB

Scenario TPS RT(ms) MinRT MaxRT 80%RT 95%RT 99%RT
Scenario 1 1008.12 832.68 47.19 1310.56 1158.44 1255.66 1283.67
Scenario 2 1094.4 770.82 43.64 1469.04 1078.78 1238.06 1281.69
Scenario 3 804.82 1047.59 132.18 1297.71 1188.12 1269.82 1281.32
Scenario 4 1039.72 807.29 44.43 1421.03 1110.46 1242.02 1281.76

Compare query performance of TSDB and OpenTSDB databases

Scenarios

If the preceding stress test configurations are used, five stress testers are available and the queries per second (QPS) of each stress tester is 1,000. In this case, a maximum of 5,000 data points can be queried every second during stress testing. The datasets for queries are larger than the datasets for write operations. If 5,000 queries are sent every second during stress testing, dry-run issues can occur if the number of queries in the queue exceeds the upper limit. In this example, 5,000 is the maximum QPS. This ensures the accuracy of test results. Before stress testing is performed, TSDB and OpenTSDB check the database server logs and the used resources to ensure that the databases are stably running. In Scenario 5 to Scenario 8, queries are performed based on the entire dataset. OpenTSDB becomes unavailable in these scenarios, even if the number of concurrent query requests is reduced from 5,000 to 500, 50, 5, or 1. In this example, N/A indicates that the database service is unavailable. In the following tables, 0 indicates that the database service is unavailable.

Metric Number of tags (pairs of tag keys and tag values) Time range
Scenario 1 1 1 5min
Scenario 2 1 10 5min
Scenario 3 1 100 5min
Scenario 4 1 1000 5min
Scenario 5 1 1 3hour
Scenario 6 1 10 3hour
Scenario 7 1 100 3hour
Scenario 8 1 1000 3hour

Query statements

# 5min
null
null
null
null
# 3hour
null
null
null
null

Test results in TSDB

Scenario TPS RT(ms) MinRT MaxRT 80%RT 95%RT 99%RT
Scenario 1 3831.8 44.14 36.94 416.98 44.51 46.73 75.5
Scenario 2 1148.22 657.77 105.96 1054.96 715.5 745.87 796.8
Scenario 3 215.96 3522.96 557.81 4067.14 3679.5 3786.29 3854.57
Scenario 4 39.37 19692.53 1784.93 22370.1 - - -
Scenario 5 2856.1 262.76 41.29 847.01 296.99 443.52 489.4
Scenario 6 446.54 1684.15 67.75 2161.85 1802.8 1898.0 1959.02
Scenario 7 69.25 11237.9 1873.55 12776.56 11917.05 12133.61 12316.79
Scenario 8 11.76 65615.45 5742.12 86952.76 - - -

Test results in OpenTSDB

Scenario TPS RT(ms) MinRT MaxRT 80%RT 95%RT 99%RT
Scenario 1 1.97 77842.67 10486.16 109650.51 - - -
Scenario 2 1.95 78062.6 12723.96 119911.53 - - -
Scenario 3 1.96 78865.02 15942.89 141365.75 - - -
Scenario 4 1.97 77331.91 7780.02 113582.65 - - -
Scenario 5 N/A N/A N/A N/A N/A N/A N/A
Scenario 6 N/A N/A N/A N/A N/A N/A N/A
Scenario 7 N/A N/A N/A N/A N/A N/A N/A
Scenario 8 N/A N/A N/A N/A N/A N/A N/A