ฉันกำลังสร้างระบบที่โพลอุปกรณ์สำหรับข้อมูลเกี่ยวกับตัวชี้วัดที่แตกต่างกันเช่นการใช้งาน CPU, การใช้ดิสก์, อุณหภูมิ ฯลฯ ที่ (อาจ) 5 นาทีโดยใช้ SNMP เป้าหมายสูงสุดคือการแสดงภาพให้กับผู้ใช้ระบบในรูปแบบของกราฟอนุกรมเวลา

ฉันเคยดูการใช้ RRDTool ในอดีต แต่ปฏิเสธว่าเป็นการเก็บข้อมูลที่ถูกบันทึกไว้โดยไม่มีกำหนดซึ่งมีความสำคัญต่อโครงการของฉันและฉันต้องการระดับที่สูงขึ้นและการเข้าถึงข้อมูลที่บันทึกได้อย่างยืดหยุ่นมากขึ้น ดังนั้นคำถามของฉันคือ:

สิ่งที่ดีกว่าคือฐานข้อมูลเชิงสัมพันธ์ (เช่น MySQL หรือ PostgreSQL) หรือฐานข้อมูลที่ไม่ใช่เชิงสัมพันธ์หรือฐานข้อมูล NoSQL (เช่น MongoDB หรือ Redis) เกี่ยวกับประสิทธิภาพเมื่อทำการสอบถามข้อมูลเพื่อสร้างกราฟ

สัมพันธ์

ให้ฐานข้อมูลเชิงสัมพันธ์ฉันจะใช้data_instancesตารางซึ่งจะถูกเก็บไว้ทุกตัวอย่างของข้อมูลที่ถูกจับสำหรับทุกการวัดที่ถูกวัดสำหรับอุปกรณ์ทั้งหมดโดยมีฟิลด์ต่อไปนี้:

ทุ่ง: id fk_to_device fk_to_metric metric_value timestamp

เมื่อฉันต้องการวาดกราฟสำหรับตัวชี้วัดที่เฉพาะเจาะจงในอุปกรณ์ใดตัวหนึ่งฉันต้องสอบถามตารางเอกพจน์นี้เพื่อกรองอุปกรณ์อื่น ๆ และตัวชี้วัดอื่น ๆ ที่วิเคราะห์สำหรับอุปกรณ์นี้:

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

จำนวนแถวในตารางนี้จะเป็น:

d * m_d * f * t

ที่dเป็นจำนวนของอุปกรณ์ , m_dเป็นสะสมจำนวนตัวชี้วัดที่ถูกบันทึกไว้สำหรับอุปกรณ์ทั้งหมดfเป็นความถี่ที่ข้อมูลจะถูกถึงขนาดและtเป็นจำนวนเงินรวมของเวลาที่ระบบได้รับการเก็บรวบรวมข้อมูล

สำหรับผู้ใช้ที่บันทึก 10 ตัวชี้วัดสำหรับ 3 อุปกรณ์ทุก ๆ 5 นาทีเป็นเวลาหนึ่งปีเราจะมีระเบียนน้อยกว่า5 ล้านรายการ

ดัชนี

หากไม่มีดัชนีfk_to_deviceและfk_to_metricสแกนตารางที่ขยายอย่างต่อเนื่องนี้จะใช้เวลานานเกินไป ดังนั้นการจัดทำดัชนีฟิลด์ดังกล่าวและtimestamp(สำหรับการสร้างกราฟที่มีช่วงเวลาที่แปลเป็นภาษาท้องถิ่น) จึงเป็นข้อกำหนด

ไม่ใช่เชิงสัมพันธ์ (NoSQL)

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

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

ลังเล

โซลูชันเชิงสัมพันธ์ที่มีการจัดทำดัชนีที่ถูกต้องจะลดลงเป็นการรวบรวมข้อมูลภายในปีหรือไม่ หรือโครงสร้างตามการรวบรวมของแนวทาง NoSQL (ซึ่งตรงกับแบบจำลองจิตของฉันของข้อมูลที่เก็บไว้) ให้ประโยชน์ที่เห็นได้ชัดเจน?

