All Products
Search
Document Center

Advantages over OpenTSDB

Last Updated: Jun 15, 2020

OpenTSDB is a scalable distributed time series database, and uses Apache HBase as the data storage system. OpenTSDB is a typical time series database that is developed based on general-purpose storage. It is released at an earlier stage than most time series databases, and wins high recognition from users in the market. Alibaba Cloud Time Series Database (TSDB) is highly compatible with the OpenTSDB protocol. TSDB provides powerful time series capabilities by using technologies that are developed by Alibaba Cloud, such as technologies for indexing, data models, and streaming aggregation. This topic describes the advantages of Alibaba Cloud TSDB and OpenTSDB in terms of operations and maintenance (O&M), features, costs, and performance.

Comparison between Alibaba Cloud TSDB and OpenTSDB

OpenTSDB TSDB
O&M Service availability You must ensure service availability, create clusters, and add component dependencies by yourself. 99.9%
Data reliability You must ensure data reliability, create clusters, and add component dependencies by yourself. 99.9999%
Software and hardware The cost of database servers is high. You do not need to deploy software or hardware. You are billed based on your actual resource usage.
Maintenance cost You must employ full-time TSDB database administrators (DBAs) for O&M, which increases the costs for human resources. TSDB provides managed services.
Deployment and scaling You must purchase hardware devices, manage data centers that host your databases, and deploy database servers. The deployment and scaling processes are time-consuming. TSDB supports quick activation, fast deployment, and elastic scaling.
Component dependency OpenTSDB depends on AysncHBase and Apache HBase, which incurs high O&M costs. No O&M costs are incurred.
Parameters for configuration and optimization You must specify a lot of parameters for configuration and optimization, such as salting parameters, number of connections, synchronous flushing parameters, and compaction parameters. By default, parameter settings in the best practices are used.
Statements for creating tables You must perform O&M on the static statements that are used to create tables. TSDB provides managed services for the statements that are used to create tables. You do not need to worry about the relevant details.
Monitoring and alerting OpenTSDB relies on external systems for monitoring and alerting. TSDB provides end-to-end monitoring services.
Features Data models OpenTSDB supports the single-value data model. TSDB supports multi-value and single-value data models.
SDK OpenTSDB provides open source SDKs that do not support queries. TSDB provides robust and stable Java SDKs.
Supported data types OpenTSDB supports the numeric data type. TSDB supports multiple data types, including numeric, boolean, and string.
SQL query OpenTSDB does not support SQL queries. TSDB supports SQL analysis and queries.
Console The OpenTSDB console provides limited UI elements for data display. The TSDB console provides a wide range of UI elements for various features, such as detail display, data management, and time series insights.
Support for Chinese characters Only English characters are supported. Both English and Chinese characters are supported.
Single dimension (tags parameter) The tags parameter is required. The tags parameter is optional.
Number of tag keys You can specify a maximum of 8 tag keys. You can specify a maximum of 16 tag keys.
Integration with other cloud products OpenTSDB is an open source database service, and can be integrated with limited cloud products. TSDB supports seamless integration with various cloud services in an inclusive ecosystem, such as Apache Flink and IoT Platform.
Costs Data compression OpenTSDB supports general data compression. The data compression rate is low. TSDB supports data compression that is specific to the time series fields. The data compression rate is high.
Stability Data reading Read and write thread pools are not separated. This results in higher possibilities that all connections are occupied and read/write errors occur. The read thread pool is separated from the write thread pool. This makes it easy to manage connections and helps you to ensure that read and write operations are performed as expected.
Aggregator OpenTSDB supports in-memory aggregation, which easily causes out-of-memory (OOM) exceptions. TSDB supports streaming aggregation. This allows you to implement fine-grained memory management and gain more control over memory resources.

Compatibility with the OpenTSDB protocol

