ความโกรธ การต่อรอง และความหดหู่เมื่อทำงานกับ InfluxDB

หากคุณใช้ฐานข้อมูลอนุกรมเวลา (timeseries db, วิกิพีเดีย) เป็นที่เก็บข้อมูลหลักสำหรับไซต์ที่มีสถิติ แทนที่จะแก้ปัญหา กลับทำให้คุณปวดหัวแทน ฉันกำลังทำงานในโปรเจ็กต์ที่ใช้ฐานข้อมูลดังกล่าว และบางครั้ง InfluxDB ซึ่งจะมีการพูดคุยกัน ก็นำเสนอเรื่องน่าประหลาดใจที่ไม่คาดคิดโดยสิ้นเชิง

ข้อจำกัดความรับผิดชอบ: ปัญหาที่ระบุไว้ใช้กับ InfluxDB เวอร์ชัน 1.7.4

ทำไมต้องเป็นอนุกรมเวลา?

โครงการนี้คือการติดตามธุรกรรมบนบล็อกเชนต่างๆ และแสดงสถิติ โดยเฉพาะอย่างยิ่ง เราพิจารณาถึงการปล่อยและการเผาไหม้ของเหรียญที่มีเสถียรภาพ (วิกิพีเดีย). จากธุรกรรมเหล่านี้ คุณจะต้องสร้างกราฟและแสดงตารางสรุป

ขณะวิเคราะห์ธุรกรรม ก็มีแนวคิดเกิดขึ้น: ใช้ฐานข้อมูลอนุกรมเวลา InfluxDB เป็นที่จัดเก็บข้อมูลหลัก ธุรกรรมเป็นจุดในเวลาและเข้ากันได้ดีกับโมเดลอนุกรมเวลา

ฟังก์ชันการรวมกลุ่มยังดูสะดวกมาก เหมาะสำหรับการประมวลผลแผนภูมิที่มีระยะเวลายาวนาน ผู้ใช้ต้องการแผนภูมิเป็นเวลาหนึ่งปี และฐานข้อมูลประกอบด้วยชุดข้อมูลที่มีกรอบเวลาห้านาที การส่งจุดทั้งหมดหนึ่งแสนจุดไปให้เขานั้นไม่มีประโยชน์ - นอกเหนือจากการประมวลผลที่ยาวนานแล้ว จุดเหล่านั้นจะไม่พอดีกับหน้าจอด้วยซ้ำ คุณสามารถเขียนการใช้งานของคุณเองในการเพิ่มกรอบเวลา หรือใช้ฟังก์ชันการรวมกลุ่มที่สร้างไว้ใน Influx ด้วยความช่วยเหลือของพวกเขา คุณสามารถจัดกลุ่มข้อมูลตามวันและส่ง 365 คะแนนที่ต้องการได้

ค่อนข้างสับสนเล็กน้อยที่ฐานข้อมูลดังกล่าวมักถูกใช้เพื่อวัตถุประสงค์ในการรวบรวมเมตริก การตรวจสอบเซิร์ฟเวอร์ อุปกรณ์ iot ทุกอย่างที่มีจุดหลายล้านจุดในรูปแบบ "การไหล": [<เวลา> - <ค่าเมตริก>] แต่หากฐานข้อมูลทำงานได้ดีกับกระแสข้อมูลขนาดใหญ่ แล้วเหตุใดปริมาณข้อมูลขนาดเล็กจึงควรทำให้เกิดปัญหา ด้วยเหตุนี้ เราจึงนำ InfluxDB มาทำงาน

มีอะไรอีกที่สะดวกใน InfluxDB

นอกเหนือจากฟังก์ชันการรวมกลุ่มที่กล่าวมานี้ ยังมีข้อดีอีกประการหนึ่งคือ แบบสอบถามอย่างต่อเนื่อง (doc). นี่คือตัวกำหนดเวลาที่สร้างไว้ในฐานข้อมูลที่สามารถประมวลผลข้อมูลตามกำหนดเวลาได้ ตัวอย่างเช่น ทุก 24 ชั่วโมง คุณสามารถจัดกลุ่มบันทึกทั้งหมดสำหรับวันนั้น คำนวณค่าเฉลี่ย และบันทึกจุดใหม่หนึ่งจุดในตารางอื่นโดยไม่ต้องเขียนจักรยานของคุณเอง