ความสัมพันธ์ที่แน่นอน ความยืดหยุ่นและการขยายที่ไม่ จำกัด

การแก้ไขสองแบบทั้งในแนวคิดและการใช้งานตามด้วยการยกระดับ

การแก้ไข

1. ไม่ใช่ "การกรองข้อมูลที่ไม่ต้องการ"; มันคือการเลือกข้อมูลที่จำเป็นเท่านั้น ใช่แน่นอนถ้าคุณมีดัชนีเพื่อสนับสนุนคอลัมน์ที่ระบุไว้ในส่วนคำสั่ง WHERE จะรวดเร็วมากและแบบสอบถามไม่ได้ขึ้นอยู่กับขนาดของตาราง (คว้า 1,000 แถวจากตารางแถว 16 พันล้านทันที) .

2. ตารางของคุณมีหนึ่งอุปสรรคที่ร้ายแรง รับรายละเอียดของคุณ PK ที่แท้จริงคือ (อุปกรณ์, ตัวชี้วัด, DateTime) (โปรดอย่าเรียกว่า TimeStamp นั่นหมายถึงอย่างอื่น แต่นั่นเป็นปัญหาเล็กน้อย) ความเป็นเอกลักษณ์ของแถวถูกระบุโดย:

      (Device, Metric, DateTime)
   

   • Idคอลัมน์ไม่ทำอะไรเลยก็เป็นทั้งหมดและซ้ำซ้อนอย่างสมบูรณ์

     • Idคอลัมน์จะไม่เป็นคีย์ (แถวที่ซ้ำกันซึ่งเป็นสิ่งต้องห้ามในฐานข้อมูลเชิงสัมพันธ์จะต้องได้รับการป้องกันด้วยวิธีอื่น ๆ )

     • Idคอลัมน์ต้องเพิ่มดัชนีซึ่งเห็นได้ชัดว่าเป็นอุปสรรคความเร็วINSERT/DELETEและเพิ่มพื้นที่ดิสก์ที่ใช้

     • คุณสามารถกำจัดมันได้ กรุณา.

การยกระดับ

1. ตอนนี้คุณได้ลบสิ่งกีดขวางออกแล้วคุณอาจไม่รู้จัก แต่ตารางของคุณอยู่ในรูปแบบปกติที่หก ความเร็วสูงมากด้วยดัชนีเพียงหนึ่งเดียวใน PK เพื่อความเข้าใจอ่านคำตอบนี้จากแบบฟอร์มปกติที่หกคืออะไร มุ่งหน้าเป็นต้นไป

   • (ฉันมีหนึ่งดัชนีเท่านั้นไม่ใช่สามใน Non-SQLs คุณอาจต้องมีสามดัชนี)

   • ฉันมีตารางเดียวกันแน่นอน (โดยไม่ต้องId"คีย์" แน่นอน) Serverฉันมีคอลัมน์เพิ่มเติม ฉันสนับสนุนลูกค้าหลายรายจากระยะไกล

     (Server, Device, Metric, DateTime)

   ตารางสามารถใช้ในการ Pivot ข้อมูล (เช่นDevicesข้ามด้านบนและMetricsล่างหรือหมุน) โดยใช้รหัส SQL เดียวกันทั้งหมด (ใช่เปลี่ยนเซลล์) ฉันใช้ตารางเพื่อสร้างกราฟและแผนภูมิที่หลากหลายแบบไม่ จำกัด เพื่อให้ลูกค้าใช้งานเซิร์ฟเวอร์ได้อย่างมีประสิทธิภาพ

   • การตรวจสอบสถิติข้อมูลรุ่น
     (มีขนาดใหญ่เกินไปสำหรับแบบอินไลน์เบราว์เซอร์บางตัวไม่สามารถโหลดแบบอินไลน์ได้ให้คลิกที่ลิงก์นอกจากนี้ยังเป็นเวอร์ชั่นตัวอย่างที่ล้าสมัยด้วยเหตุผลที่ชัดเจนฉันไม่สามารถแสดง DM ผลิตภัณฑ์เชิงพาณิชย์ให้คุณได้)

   • มันช่วยให้ฉันเพื่อผลิตชาร์ตเช่นนี้หกการกดแป้นพิมพ์หลังจากที่ได้รับการตรวจสอบไฟล์ดิบสถิติจากลูกค้าโดยใช้คำสั่ง SELECT เดียว สังเกตการมิกซ์แอนด์แมตช์; ระบบปฏิบัติการและเซิร์ฟเวอร์ในแผนภูมิเดียวกัน ความหลากหลายของ Pivots แน่นอนว่าไม่มีการ จำกัด จำนวนเมทริกซ์สถิติและทำให้แผนภูมิ (ใช้เมื่อได้รับอนุญาตจากลูกค้า)

   • ผู้อ่านที่ไม่คุ้นเคยกับมาตรฐานสำหรับการสร้างแบบจำลองฐานข้อมูลเชิงสัมพันธ์อาจพบว่าสัญกรณ์ IDEF1Xเป็นประโยชน์