The underlying technical architecture of Alibaba Cloud TSDB is different from that of OpenTSDB. Therefore, TSDB is incompatible with certain O&M API endpoints of OpenTSDB. For example, TSDB does not support the /api/tree and /api/uid API endpoints that are provided by OpenTSDB to manage metadata. The following table lists certain OpenTSDB API endpoints(http://opentsdb.net/docs/build/html/api_http/index.html), and specifies whether TSDB is compatible with these endpoints.

OpenTSDB API endpoint Whether TSDB is compatible with the API endpoint
/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 API endpoints that are specific to the time series fields. These endpoints are listed in the following table.

API endpoint (custom protocol) Description
/api/mput Writes multi-value data.
/api/mquery Queries multi-value data.
/api/query/mlast Queries the latest data points in the multi-value data model.
/api/dump_meta Queries the tag values of a tag key.
/api/ttl Sets the data time-to-live (TTL) of data.
/api/delete_data Deletes data.
/api/delete_meta Deletes a specified timeline.

Performance comparison

Test data description

This topic uses a dataset as an example to test the query performance. The dataset is described from the following aspects: metric, timeline, metric values, and data collection interval.

Metric

A metric is permanently set to m.

Tag key-value pair

The following table lists 5 tag key-value pairs. Based on the first 4 tag key-value pairs, a total of 2,000,000 (10 × 20 × 100 × 100 = 2,000,000) timelines are created. The last tag key ip corresponds to the 2,000,000 timelines, and the tag value increments from 1.

Tag key Tag value
zone z1-z10
cluster c1-c20
group g1-g100
app a1-a100
ip ip1-ip2000000

Value

The metric value is a random value within the range of [1, 100 ].

interval

The data collection interval is 10 seconds, and data is collected for three consecutive hours. In this case, the total number of data points is calculated based on this formula: 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 model A fixed value The concurrency of the stress testing is not adjusted in the fixed stress model. In the layered stress model and pulse stress model, the concurrency is adjusted.
Number of stress testers 5
Transactions per second (TPS) per stress tester 1000
Time-out for obtaining connection details (milliseconds) 600,000
Time-out for establishing connections (milliseconds) 600,000
Time-out for requesting data (milliseconds) 600,000 Large queries are time-consuming. A time-out exception may cause inaccuracy of TPS statistical result.
Calling method Synchronous

The database service is restarted before each stress test is performed. The purpose is to prevent previous stress tests from occupying resources. Preloading is also performed for the test operations. If preloading is not performed, an excessively long period 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 servers: 8 cores and 16 GB memory (5 servers)

Database versions

OpenTSDB: OpenTSDB 2.3.2 and ApsaraDB for HBase 1.5.0.1

TSDB: TSDB 2.4.2

Write performance comparison

Scenarios

Based on the preceding stress test configurations, 5 stress testers are available and the TPS of each stress tester is 1,000. Therefore, a maximum of 5,000 transactions (data points) can be written every second in the stress testing. To ensure that the test results show the actual performance of TSDB and OpenTSDB, the stress tests perform synchronous write operations on both TSDB and OpenTSDB. The feature of transferring cache data to disks is also enabled for both TSDB and OpenTSDB. To ensure that data points at various timestamps are collected in each scenario, the stress tests change the timestamps with the increase of service calls based on a specified time. The number of service calls is indicated by N, and the specified time is indicated by base_time. The timestamps is calculated based on this formula: Timestamp = Specified time (base_time) + Interval × N.

Interval (seconds) Metric Tag
Scenario 1 10 1 metric 4 tag keys × 2,500 tag values
Scenario 2 10 10 metrics 4 tag keys × 2,500 tag values
Scenario 3 60 1 metric 4 tag keys × 2,500 tag values
Scenario 4 60 10 metrics 4 tag keys × 2,500 tag values

TSDB performance testing results

Scenario TPS Response time (milliseconds) Minimum response time Maximum response time Response time for 80% write operations Response time for 95% write operations Response time for 99% write operations
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

OpenTSDB performance testing results

Scenario TPS Response time (milliseconds) Minimum response time Maximum response time Response time for 80% write operations Response time for 95% write operations Response time for 99% write operations
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

Query performance comparison

Scenarios

Based on the preceding stress test configurations, 5 stress testers are available and the queries per second (QPS) of each stress tester is 1,000. Therefore, a maximum of 5,000 transactions (data points) can be read every second in the stress testing. The target dataset for queries is larger than that for write operations. If 5,000 queries are sent every second in the stress testing, dry-run issues may occur. This is because the query queue may be full. To ensure the test accuracy, the stress testing uses 5,000 QPS as the upper limit. Before the stress testing is performed, database server logs and resource consumption are checked to ensure the stable running of databases. In scenarios 5 to 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. N/A is used in the following tables to indicate the not available state, and 0 is used in the following charts to indicate this state for subsequent analysis.

Metric Tag (tag key and tag value) Time range
Scenario 1 1 metric 1 tag 5 minutes
Scenario 2 1 metric 10 tags 5 minutes
Scenario 3 1 metric 100 tags 5 minutes
Scenario 4 1 metric 1,000 tags 5 minutes
Scenario 5 1 metric 1 tag 3 hours
Scenario 6 1 metric 10 tags 3 hours
Scenario 7 1 metric 100 tags 3 hours
Scenario 8 1 metric 1,000 tags 3 hours

Query statements

  1. # 5min
  2. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"ip":"i1"}}]}
  3. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1","app":"a1"}}]}
  4. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"zone":"z1","cluster":"c1","group":"h1"}}]}
  5. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1"}}]}
  6. # 3hour
  7. {"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"ip":"i1"}}]}
  8. {"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1","app":"a1"}}]}
  9. {"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"zone":"z1","cluster":"c1","group":"h1"}}]}
  10. {"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1"}}]}

TSDB performance testing results

Scenario TPS Response time (milliseconds) Minimum response time Maximum response time Response time for 80% queries Response time for 95% queries Response time for 99% queries
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 - - -

OpenTSDB performance testing results

Scenario TPS Response time (milliseconds) Minimum response time Maximum response time Response time for 80% queries Response time for 95% queries Response time for 99% queries
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

If the number of concurrent requests is larger than 500, OpenTSDB becomes unavailable in most cases, and TSDB can run stably as expected.