ยังมี นโยบายการเก็บรักษา (doc)—ตั้งค่าการลบข้อมูลหลังจากช่วงระยะเวลาหนึ่ง ซึ่งจะมีประโยชน์เมื่อคุณต้องการจัดเก็บโหลดของ CPU เป็นเวลาหนึ่งสัปดาห์ด้วยการวัดหนึ่งครั้งต่อวินาที แต่ไม่จำเป็นต้องใช้ความแม่นยำดังกล่าวในระยะเวลาสองสามเดือน ในสถานการณ์เช่นนี้ คุณสามารถทำได้:

1. สร้างแบบสอบถามต่อเนื่องเพื่อรวบรวมข้อมูลลงในตารางอื่น
2. สำหรับตารางแรก ให้กำหนดนโยบายในการลบเมตริกที่เก่ากว่าสัปดาห์เดียวกันนั้น

และ Influx จะลดขนาดข้อมูลและลบสิ่งที่ไม่จำเป็นออกไปอย่างอิสระ

เกี่ยวกับข้อมูลที่เก็บไว้

มีการจัดเก็บข้อมูลไม่มาก: ประมาณ 70 ธุรกรรมและอีกล้านคะแนนพร้อมข้อมูลตลาด เพิ่มรายการใหม่ - ไม่เกิน 3000 คะแนนต่อวัน นอกจากนี้ยังมีตัวชี้วัดสำหรับไซต์ แต่มีข้อมูลเพียงเล็กน้อยและตามนโยบายการเก็บรักษา ข้อมูลเหล่านั้นจะถูกเก็บไว้ไม่เกินหนึ่งเดือน

ปัญหา

ในระหว่างการพัฒนาและการทดสอบบริการในเวลาต่อมา ปัญหาสำคัญเกิดขึ้นในการทำงานของ InfluxDB มากขึ้นเรื่อยๆ

1. การลบข้อมูล

มีชุดข้อมูลที่มีธุรกรรม:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

ผล:

ฉันกำลังส่งคำสั่งให้ลบข้อมูล:

DELETE FROM transactions WHERE symbol=’USDT’

ต่อไปฉันจะขอรับข้อมูลที่ถูกลบไปแล้ว และแทนที่จะตอบกลับว่างเปล่า Influx จะส่งคืนข้อมูลบางส่วนที่ควรลบ

ฉันกำลังพยายามลบทั้งตาราง:

DROP MEASUREMENT transactions

ฉันตรวจสอบการลบตาราง:

SHOW MEASUREMENTS

ฉันไม่เห็นตารางในรายการ แต่แบบสอบถามข้อมูลใหม่ยังคงส่งคืนชุดธุรกรรมเดียวกัน

ปัญหาเกิดขึ้นกับฉันเพียงครั้งเดียว เนื่องจากกรณีการลบเป็นกรณีแยกกัน แต่พฤติกรรมของฐานข้อมูลนี้ไม่สอดคล้องกับกรอบการทำงานที่ "ถูกต้อง" อย่างชัดเจน ต่อมาฉันพบว่ามันเปิดบน GitHub ตั๋ว เกือบหนึ่งปีที่แล้วในหัวข้อนี้

ด้วยเหตุนี้การลบและกู้คืนฐานข้อมูลทั้งหมดจึงช่วยได้

2. ตัวเลขทศนิยม

การคำนวณทางคณิตศาสตร์เมื่อใช้ฟังก์ชันในตัวใน InfluxDB มีข้อผิดพลาดด้านความแม่นยำ ไม่ใช่ว่านี่เป็นสิ่งที่ผิดปกติ แต่ก็ไม่เป็นที่พอใจ

ในกรณีของฉัน ข้อมูลมีองค์ประกอบทางการเงิน และฉันต้องการประมวลผลข้อมูลด้วยความแม่นยำสูง ด้วยเหตุนี้ เราจึงวางแผนที่จะละทิ้งคำถามต่อเนื่อง

3. การสืบค้นแบบต่อเนื่องไม่สามารถปรับให้เข้ากับเขตเวลาที่ต่างกันได้

บริการมีตารางสถิติการทำธุรกรรมรายวัน ในแต่ละวัน คุณต้องจัดกลุ่มธุรกรรมทั้งหมดสำหรับวันนั้น แต่วันของผู้ใช้แต่ละคนจะเริ่มต้นในเวลาที่แตกต่างกัน ดังนั้นชุดธุรกรรมจะแตกต่างกัน โดย UTC ใช่ 37 รุ่น กะที่คุณต้องรวบรวมข้อมูล