อีกหนึ่งสิ่ง

สุดท้าย แต่ไม่ท้ายสุด SQL คือมาตรฐาน IEC / ISO / ANSI ฟรีแวร์จริง ๆ แล้วไม่ใช่ SQL มันเป็นการฉ้อโกงที่จะใช้คำว่า SQL หากไม่ได้จัดทำมาตรฐาน พวกเขาอาจให้ "ความพิเศษ" แต่พวกเขาขาดพื้นฐาน

พบว่าน่าสนใจมากคำตอบข้างต้น พยายามเพิ่มข้อควรพิจารณาเพิ่มเติมอีกสองสามข้อที่นี่

1) Data aging

การจัดการอนุกรมเวลามักจะต้องสร้างนโยบายอายุ สถานการณ์ทั่วไป (เช่น CPU ของเซิร์ฟเวอร์การมอนิเตอร์) จำเป็นต้องมีการจัดเก็บ:

• ตัวอย่างดิบ1 วินาทีในช่วงเวลาสั้น ๆ (เช่น 24 ชั่วโมง)

• ตัวอย่างรวมรายละเอียด5 นาทีสำหรับช่วงเวลาปานกลาง (เช่น 1 สัปดาห์)

• รายละเอียดมากกว่า1 ชั่วโมง (เช่นสูงสุด 1 ปี)

แม้ว่าโมเดลเชิงสัมพันธ์ทำให้มันเป็นไปได้อย่างแน่นอน (บริษัท ของฉันใช้ฐานข้อมูลส่วนกลางขนาดใหญ่สำหรับลูกค้าขนาดใหญ่ที่มีชุดข้อมูลนับหมื่นชุด) เพื่อจัดการอย่างเหมาะสม แต่ตัวเก็บข้อมูลสายพันธุ์ใหม่ก็เพิ่มฟังก์ชั่นที่น่าสนใจเช่น:

• การล้างข้อมูลอัตโนมัติ (ดูคำสั่ง EXPIRE ของ Redis)

• การรวมหลายมิติ (เช่นแผนที่ลดงาน a-la-Splunk)

2) การรวบรวมตามเวลาจริง

