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 API. 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 |