มีการเปรียบเทียบ VictoriaMetrics, TimescaleDB และ InfluxDB บนชุดข้อมูลที่มีจุดข้อมูลนับพันล้านจุดซึ่งอยู่ในอนุกรมเวลาที่ไม่ซ้ำกัน 40 ชุด
ไม่กี่ปีที่ผ่านมาเป็นยุคของซับบิกซ์ เซิร์ฟเวอร์ Bare Metal แต่ละตัวมีตัวบ่งชี้ไม่เกินสองสามตัว ได้แก่ การใช้งาน CPU, การใช้งาน RAM, การใช้งานดิสก์ และการใช้งานเครือข่าย ด้วยวิธีนี้ ตัววัดจากเซิร์ฟเวอร์หลายพันเครื่องสามารถใส่ลงในอนุกรมเวลาที่ไม่ซ้ำกันได้ 40 ชุด และ Zabbix สามารถใช้ MySQL เป็นแบ็กเอนด์สำหรับข้อมูลอนุกรมเวลา :)
ปัจจุบันอยู่คนเดียว ด้วยการกำหนดค่าเริ่มต้นให้มากกว่า 500 เมตริกบนโฮสต์โดยเฉลี่ย มีมากมาย สำหรับฐานข้อมูล เว็บเซิร์ฟเวอร์ ระบบฮาร์ดแวร์ ฯลฯ ต่างๆ ทั้งหมดนี้มอบตัวชี้วัดที่มีประโยชน์มากมาย ทั้งหมด เริ่มกำหนดตัวชี้วัดต่างๆ ให้กับตนเอง มี Kubernetes ที่มีคลัสเตอร์และพ็อดที่แสดงเมตริกจำนวนมาก ส่งผลให้เซิร์ฟเวอร์เปิดเผยตัววัดที่ไม่ซ้ำกันหลายพันรายการต่อโฮสต์ ดังนั้นอนุกรมเวลา 40K อันเป็นเอกลักษณ์จึงไม่มีกำลังสูงอีกต่อไป กำลังกลายเป็นกระแสหลักและควรได้รับการจัดการอย่างง่ายดายโดย TSDB สมัยใหม่บนเซิร์ฟเวอร์เดียว
อนุกรมเวลาที่ไม่ซ้ำกันจำนวนมากในขณะนี้คืออะไร? อาจเป็น 400K หรือ 4M? หรือ 40 ม.? ลองเปรียบเทียบ TSDB สมัยใหม่กับตัวเลขเหล่านี้
การติดตั้งเกณฑ์มาตรฐาน
เป็นเครื่องมือเปรียบเทียบที่ยอดเยี่ยมสำหรับ TSDB ช่วยให้คุณสร้างเมตริกตามจำนวนที่ต้องการโดยส่งอนุกรมเวลาที่ต้องการหารด้วย 10 - แฟล็ก (อดีต -scale-var- 10 คือจำนวนการวัด (หน่วยเมตริก) ที่สร้างขึ้นในแต่ละโฮสต์หรือเซิร์ฟเวอร์ ชุดข้อมูลต่อไปนี้ถูกสร้างขึ้นโดยใช้ TSBS สำหรับการวัดประสิทธิภาพ:
- อนุกรมเวลาที่ไม่ซ้ำกัน 400K ช่วงเวลา 60 วินาทีระหว่างจุดข้อมูล ข้อมูลครอบคลุม 3 วันเต็ม จำนวนจุดข้อมูลทั้งหมด ~1.7B
- อนุกรมเวลาที่ไม่ซ้ำกัน 4M ช่วงเวลา 600 วินาที ข้อมูลครอบคลุม 3 วันเต็ม จำนวนจุดข้อมูลทั้งหมด ~1.7B
- อนุกรมเวลาที่ไม่ซ้ำกัน 40M ช่วงเวลา 1 ชั่วโมง ข้อมูลครอบคลุม 3 วันเต็ม จำนวนจุดข้อมูลทั้งหมด ~2.8B
ไคลเอนต์และเซิร์ฟเวอร์กำลังทำงานบนอินสแตนซ์เฉพาะ ในคลาวด์ของ Google อินสแตนซ์เหล่านี้มีการกำหนดค่าต่อไปนี้:
- vCPU: 16
- RAM: 60 GB
- พื้นที่จัดเก็บข้อมูล: HDD มาตรฐาน 1TB ให้ทรูพุตการอ่าน/เขียน 120 Mbps, การอ่าน 750 ครั้งต่อวินาที และการเขียน 1,5K ต่อวินาที
TSDB ถูกแยกออกจากอิมเมจนักเทียบท่าอย่างเป็นทางการและทำงานในนักเทียบท่าด้วยการกำหนดค่าต่อไปนี้:
วิกตอเรียเมตริก:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metricsต้องใช้ค่า InfluxDB (-e) เพื่อรองรับพลังงานสูง ดูรายละเอียดใน ):
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 (การกำหนดค่านำมาจาก ไฟล์):
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=100ตัวโหลดข้อมูลถูกรันด้วยเธรดแบบขนาน 16 เธรด
บทความนี้มีเพียงผลลัพธ์สำหรับการวัดประสิทธิภาพการแทรกเท่านั้น ผลลัพธ์ของการวัดประสิทธิภาพแบบคัดเลือกจะมีการเผยแพร่ในบทความแยกต่างหาก
อนุกรมเวลาที่ไม่ซ้ำกัน 400K
เริ่มจากองค์ประกอบง่ายๆ - 400K ผลลัพธ์มาตรฐาน:
- VictoriaMetrics: จุดข้อมูล 2,6M ต่อวินาที; การใช้งาน RAM: 3 GB; ขนาดข้อมูลสุดท้ายบนดิสก์: 965 MB
- InfluxDB: จุดข้อมูล 1.2M ต่อวินาที; การใช้งาน RAM: 8.5 GB; ขนาดข้อมูลสุดท้ายบนดิสก์: 1.6 GB
- มาตราส่วนเวลา: จุดข้อมูล 849 จุดต่อวินาที; การใช้งาน RAM: 2,5 GB; ขนาดข้อมูลสุดท้ายบนดิสก์: 50 GB
ดังที่คุณเห็นจากผลลัพธ์ข้างต้น VictoriaMetrics ชนะในด้านประสิทธิภาพการแทรกและอัตราส่วนการบีบอัด ไทม์ไลน์ชนะในการใช้ RAM แต่ใช้พื้นที่ดิสก์จำนวนมาก - 29 ไบต์ต่อจุดข้อมูล
ด้านล่างนี้คือกราฟการใช้งาน CPU สำหรับแต่ละ TSDB ระหว่างการวัดประสิทธิภาพ:
ด้านบนเป็นภาพหน้าจอ: VictoriaMetrics - โหลด CPU ระหว่างการทดสอบการแทรกสำหรับตัววัด 400K ที่ไม่ซ้ำกัน
ด้านบนเป็นภาพหน้าจอ: InfluxDB - โหลด CPU ระหว่างการทดสอบการแทรกสำหรับเมตริกเฉพาะ 400K
ด้านบนเป็นภาพหน้าจอ: TimescaleDB - โหลด CPU ระหว่างการทดสอบการแทรกสำหรับเมตริกเฉพาะ 400K
VictoriaMetrics ใช้ vCPU ที่มีอยู่ทั้งหมด ในขณะที่ InfluxDB ใช้ vCPU ต่ำกว่าประมาณ 2 จาก 16 ตัว
มาตราส่วนเวลาใช้เพียง 3-4 จาก 16 vCPU สัดส่วนที่สูงของ iowait และระบบในกราฟมาตราส่วนเวลาของ TimescaleDB บ่งชี้ถึงปัญหาคอขวดในระบบย่อยอินพุต/เอาท์พุต (I/O) ลองดูกราฟการใช้แบนด์วิธของดิสก์:
ด้านบนเป็นภาพหน้าจอ: VictoriaMetrics - การใช้แบนด์วิดท์ของดิสก์ในการทดสอบการแทรกสำหรับเมตริกที่ไม่ซ้ำ 400K
ด้านบนเป็นภาพหน้าจอ: InfluxDB - การใช้แบนด์วิดท์ของดิสก์ในการทดสอบการแทรกสำหรับเมตริกที่ไม่ซ้ำ 400K
ด้านบนเป็นภาพหน้าจอ: TimescaleDB - การใช้แบนด์วิดท์ของดิสก์ในการทดสอบการแทรกสำหรับเมตริกที่ไม่ซ้ำ 400K
VictoriaMetrics บันทึกข้อมูลที่ความเร็ว 20 Mbps และสูงสุดที่ 45 Mbps ยอดเขาสอดคล้องกับการรวมตัวกันบางส่วนขนาดใหญ่ในต้นไม้ .
InfluxDB เขียนข้อมูลด้วยความเร็ว 160 MB/s ในขณะที่ไดรฟ์ขนาด 1 TB ความเร็วการเขียน 120 MB/s
TimescaleDB ถูกจำกัดให้เขียนที่ความเร็ว 120 Mbps แต่บางครั้งก็เกินขีดจำกัดนี้และถึง 220 Mbps ในค่าสูงสุด จุดสูงสุดเหล่านี้สอดคล้องกับระดับการใช้งาน CPU ที่ไม่เพียงพอในกราฟก่อนหน้า
มาดูกราฟการใช้งานอินพุต/เอาท์พุต (I/O) กัน:
ด้านบนเป็นภาพหน้าจอ: VictoriaMetrics - แทรกการใช้ I/O ทดสอบสำหรับตัววัดที่ไม่ซ้ำกัน 400 ตัว
ด้านบนเป็นภาพหน้าจอ: InfluxDB - แทรกการใช้งาน I/O ทดสอบสำหรับตัววัดที่ไม่ซ้ำกัน 400K
ด้านบนเป็นภาพหน้าจอ: TimescaleDB - แทรกการใช้งาน I/O ทดสอบสำหรับตัววัดที่ไม่ซ้ำกัน 400K
ตอนนี้เป็นที่ชัดเจนว่า TimescaleDB ถึงขีดจำกัด I/O แล้ว ดังนั้นจึงไม่สามารถใช้ vCPU ที่เหลืออีก 12 vCPU ได้
อนุกรมเวลาพิเศษ 4M
อนุกรมเวลา 4M ดูท้าทายเล็กน้อย แต่คู่แข่งของเราก็สอบผ่านได้สำเร็จ ผลลัพธ์มาตรฐาน:
- VictoriaMetrics: จุดข้อมูล 2,2M ต่อวินาที; การใช้งาน RAM: 6 GB; ขนาดข้อมูลสุดท้ายบนดิสก์: 3 GB
- InfluxDB: จุดข้อมูล 330K ต่อวินาที; การใช้งาน RAM: 20,5 GB; ขนาดข้อมูลสุดท้ายบนดิสก์: 18,4 GB
- TimescaleDB: จุดข้อมูล 480K ต่อวินาที; การใช้งาน RAM: 2,5 GB; ขนาดข้อมูลสุดท้ายบนดิสก์: 52 GB
ประสิทธิภาพ InfluxDB ลดลงจาก 1,2M จุดข้อมูลต่อวินาทีสำหรับอนุกรมเวลา 400K เป็น 330K จุดข้อมูลต่อวินาทีสำหรับอนุกรมเวลา 4M นี่เป็นการสูญเสียประสิทธิภาพอย่างมีนัยสำคัญเมื่อเทียบกับคู่แข่งรายอื่น ลองดูกราฟการใช้งาน CPU เพื่อทำความเข้าใจสาเหตุที่แท้จริงของการสูญเสียนี้:
ด้านบนเป็นภาพหน้าจอ: VictoriaMetrics - การใช้ CPU ระหว่างการทดสอบการแทรกสำหรับอนุกรมเวลา 4M ที่ไม่ซ้ำกัน
ด้านบนเป็นภาพหน้าจอ: InfluxDB - การใช้งาน CPU ระหว่างการทดสอบการแทรกสำหรับอนุกรมเวลา 4M ที่ไม่ซ้ำกัน
ด้านบนเป็นภาพหน้าจอ: TimescaleDB - การใช้งาน CPU ระหว่างการทดสอบการแทรกสำหรับอนุกรมเวลา 4M ที่ไม่ซ้ำกัน
VictoriaMetrics ใช้กำลังของหน่วยประมวลผล (CPU) เกือบทั้งหมด การดรอปที่ส่วนท้ายสอดคล้องกับการรวม LSM ที่เหลือหลังจากแทรกข้อมูลทั้งหมดแล้ว
InfluxDB ใช้ vCPU เพียง 8 จาก 16 vCPU ในขณะที่ TimsecaleDB ใช้ 4 จาก 16 vCPU กราฟของพวกเขามีอะไรเหมือนกัน? ส่วนแบ่งสูง iowaitซึ่งบ่งบอกถึงปัญหาคอขวดของ I/O อีกครั้ง
TimescaleDB มีส่วนแบ่งสูง system- เราถือว่าพลังงานสูงทำให้เกิดการเรียกระบบหลายครั้งหรือหลายครั้ง .
ลองดูกราฟปริมาณงานของดิสก์:
ด้านบนเป็นภาพหน้าจอ: VictoriaMetrics - การใช้แบนด์วิดท์ของดิสก์เพื่อแทรกเมตริกที่ไม่ซ้ำกัน 4M
ด้านบนเป็นภาพหน้าจอ: InfluxDB - การใช้แบนด์วิดท์ของดิสก์เพื่อแทรกเมตริกที่ไม่ซ้ำกัน 4M
ด้านบนเป็นภาพหน้าจอ: TimescaleDB - การใช้แบนด์วิดท์ของดิสก์เพื่อแทรกเมตริกที่ไม่ซ้ำกัน 4M
VictoriaMetrics มีความเร็วสูงสุดที่ 120 MB/s ในขณะที่ความเร็วในการเขียนเฉลี่ยอยู่ที่ 40 MB/s มีแนวโน้มว่าจะมีการหลอมรวม LSM จำนวนมากหลายครั้งในช่วงพีค
InfluxDB บีบปริมาณการเขียนเฉลี่ยอีกครั้งที่ 200 MB/s โดยมีจุดสูงสุดสูงสุด 340 MB/s บนดิสก์โดยจำกัดการเขียนที่ 120 MB/s :)
TimescaleDB ไม่มีการจำกัดดิสก์อีกต่อไป ดูเหมือนจะถูกจำกัดด้วยสิ่งอื่นที่เกี่ยวข้องกับสัดส่วนที่สูง системной โหลดซีพียู
ลองดูกราฟการใช้งาน IO:
ด้านบนเป็นภาพหน้าจอ: VictoriaMetrics - การใช้ I/O ระหว่างการทดสอบการแทรกสำหรับอนุกรมเวลา 4M ที่ไม่ซ้ำกัน
ด้านบนเป็นภาพหน้าจอ: InfluxDB - การใช้ I/O ระหว่างการทดสอบการแทรกสำหรับอนุกรมเวลา 4M ที่ไม่ซ้ำกัน
ด้านบนเป็นภาพหน้าจอ: TimescaleDB - การใช้งาน I/O ระหว่างการทดสอบการแทรกสำหรับอนุกรมเวลา 4M ที่ไม่ซ้ำกัน
รูปแบบการใช้งาน IO สะท้อนถึงแบนด์วิธของดิสก์ - InfluxDB มี IO ที่จำกัด ในขณะที่ VictoriaMetrics และ TimescaleDB มีทรัพยากร IO สำรอง
อนุกรมเวลาที่ไม่ซ้ำกัน 40M
อนุกรมเวลาที่ไม่ซ้ำกัน 40M ใหญ่เกินไปสำหรับ InfluxDB :)
ผลลัพธ์มาตรฐาน:
- VictoriaMetrics: จุดข้อมูล 1,7M ต่อวินาที; การใช้งาน RAM: 29 GB; การใช้พื้นที่ดิสก์: 17 GB
- InfluxDB: ดำเนินการไม่เสร็จเนื่องจากต้องใช้ RAM มากกว่า 60GB
- TimescaleDB: จุดข้อมูล 330K ต่อวินาที การใช้ RAM: 2,5 GB; การใช้พื้นที่ดิสก์: 84GB
TimescaleDB แสดงการใช้งาน RAM ที่ต่ำและเสถียรเป็นพิเศษที่ 2,5 GB - เช่นเดียวกับตัววัด 4M และ 400K ที่ไม่ซ้ำกัน
VictoriaMetrics ค่อย ๆ ปรับขนาดขึ้นที่อัตรา 100 จุดข้อมูลต่อวินาที จนกระทั่งประมวลผลชื่อตัววัดที่ติดแท็กทั้งหมด 40 ล้านชื่อ จากนั้นเขาได้รับอัตราการแทรกข้อมูลอย่างต่อเนื่องที่ 1,5-2,0 ล้านจุดข้อมูลต่อวินาที ดังนั้นผลลัพธ์สุดท้ายคือ 1,7 ล้านจุดข้อมูลต่อวินาที
กราฟสำหรับอนุกรมเวลาที่ไม่ซ้ำกัน 40 ล้านอนุกรมนั้นคล้ายคลึงกับกราฟสำหรับอนุกรมเวลาที่ไม่ซ้ำกัน 4 ล้านอนุกรม ดังนั้น ข้ามไปกันดีกว่า
ผลการวิจัย
- TSDB สมัยใหม่สามารถประมวลผลส่วนแทรกสำหรับอนุกรมเวลาที่ไม่ซ้ำกันนับล้านรายการบนเซิร์ฟเวอร์เดียว ในบทความถัดไป เราจะทดสอบว่า TSDB ดำเนินการเลือกอนุกรมเวลาที่ไม่ซ้ำกันนับล้านได้ดีเพียงใด
- การใช้งาน CPU ไม่เพียงพอมักจะบ่งชี้ถึงปัญหาคอขวดของ I/O นอกจากนี้ยังอาจบ่งชี้ว่าการบล็อกนั้นหยาบเกินไป โดยสามารถทำงานได้เพียงไม่กี่เธรดในแต่ละครั้ง
- ปัญหาคอขวดของ I/O มีอยู่จริง โดยเฉพาะอย่างยิ่งในพื้นที่จัดเก็บข้อมูลที่ไม่ใช่ SSD เช่น อุปกรณ์บล็อกเสมือนจริงของผู้ให้บริการคลาวด์
- VictoriaMetrics มอบการปรับแต่งที่ดีที่สุดสำหรับพื้นที่จัดเก็บ I/O ที่ช้าและต่ำ ให้ความเร็วที่ดีที่สุดและอัตราการบีบอัดที่ดีที่สุด
ดาวน์โหลด และลองใช้กับข้อมูลของคุณ ไบนารีคงที่ที่เกี่ยวข้องมีอยู่ที่ .
อ่านเพิ่มเติมเกี่ยวกับ VictoriaMetrics ได้ในนี้ .
อัปเดต: เผยแพร่แล้ว ด้วยผลลัพธ์ที่สามารถทำซ้ำได้
อัปเดต #2: อ่านด้วย .
อัปเดต #3: !
แชทโทรเลข:
ที่มา: will.com