ที่สำคัญยิ่งไปกว่านั้นบางร้านค้าข้อมูลที่ไม่เกี่ยวข้องมีการกระจายอย่างต่อเนื่องและอนุญาตให้มีการรวบรวมข้อมูลแบบเรียลไทม์ (หรือใกล้เวลาจริง) ที่มีประสิทธิภาพมากขึ้นซึ่งอาจเป็นปัญหากับ RDBMS เนื่องจากการสร้างฮอตสปอต ตารางเดียว) โดยทั่วไปปัญหานี้ในพื้นที่ RDBMS จะได้รับการแก้ไขกลับไปเป็นขั้นตอนการนำเข้าแบบแบทช์ (เราจัดการด้วยวิธีนี้ในอดีต) ในขณะที่เทคโนโลยีแบบ sql ไม่ประสบความสำเร็จในการรวบรวมและรวมแบบเรียลไทม์ขนาดใหญ่ (ดู Splunk เช่น .

ตารางของคุณมีข้อมูลในตารางเดียว ดังนั้นความสัมพันธ์กับความสัมพันธ์จึงไม่ใช่คำถาม โดยทั่วไปคุณต้องอ่านข้อมูลตามลำดับจำนวนมาก ตอนนี้ถ้าคุณมี RAM เพียงพอที่จะจัดเก็บข้อมูลที่คุ้มค่าเป็นเวลาหลายปีแล้วไม่มีอะไรที่เหมือนกับการใช้ Redis / MongoDB เป็นต้น

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

NoSQL ทำเช่นเดียวกับการสร้างดัชนีในรหัสอุปกรณ์และรหัสเมตริก แต่ในทางของตัวเอง ด้วยฐานข้อมูลแม้ว่าคุณจะทำสิ่งนี้ดัชนีและข้อมูลอาจแตกต่างกันและจะมีดิสก์ IO จำนวนมาก

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

สร้างไฟล์ตั้งชื่อมันว่า 1_2.data ความคิดที่แปลกประหลาด? สิ่งที่คุณจะได้รับ:

• คุณประหยัดพื้นที่ได้มากถึง 50% เพราะคุณไม่จำเป็นต้องทำซ้ำค่า fk_to_device และ fk_to_metric สำหรับทุกจุดข้อมูล
• คุณประหยัดพื้นที่ได้มากขึ้นเพราะคุณไม่ต้องการดัชนีใด ๆ
• บันทึกคู่ (timestamp, metric_value) ลงในไฟล์โดยการต่อท้ายข้อมูลเพื่อให้คุณได้รับคำสั่งซื้อจาก timestamp ฟรี (สมมติว่าแหล่งที่มาของคุณไม่ส่งข้อมูลการสั่งซื้อสำหรับอุปกรณ์)

=> แบบสอบถามโดยการประทับเวลาทำงานอย่างรวดเร็วอย่างน่าอัศจรรย์เพราะคุณสามารถใช้การค้นหาแบบไบนารีเพื่อค้นหาสถานที่ที่เหมาะสมในไฟล์ที่จะอ่าน

ถ้าคุณชอบมันจะได้รับการปรับให้เหมาะสมที่สุดเริ่มคิดแยกไฟล์ของคุณแบบนั้น

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

หรือใช้ kdb + จากhttp://kx.comเพราะพวกเขาทำทุกอย่างให้คุณ :) การวางคอลัมน์เป็นสิ่งที่อาจช่วยคุณได้

มีวิธีแก้ปัญหาคอลัมน์แบบคลาวด์โผล่ขึ้นมาดังนั้นคุณอาจต้องการดู: http://timeseries.guru

หากคุณกำลังมองหาแพ็คเกจ GPL RRDToolนั้นเหมาะสำหรับการดู เป็นเครื่องมือที่ดีสำหรับการจัดเก็บการแยกและการสร้างกราฟข้อมูลชุดข้อมูล กรณีการใช้งานของคุณดูเหมือนว่าข้อมูลอนุกรมเวลา

นี่เป็นปัญหาที่เราต้องแก้ไขที่ ApiAxle เราเขียนโพสต์ในบล็อกว่าเราใช้ Redis อย่างไร มันไม่ได้อยู่ที่นั่นนานนัก แต่มันพิสูจน์แล้วว่ามีประสิทธิภาพ

ฉันยังใช้RRDToolสำหรับโครงการอื่นซึ่งยอดเยี่ยม

ฉันคิดว่าคำตอบสำหรับคำถามประเภทนี้ส่วนใหญ่ควรจะหมุนเกี่ยวกับวิธีที่ฐานข้อมูลของคุณใช้พื้นที่เก็บข้อมูล เซิร์ฟเวอร์ฐานข้อมูลบางตัวใช้ RAM และ Disk บางตัวใช้ RAM เท่านั้น (เป็นทางเลือก Disk for persistency) เป็นต้นโซลูชันฐานข้อมูล SQL ทั่วไปส่วนใหญ่ใช้หน่วยความจำ + ที่เก็บดิสก์และเขียนข้อมูลในรูปแบบของแถวที่ใช้ ตำแหน่งทางกายภาพ). สำหรับร้านค้าไทม์ซีในกรณีส่วนใหญ่เวิร์กโหลดมีลักษณะดังนี้: ช่วงเวลาค่อนข้างน้อยของเม็ดมีดจำนวนมากในขณะที่การอ่านเป็นไปตามคอลัมน์ (ในกรณีส่วนใหญ่คุณต้องการอ่านช่วงของข้อมูลจากคอลัมน์ที่ระบุแทนเมตริก)