ใน InfluxDB เมื่อจัดกลุ่มตามเวลา คุณสามารถระบุกะเพิ่มเติมได้ เช่น เวลามอสโก (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

แต่ผลลัพธ์การสืบค้นจะไม่ถูกต้อง ด้วยเหตุผลบางประการ ข้อมูลที่จัดกลุ่มตามวันจะเริ่มย้อนกลับไปที่ 1677 (InfluxDB สนับสนุนช่วงเวลาอย่างเป็นทางการจากปีนี้):

เพื่อแก้ไขปัญหานี้ เราได้เปลี่ยนบริการเป็น UTC+0 ชั่วคราว

4. ประสิทธิภาพ

มีเกณฑ์มาตรฐานมากมายบนอินเทอร์เน็ตที่เปรียบเทียบ InfluxDB และฐานข้อมูลอื่นๆ เมื่อดูเผินๆ พวกเขาดูเหมือนสื่อทางการตลาด แต่ตอนนี้ฉันคิดว่ามีความจริงบางอย่างอยู่ในนั้น

ฉันจะบอกคุณกรณีของฉัน

บริการนี้มีวิธีการ API ที่ส่งคืนสถิติสำหรับวันสุดท้าย เมื่อทำการคำนวณ วิธีการจะสอบถามฐานข้อมูลสามครั้งด้วยการสืบค้นต่อไปนี้:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

คำอธิบาย:

1. ในคำขอแรก เราจะได้คะแนนสุดท้ายสำหรับแต่ละเหรียญพร้อมข้อมูลตลาด แปดแต้มสำหรับแปดเหรียญในกรณีของฉัน
2. คำขอที่สองได้รับหนึ่งในคะแนนใหม่ล่าสุด
3. อันที่ XNUMX ขอรายการธุรกรรมในช่วง XNUMX ชั่วโมงที่ผ่านมา อาจมีหลายร้อยรายการ

ฉันขอชี้แจงว่า InfluxDB จะสร้างดัชนีโดยอัตโนมัติตามแท็กและเวลา ซึ่งจะช่วยเร่งความเร็วในการสืบค้น ในการขอครั้งแรก เครื่องหมาย คือแท็ก

ฉันได้ทำการทดสอบความเครียดกับวิธี API นี้แล้ว สำหรับ 25 RPS เซิร์ฟเวอร์สาธิตการใช้งาน CPU เต็มหกตัว:

ในเวลาเดียวกัน กระบวนการ NodeJs ไม่ได้จัดเตรียมภาระใดๆ เลย

ความเร็วในการดำเนินการลดลงแล้ว 7-10 RPS: หากไคลเอนต์รายหนึ่งสามารถรับการตอบกลับภายใน 200 มิลลิวินาที ไคลเอนต์ 10 รายต้องรอสักครู่ 25 RPS คือขีดจำกัดที่เสถียรภาพได้รับความเสียหาย โดยส่งคืนข้อผิดพลาด 500 รายการให้กับลูกค้า

ด้วยประสิทธิภาพดังกล่าว จึงเป็นไปไม่ได้ที่จะใช้ Influx ในโครงการของเรา ยิ่งไปกว่านั้น: ในโปรเจ็กต์ที่จำเป็นต้องแสดงการตรวจสอบให้ไคลเอนต์จำนวนมากเห็น ปัญหาที่คล้ายกันอาจปรากฏขึ้นและเซิร์ฟเวอร์ตัววัดจะโอเวอร์โหลด

เอาท์พุต

ข้อสรุปที่สำคัญที่สุดจากประสบการณ์ที่ได้รับคือ คุณไม่สามารถนำเทคโนโลยีที่ไม่รู้จักมาสู่โครงการได้หากไม่มีการวิเคราะห์ที่เพียงพอ การคัดกรองปัญหาที่เปิดอยู่อย่างง่าย ๆ บน GitHub สามารถให้ข้อมูลเพื่อหลีกเลี่ยงการเลือก InfluxDB เป็นที่เก็บข้อมูลหลัก

InfluxDB ควรเหมาะสมกับงานในโครงการของฉัน แต่ตามแนวทางปฏิบัติแสดงให้เห็นแล้ว ฐานข้อมูลนี้ไม่ตรงตามความต้องการและมีข้อบกพร่องมากมาย

คุณสามารถค้นหาเวอร์ชัน 2.0.0-เบต้าได้แล้วในพื้นที่เก็บข้อมูลโปรเจ็กต์ เราหวังเพียงว่าเวอร์ชันที่สองจะมีการปรับปรุงที่สำคัญ ในระหว่างนี้ ฉันจะไปศึกษาเอกสารของ TimescaleDB

ที่มา: will.com