โดยทั่วไปแล้วสำหรับชุดข้อมูลที่มีโครงสร้างฉันสงสัยว่าคุณสามารถเขียนรูปแบบข้อมูลที่กำหนดเองซึ่งเร็วกว่าสำหรับการดำเนินงานประจำวันส่วนใหญ่ (เช่นข้อมูลขนาดเล็กดึงจากเวลาที่กำหนด) ประโยชน์ของการย้ายไปยังเครื่องมือฐานข้อมูลมาตรฐานมีแนวโน้มที่จะมีอยู่ในอุปกรณ์พิเศษบางอย่างเช่นคิวรีแบบเฉพาะกิจการเข้าถึงหลายการจำลองแบบความพร้อมใช้งานเป็นต้นนอกจากนี้ยังง่ายต่อการจ้างงานช่วยเหลือในการรักษาแหล่งข้อมูลมาตรฐาน
ถ้าฉันถูกขอให้ตั้งค่าฐานข้อมูลเพื่อเก็บข้อมูลนั้นฉันจะทำสิ่งต่อไปนี้:
สคีมาที่เสนอ
(1) ข้อมูลหลักถูกวางลงในหลาย ๆ ตาราง (1,000) ของแต่ละตารางแต่ละอันมีสองคอลัมน์:
- เวลา: ชนิดข้อมูล SQL DATETIME หรือชนิดตัวเลขจากบางช่วงเวลา (นี่คือคีย์หลัก)
- ค่า: พิมพ์ตามความเหมาะสมสำหรับข้อมูลของคุณ ฉันจะใช้ค่าเริ่มต้นเป็นทศนิยมความแม่นยำเพียงอย่างเดียวอย่างไรก็ตามประเภทข้อมูลคงที่อาจเหมาะสมกว่าสำหรับธุรกรรมทางการเงิน นี่อาจไม่ได้ทำดัชนี
ตารางเหล่านี้จะมีขนาดค่อนข้างใหญ่และคุณอาจต้องการแบ่งพาร์ติชันด้วยตนเองภายในปี (ตัวอย่าง) แต่คุณจะต้องตรวจสอบประสิทธิภาพของระบบและปรับแต่งตามความเหมาะสม
ตารางเหล่านี้ต้องการชื่อที่ไม่ซ้ำกันและมีสองตัวเลือก พวกเขาอาจเป็นมนุษย์ที่อ่านได้ (เช่น nyse_goog_dailyhighs_2010) หรือ (ความชอบของฉัน) ต้องใช้ชุดของตารางเมทาดาทาอย่างใดอย่างหนึ่งและชื่อตารางแบบสุ่มจะป้องกันไม่ให้นักพัฒนาอนุมานสิ่งใด ๆ ในชื่อที่ไม่ได้ตั้งใจจะอนุมาน
(2) ข้อมูล Meta ถูกเก็บไว้ในตารางแยกต่างหากตามที่แอปพลิเคชันต้องการ :
จำเป็นต้องใช้ตารางเพิ่มเติมหรือชุดของตารางเพื่อติดตามข้อมูลเมตา ตารางเหล่านี้จะมีข้อมูลเกี่ยวกับการแลกเปลี่ยนตราสารค่าความถี่ช่วงวันที่แหล่งที่มา (ข้อมูลมาจากไหน) รวมถึงสิ่งอื่นที่คุณต้องการ สิ่งเหล่านี้ถูกแมปกับชื่อตารางข้อมูล
หากมีข้อมูลเพียงพอการค้นหานี้สามารถให้ชื่อตารางและชื่อฐานข้อมูลได้จริงซึ่งช่วยให้สามารถเรียงลำดับข้อมูลที่ถูกนำไปใช้ด้วยตนเอง (ถ้าเป็นการใช้คำที่ถูกต้อง) แต่ฉันจะถือมันไว้สำรอง
จากนั้นที่ชั้นแอปพลิเคชันฉันจะสอบถามตารางเมทาดาทาเพื่อกำหนดว่าข้อมูลของฉันอยู่ที่ไหนและจากนั้นดำเนินการสืบค้นแบบง่ายๆบนตารางข้อมูลขนาดใหญ่เพื่อรับข้อมูลของฉัน
ข้อดี:
ประสบการณ์ของฉัน (ค่อนข้าง จำกัด ) คือฐานข้อมูลสามารถจัดการตารางขนาดเล็กจำนวนมากได้ง่ายกว่าตารางขนาดใหญ่จำนวนน้อย วิธีนี้ยังช่วยให้การบำรุงรักษาง่ายขึ้น (เช่นการล้างข้อมูลเก่าสร้างตารางที่เสียหายใหม่การสร้าง / โหลดซ้ำจากการสำรองข้อมูลเพิ่มเอนทิตีใหม่) สิ่งนี้จะแยกประเภทข้อมูลที่แตกต่างออกไปอย่างสิ้นเชิงถ้า (ตัวอย่าง) คุณมีข้อมูลในอัตราที่ต่างกันหรือต้องการประเภทข้อมูลที่แตกต่างกัน
แนวคิดตารางผอมนี้ควรอนุญาตให้เข้าถึงดิสก์อย่างรวดเร็วสำหรับสิ่งที่ฉันสงสัยว่าเป็นแบบสอบถามที่พบบ่อยที่สุดซึ่งเป็นช่วงของข้อมูลที่ต่อเนื่องกันจากเอนทิตีเดียว แอ็พพลิเคชันข้อมูลส่วนใหญ่เป็นดิสก์ I / O จำกัด ดังนั้นจึงควรพิจารณาด้วย ในฐานะผู้แสดงความคิดเห็นได้บอกเป็นนัยแล้วนี่เป็นแอพพลิเคชั่นที่เหมาะสำหรับฐานข้อมูลแบบคอลัมน์ แต่ฉันยังไม่พบผลิตภัณฑ์แบบคอลัมน์ที่มีความสำคัญพอที่จะวางเดิมพันอาชีพของฉัน สคีมานี้เข้าใกล้แล้ว
ข้อเสีย:
ประมาณครึ่งหนึ่งของพื้นที่ดิสก์ของคุณมีไว้สำหรับการจัดเก็บการประทับเวลาเมื่อค่อนข้างตรงไปตรงมา 100 หรือ 1,000 ของตารางจะมีข้อมูลเดียวกันที่แน่นอนในคอลัมน์ประทับเวลา (อันที่จริงนี่เป็นข้อกำหนดถ้าคุณต้องการที่จะทำการรวมตารางง่าย ๆ )
การจัดเก็บชื่อตารางและการค้นหาแบบไดนามิกต้องใช้ความซับซ้อนของแอปพลิเคชันและการดำเนินการกับสตริงจำนวนมากซึ่งทำให้ฉันประจบประแจง แต่มันก็ยังดีกว่าทางเลือกอื่น (ที่อธิบายด้านล่าง)
การพิจารณา:
ระวังการปัดเศษในเขตเวลาของคุณ คุณต้องการให้ค่าของคุณมีค่ามากพอที่จะเปิดใช้งานการรวม (ถ้าเหมาะสม) แต่แม่นยำพอที่จะโปร่งใส
ระวังเขตเวลาและเวลาออมแสง สิ่งเหล่านี้ยากที่จะทดสอบ ฉันจะบังคับใช้ข้อกำหนด UTC ในที่เก็บข้อมูล (ซึ่งอาจทำให้ฉันไม่เป็นที่นิยม) และจัดการกับการแปลงในแอปพลิเคชัน
รูปแบบ:
บางรูปแบบที่ฉันได้พิจารณาคือ:
การพับข้อมูล: หากมีการเว้นระยะเวลาเท่ากันให้ใช้หนึ่งคอลัมน์การประทับเวลาและ (ตัวอย่าง) คอลัมน์ข้อมูล 10 คอลัมน์ ขณะนี้การประทับเวลาหมายถึงเวลาของคอลัมน์ข้อมูลแรกและคอลัมน์ข้อมูล othe จะเว้นระยะเท่ากันระหว่างการประทับเวลานั้นและคอลัมน์ถัดไป วิธีนี้ช่วยประหยัดพื้นที่เก็บข้อมูลจำนวนมากที่ก่อนหน้านี้ใช้เพื่อจัดเก็บการประทับเวลาด้วยค่าใช้จ่ายในการสืบค้นที่สำคัญและ / หรือความซับซ้อนของแอปพลิเคชัน ช่วงที่ต่อเนื่องกันคิวรีเอนทิตีเดี่ยวตอนนี้ต้องการการเข้าถึงดิสก์น้อยลง
Multi-plexing: หากรู้ว่าอนุกรมเวลาหลายชุดใช้อนุกรมเวลาเดียวกันให้ใช้การประทับเวลาหนึ่งครั้งและ (เช่น) คอลัมน์ข้อมูล 10 คอลัมน์ตามที่อธิบายไว้ข้างต้น แต่ตอนนี้แต่ละคอลัมน์แสดงชุดเวลาที่แตกต่างกัน สิ่งนี้ต้องการการปรับปรุงในตารางเมตาดาต้าซึ่งไม่ใช่การค้นหาในชื่อตารางและคอลัมน์ พื้นที่เก็บข้อมูลลดลง การค้นหายังคงง่าย อย่างไรก็ตามช่วงที่ต่อเนื่องกันคิวรีเอนทิตีเดี่ยวต้องการการเข้าถึงดิสก์เพิ่มขึ้นอย่างมาก
Mega-table: นำแนวคิด "multi-plexing" มาสู่สุดขั้วและนำข้อมูลทั้งหมดไปไว้ในตารางเดียวเมื่ออนุกรมเวลาต่อคอลัมน์ สิ่งนี้ต้องการการเข้าถึงดิสก์จำนวนมากสำหรับช่วงที่ต่อเนื่องกันคำสั่งเอนทิตีเดียวและเป็นฝันร้ายการบำรุงรักษา ตัวอย่างเช่นการเพิ่มเอนทิตีใหม่ต้องใช้คำสั่งแก้ไขตารางบนตาราง TB จำนวนมาก
สำหรับการอภิปรายเพิ่มเติมเกี่ยวกับรูปแบบนี้ดูคำตอบต่าง ๆ ใน:
มีคอลัมน์มากเกินไปใน MySQL
ตารางที่ทำให้เป็นมาตรฐานแบบเต็ม:
แทนที่จะใช้ตาราง 2 คอลัมน์จำนวนมากคุณสามารถใช้หนึ่งตารางสามคอลัมน์ซึ่งคอลัมน์คือเวลา dataid และค่า ตอนนี้ตารางเมทาดาทาของคุณต้องการค้นหาค่า ID เท่านั้นแทนที่จะเป็นชื่อแท็บหรือคอลัมน์
ขณะนี้มีการใช้ที่จัดเก็บข้อมูลประมาณ 2/3 ของคอลัมน์ Normalizing ดังนั้นจะใช้พื้นที่ดิสก์จำนวนมาก
คุณสามารถใช้คำสั่งคีย์หลักของ (dataid, timestamp) สำหรับการสืบค้นเอนทิตีเดี่ยวอย่างรวดเร็วที่ต่อเนื่องกัน หรือคุณสามารถใช้คำสั่งคีย์หลักของ (การประทับเวลา. dataid) สำหรับการแทรกที่เร็วขึ้น
อย่างไรก็ตามหลังจากพิจารณาความผันแปรเหล่านี้แล้วแผนของฉันสำหรับการพัฒนาครั้งต่อไปของฉันคือตารางจำนวนมากแต่ละคอลัมน์สองคอลัมน์ นั่นหรือวิธีการที่เร็ว ๆ นี้จะมีการโพสต์โดยคนที่ฉลาดกว่าฉัน :)