ฉันพบฐานข้อมูลเรียงเป็นแถว (google แล้วคุณจะพบว่า MonetDB, InfoBright, parAccel และอื่น ๆ ) กำลังทำงานที่ยอดเยี่ยมสำหรับอนุกรมเวลา

สำหรับคำถามของคุณซึ่งโดยส่วนตัวแล้วฉันคิดว่าค่อนข้างไม่ถูกต้อง (เนื่องจากการอภิปรายทั้งหมดโดยใช้คำว่า NoSQL - IMO): คุณสามารถใช้เซิร์ฟเวอร์ฐานข้อมูลที่สามารถพูด SQL ได้ด้วยมือเดียวทำให้ชีวิตของคุณง่ายขึ้น ปีที่ผ่านมาและภาษานี้ได้รับการปรับปรุงอย่างสมบูรณ์ซ้ำแล้วซ้ำอีกสำหรับการค้นหาข้อมูล; แต่ยังคงใช้ RAM, CPU Cache และดิสก์ในลักษณะแบบเรียงเป็นแนวทำให้โซลูชันของคุณเหมาะสมที่สุดกับ Time Series

5 ล้านแถวไม่ได้เป็นข้อมูลสำหรับวันนี้ คาดว่าข้อมูลจะอยู่ใน TB หรือ PB ในเวลาเพียงไม่กี่เดือน ณ จุดนี้ RDBMS ไม่ขยายไปยังงานและเราต้องการ scalability เชิงเส้นของฐานข้อมูล NoSql ประสิทธิภาพจะประสบความสำเร็จสำหรับพาร์ทิชันคอลัมน์ที่ใช้ในการจัดเก็บข้อมูลเพิ่มคอลัมน์มากขึ้นและชนิดของแนวคิดน้อยแถวเพื่อเพิ่มประสิทธิภาพ ใช้ประโยชน์จากงาน Open TSDB ที่ทำบน HBASE หรือ MapR_DB เป็นต้น

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

คุณควรมีลักษณะเป็นฐานข้อมูลอนุกรมเวลา มันถูกสร้างขึ้นเพื่อจุดประสงค์นี้

ฐานข้อมูลอนุกรมเวลา (TSDB) เป็นระบบซอฟต์แวร์ที่ได้รับการปรับให้เหมาะสมสำหรับการจัดการข้อมูลอนุกรมเวลาอาร์เรย์ของตัวเลขที่จัดทำดัชนีตามเวลา (วันที่และเวลาหรือช่วงวันที่และเวลา)

ตัวอย่างที่นิยมของฐานข้อมูลอนุกรมเวลาInfluxDB