VictoriaMetrics, TimescaleDB và InfluxDB được so sánh trong trên tập dữ liệu có một tỷ điểm dữ liệu thuộc chuỗi thời gian duy nhất 40K.
Vài năm trước có kỷ nguyên của Zabbix. Mỗi máy chủ kim loại trần không có nhiều hơn một vài chỉ số - mức sử dụng CPU, mức sử dụng RAM, mức sử dụng ổ đĩa và mức sử dụng mạng. Bằng cách này, số liệu từ hàng nghìn máy chủ có thể phù hợp với 40 nghìn chuỗi thời gian duy nhất và Zabbix có thể sử dụng MySQL làm phụ trợ cho dữ liệu chuỗi thời gian :)
Hiện tại một mình với cấu hình mặc định cung cấp hơn 500 số liệu trên máy chủ trung bình. Có nhiều cho nhiều cơ sở dữ liệu, máy chủ web, hệ thống phần cứng, v.v. Tất cả chúng đều cung cấp nhiều số liệu hữu ích. Tất cả bắt đầu thiết lập các chỉ số khác nhau cho mình. Có Kubernetes với các cụm và nhóm hiển thị nhiều số liệu. Điều này dẫn đến việc các máy chủ hiển thị hàng nghìn số liệu duy nhất trên mỗi máy chủ. Vì vậy, chuỗi thời gian 40K độc nhất không còn có công suất cao nữa. Nó đang trở thành xu hướng chủ đạo và có thể được xử lý dễ dàng bởi bất kỳ TSDB hiện đại nào trên một máy chủ.
Số lượng lớn các chuỗi thời gian duy nhất tại thời điểm này là gì? Có lẽ là 400K hay 4M? Hay 40m? Hãy so sánh TSDB hiện đại với những con số này.
Cài đặt điểm chuẩn
là một công cụ đo điểm chuẩn tuyệt vời cho TSDB. Nó cho phép bạn tạo số lượng số liệu tùy ý bằng cách chuyển số lượng chuỗi thời gian được yêu cầu chia cho 10 - cờ (trước -scale-var). 10 là số phép đo (số liệu) được tạo trên mỗi máy chủ hoặc máy chủ. Các bộ dữ liệu sau được tạo bằng TSBS cho điểm chuẩn:
- Chuỗi thời gian duy nhất 400K, khoảng thời gian 60 giây giữa các điểm dữ liệu, dữ liệu kéo dài trọn 3 ngày, tổng số điểm dữ liệu ~ 1.7B.
- Chuỗi thời gian duy nhất 4M, khoảng thời gian 600 giây, dữ liệu kéo dài 3 ngày, tổng số điểm dữ liệu ~ 1.7B.
- Chuỗi thời gian duy nhất 40M, khoảng thời gian 1 giờ, dữ liệu kéo dài 3 ngày, tổng số điểm dữ liệu ~ 2.8B.
Máy khách và máy chủ đang chạy trên các phiên bản chuyên dụng trong đám mây của Google. Những phiên bản này có cấu hình sau:
- vCPU: 16
- RAM: 60 GB
- Lưu trữ: Ổ cứng 1TB tiêu chuẩn. Nó cung cấp thông lượng đọc/ghi 120 Mbps, 750 thao tác đọc mỗi giây và 1,5K ghi mỗi giây.
TSDB được trích xuất từ hình ảnh docker chính thức và chạy trong docker với các cấu hình sau:
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metricsCần có giá trị InfluxDB (-e) để hỗ trợ công suất cao. ):
docker run -it --rm -p 8086:8086 -e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 -e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g -e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 -v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdbTimescaleDB (cấu hình được lấy từ tài liệu):
MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432
--shm-size=${SHARED}MB
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data
timescale/timescaledb:latest-pg10 postgres
-cmax_wal_size=${WAL}MB
-clog_line_prefix="%m [%p]: [%x] %u@%d"
-clogging_collector=off
-csynchronous_commit=off
-cshared_buffers=${SHARED}MB
-ceffective_cache_size=${CACHE}MB
-cwork_mem=${WORK}MB
-cmaintenance_work_mem=${MAINT}MB
-cmax_files_per_process=100Trình tải dữ liệu được chạy với 16 luồng song song.
Bài viết này chỉ chứa kết quả cho điểm chuẩn chèn. Kết quả benchmark chọn lọc sẽ được công bố trong một bài viết riêng.
Chuỗi thời gian duy nhất 400K
Hãy bắt đầu với các yếu tố đơn giản - 400K. Kết quả điểm chuẩn:
- VictoriaMetrics: 2,6 triệu điểm dữ liệu mỗi giây; Mức sử dụng RAM: 3 GB; kích thước dữ liệu cuối cùng trên đĩa: 965 MB
- InfluxDB: 1.2 triệu điểm dữ liệu mỗi giây; Mức sử dụng RAM: 8.5 GB; kích thước dữ liệu cuối cùng trên đĩa: 1.6 GB
- Thang thời gian: 849K điểm dữ liệu mỗi giây; Mức sử dụng RAM: 2,5 GB; kích thước dữ liệu cuối cùng trên đĩa: 50 GB
Như bạn có thể thấy từ các kết quả trên, VictoriaMetrics giành chiến thắng về hiệu suất chèn và tỷ lệ nén. Dòng thời gian chiếm ưu thế trong việc sử dụng RAM nhưng sử dụng nhiều dung lượng ổ đĩa - 29 byte cho mỗi điểm dữ liệu.
Dưới đây là biểu đồ sử dụng CPU cho từng TSDB trong quá trình đo điểm chuẩn:
Trên đây là ảnh chụp màn hình: VictoriaMetrics - Tải CPU trong quá trình kiểm tra chèn cho chỉ số 400K duy nhất.
Trên đây là ảnh chụp màn hình: InfluxDB - Tải CPU trong quá trình kiểm tra chèn cho số liệu duy nhất 400K.
Trên đây là ảnh chụp màn hình: TimescaleDB - Tải CPU trong quá trình kiểm tra chèn cho số liệu duy nhất là 400K.
VictoriaMetrics sử dụng tất cả các vCPU hiện có, trong khi InfluxDB sử dụng không đúng mức ~2 trong số 16 vCPU.
Thang thời gian chỉ sử dụng 3-4 trong số 16 vCPU. Tỷ lệ iowait và hệ thống cao trong biểu đồ thang thời gian TimescaleDB cho thấy tình trạng tắc nghẽn trong hệ thống con đầu vào/đầu ra (I/O). Hãy xem biểu đồ sử dụng băng thông đĩa:
Trên đây là ảnh chụp màn hình: VictoriaMetrics - Sử dụng băng thông đĩa trong thử nghiệm chèn cho số liệu duy nhất 400K.
Trên đây là ảnh chụp màn hình: InfluxDB - Sử dụng băng thông đĩa trong quá trình kiểm tra chèn cho số liệu duy nhất 400K.
Trên đây là ảnh chụp màn hình: TimescaleDB - Sử dụng băng thông ổ đĩa trong quá trình kiểm tra chèn cho số liệu duy nhất 400K.
VictoriaMetrics ghi lại dữ liệu ở tốc độ 20 Mbps với tốc độ cao nhất lên tới 45 Mbps. Các đỉnh tương ứng với sự hợp nhất một phần lớn trong cây .
InfluxDB ghi dữ liệu ở tốc độ 160 MB/s, trong khi ổ 1 TB tốc độ ghi 120 MB/s.
TimescaleDB bị giới hạn ở tốc độ ghi là 120 Mbps, nhưng đôi khi nó phá vỡ giới hạn này và đạt giá trị cao nhất là 220 Mbps. Các đỉnh này tương ứng với mức sử dụng CPU không đủ trong biểu đồ trước.
Hãy xem biểu đồ sử dụng đầu vào/đầu ra (I/O):
Trên đây là ảnh chụp màn hình: VictoriaMetrics - Chèn mức sử dụng I/O thử nghiệm cho 400K số liệu duy nhất.
Trên đây là ảnh chụp màn hình: InfluxDB - Chèn mức sử dụng I/O thử nghiệm cho 400K số liệu duy nhất.
Trên đây là ảnh chụp màn hình: TimescaleDB - Chèn mức sử dụng I/O thử nghiệm cho 400K số liệu duy nhất.
Hiện tại rõ ràng là TimescaleDB đang đạt đến giới hạn I/O nên nó không thể sử dụng 12 vCPU còn lại.
Chuỗi thời gian duy nhất 4M
Chuỗi thời gian 4M có vẻ hơi khó khăn. Nhưng các đối thủ cạnh tranh của chúng tôi đã vượt qua kỳ thi này một cách thành công. Kết quả điểm chuẩn:
- VictoriaMetrics: 2,2 triệu điểm dữ liệu mỗi giây; Mức sử dụng RAM: 6 GB; kích thước dữ liệu cuối cùng trên đĩa: 3 GB.
- InfluxDB: 330K điểm dữ liệu mỗi giây; Mức sử dụng RAM: 20,5 GB; kích thước dữ liệu cuối cùng trên đĩa: 18,4 GB.
- TimescaleDB: 480K điểm dữ liệu mỗi giây; Mức sử dụng RAM: 2,5 GB; kích thước dữ liệu cuối cùng trên đĩa: 52 GB.
Hiệu suất của InfluxDB giảm từ 1,2 triệu điểm dữ liệu mỗi giây đối với chuỗi thời gian 400K xuống còn 330K điểm dữ liệu mỗi giây đối với chuỗi thời gian 4M. Đây là một sự sụt giảm hiệu suất đáng kể so với các đối thủ khác. Hãy xem biểu đồ mức sử dụng CPU để hiểu nguyên nhân cốt lõi của sự mất mát này:
Trên đây là ảnh chụp màn hình: VictoriaMetrics - Mức sử dụng CPU trong quá trình kiểm tra chèn cho chuỗi thời gian 4M duy nhất.
Trên đây là ảnh chụp màn hình: InfluxDB - Mức sử dụng CPU trong quá trình kiểm tra chèn cho chuỗi thời gian 4M duy nhất.
Trên đây là ảnh chụp màn hình: TimescaleDB - Mức sử dụng CPU trong quá trình kiểm tra chèn cho chuỗi thời gian 4M duy nhất.
VictoriaMetrics sử dụng gần như toàn bộ năng lượng của bộ xử lý (CPU). Mức giảm ở cuối tương ứng với các lần hợp nhất LSM còn lại sau khi tất cả dữ liệu đã được chèn vào.
InfluxDB chỉ sử dụng 8 trong số 16 vCPU, trong khi TimsecaleDB sử dụng 4 trong số 16 vCPU. Đồ thị của chúng có điểm gì chung? Chia sẻ cao iowait, điều này một lần nữa cho thấy nút cổ chai I/O.
TimescaleDB có thị phần cao system. Chúng tôi giả định rằng công suất cao dẫn đến nhiều lệnh gọi hệ thống hoặc nhiều .
Chúng ta hãy nhìn vào biểu đồ thông lượng đĩa:
Trên đây là ảnh chụp màn hình: VictoriaMetrics - Sử dụng băng thông đĩa để chèn 4M số liệu duy nhất.
Trên đây là ảnh chụp màn hình: InfluxDB - Sử dụng băng thông đĩa để chèn 4M số liệu duy nhất.
Trên đây là ảnh chụp màn hình: TimescaleDB - Sử dụng băng thông đĩa để chèn 4M số liệu duy nhất.
VictoriaMetrics đạt giới hạn cao nhất là 120 MB/s, trong khi tốc độ ghi trung bình là 40 MB/s. Có khả năng là một số phản ứng tổng hợp LSM nặng đã được thực hiện trong thời kỳ cao điểm.
InfluxDB một lần nữa đạt được tốc độ ghi trung bình là 200 MB/s với mức cao nhất lên tới 340 MB/s trên đĩa có giới hạn ghi là 120 MB/s :)
TimescaleDB không còn bị giới hạn đĩa nữa. Nó dường như bị hạn chế bởi một cái gì đó khác liên quan đến tỷ lệ cao системной Tải CPU.
Hãy nhìn vào biểu đồ sử dụng IO:
Trên đây là ảnh chụp màn hình: VictoriaMetrics - Sử dụng I/O trong quá trình kiểm tra chèn cho chuỗi thời gian 4M duy nhất.
Trên đây là ảnh chụp màn hình: InfluxDB - Sử dụng I/O trong quá trình kiểm tra chèn cho chuỗi thời gian 4M duy nhất.
Trên đây là ảnh chụp màn hình: TimescaleDB - Việc sử dụng I/O trong quá trình kiểm tra chèn cho chuỗi thời gian 4M duy nhất.
Các kiểu sử dụng IO phản ánh các kiểu sử dụng băng thông ổ đĩa - InfluxDB bị giới hạn IO, trong khi VictoriaMetrics và TimescaleDB có tài nguyên IO dự phòng.
Chuỗi thời gian duy nhất 40 triệu
Chuỗi thời gian duy nhất 40 triệu là quá lớn đối với InfluxDB :)
Kết quả điểm chuẩn:
- VictoriaMetrics: 1,7 triệu điểm dữ liệu mỗi giây; Mức sử dụng RAM: 29 GB; Dung lượng ổ đĩa sử dụng: 17 GB.
- InfluxDB: Chưa hoàn thành vì yêu cầu hơn 60GB RAM.
- TimescaleDB: 330K điểm dữ liệu mỗi giây, mức sử dụng RAM: 2,5 GB; Dung lượng ổ đĩa sử dụng: 84GB.
TimescaleDB cho thấy mức sử dụng RAM cực kỳ thấp và ổn định ở mức 2,5 GB - giống như đối với các chỉ số 4M và 400K duy nhất.
VictoriaMetrics tăng dần quy mô với tốc độ 100 nghìn điểm dữ liệu mỗi giây cho đến khi tất cả 40 triệu tên chỉ số được gắn thẻ đều được xử lý. Sau đó, anh ấy đạt được tốc độ chèn ổn định ở mức 1,5-2,0M điểm dữ liệu mỗi giây, do đó kết quả cuối cùng là 1,7 triệu điểm dữ liệu mỗi giây.
Biểu đồ cho chuỗi thời gian duy nhất 40M tương tự như biểu đồ cho chuỗi thời gian duy nhất 4M, vì vậy hãy bỏ qua chúng.
Những phát hiện
- Các TSDB hiện đại có khả năng xử lý các phần chèn cho hàng triệu chuỗi thời gian duy nhất trên một máy chủ. Trong bài viết tiếp theo, chúng tôi sẽ kiểm tra xem TSDB thực hiện lựa chọn tốt như thế nào trên hàng triệu chuỗi thời gian duy nhất.
- Việc sử dụng CPU không đủ thường biểu thị tình trạng tắc nghẽn I/O. Nó cũng có thể chỉ ra rằng việc chặn quá thô, chỉ có một vài luồng có thể chạy cùng một lúc.
- Nút cổ chai I/O tồn tại, đặc biệt là trong bộ lưu trữ không phải SSD, chẳng hạn như các thiết bị khối ảo hóa của nhà cung cấp đám mây.
- VictoriaMetrics cung cấp giải pháp tối ưu hóa tốt nhất cho việc lưu trữ I/O chậm, thấp. Nó cung cấp tốc độ tốt nhất và tỷ lệ nén tốt nhất.
Tải xuống và thử nó trên dữ liệu của bạn. Mã nhị phân tĩnh tương ứng có sẵn tại .
Đọc thêm về VictoriaMetrics trong phần này .
Cập nhật: đã xuất bản với kết quả có thể lặp lại.
Cập nhật #2: Đọc thêm .
Cập nhật số 3: !
Trò chuyện điện tín:
Nguồn: www.habr.com
