การจัดเก็บข้อมูลจำนวนมากจากอาร์เรย์เซ็นเซอร์

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

การทำผลรวมจึงนำไปสู่:

• 8640 ตัวอย่างต่อเซ็นเซอร์ต่อวัน
• ข้อมูล 242kB ต่อเซ็นเซอร์ต่อวัน
• 864 ล้านตัวอย่างต่อวัน

ตอนนี้ฉันสงสัยว่าวิธีที่ดีที่สุดในการจัดเก็บ / ดึงข้อมูลคืออะไร? ฉัน "เข้าร่วม" โครงการนี้หลังจากที่ซอฟต์แวร์ได้ถูกระบุไว้แล้วดังนั้นจึงต้องดำเนินการบนแพลตฟอร์ม Windows โดยใช้ SQL Server

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

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

โดยทั่วไปฉันจะเขียนตัวอย่างจากเซ็นเซอร์ทั้งหมดเป็นไฟล์ชั่วคราว (1 ต่อเซ็นเซอร์) ในตอนท้ายของแต่ละวันฉันจะสร้างรายการในตารางที่ 1 ใช้ RecordID ที่สร้างขึ้นและดัมพ์ไฟล์ลงในฟิลด์ Data ในตารางที่ 2

ด้วยวิธีนี้ฉันมีเพียง 100,000 รายการลงในตารางต่อวันแทนที่จะเป็น 864 ล้านรายการ ข้อมูลควรมีอยู่ใน LAN หรือ WAN ความเร็วสูงดังนั้นการดึงข้อมูลเซ็นเซอร์ตลอดทั้งวันจึงเป็นที่ยอมรับได้

แม้ว่าข้อมูลทั้งหมดจะต้องถูกเก็บไว้ แต่ส่วนใหญ่ก็อาจจะไม่เคยอ่าน ดังนั้นจำนวนการอ่านบนโต๊ะจะไม่มากไปกว่าการเขียน

ฉันรู้ว่าฉันสามารถใช้บางสิ่งบางอย่างโดยใช้ระบบไฟล์โดยเพียงแค่เก็บเส้นทางไปยังไฟล์ข้อมูล แต่ฉันอ่านว่า SQL Server มีประสิทธิภาพดีกว่า NTFS ในขณะที่เขตข้อมูลไบนารีของคุณน้อยกว่าขอบคุณ 256kB (พื้นที่สีเทาอยู่ระหว่าง 256kB ถึง 1MB ในขณะที่ NTFS มีประสิทธิภาพเหนือกว่า SQL Server สำหรับขนาดไบนารี> 1 MB)

ฉันยังระมัดระวังในการจัดเก็บข้อมูลจากเซ็นเซอร์ 100,000 ตัวลงในไฟล์ของตนเองโดยไม่ทำให้เกิดปัญหาในระบบไฟล์โดยอาจมีไฟล์จำนวนมากในโฟลเดอร์หรือโดยมีโครงสร้างต้นไม้ที่ซับซ้อนพร้อมด้วยไฟล์จำนวนเล็กน้อยในแต่ละโฟลเดอร์ แม้จะคำนึงถึงการแตกไฟล์

1. ใครสามารถให้คำแนะนำ / ความคิดเห็นที่เป็นประโยชน์กับฉันได้บ้าง

2. มีข้อผิดพลาดที่เห็นได้ชัดว่าฉันกำลังจะตกอยู่ใน?

3. ข้อมูลตัวอย่างทำการบีบอัดได้ค่อนข้างดี ไฟล์ 242 kB บีบอัดได้ถึงประมาณ 85kB อย่างไรก็ตามฉันสามารถใช้การบีบอัดบางชนิดในระดับฐานข้อมูลเพื่อให้ข้อมูลตัวอย่าง (คอลัมน์) ถูกบีบอัดโดยอัตโนมัติได้หรือไม่

4. SQL Server เป็นตัวเลือกที่ผิดอย่างชัดเจนสำหรับโครงการนี้หรือไม่?

5. การออกแบบของฉันของทั้งสองตารางนั้นชาญฉลาดหรือฉันอาจรวมมันเข้ากับตารางเดียวที่จะยังคงเป็น "นักแสดง" เหมือนสองตารางได้หรือไม่?

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

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

ทางออกคืออะไร? การแบ่งตาราง. อ่านเกี่ยวกับเรื่องนี้ในเชิงลึกในหลาย ๆ สถานที่เท่าที่จะทำได้ โดยทั่วไปการแบ่งพาร์ติชันช่วยให้คุณสามารถแยกข้อมูลของคุณลงใน "ตารางภายในตาราง" - แต่ละพาร์ติชั่นใช้สคีมาเดียวกันและเข้าถึงได้ผ่านวัตถุตาราง แต่สามารถจัดทำดัชนีและบำรุงรักษาแตกต่างกันได้ พาร์ติชันนั้นเป็นตารางโดยทั่วไปมีการตัดโดยใช้คีย์ที่มีประโยชน์ ในกรณีของคุณอาจเป็นวันที่ พวกเขาสามารถลดลงเช่นเดียวกับ (และเร็วเท่า) ตารางซึ่งหมายความว่าถ้าคุณแบ่งตารางข้อมูลขนาดใหญ่ของคุณตามวันที่คุณสามารถวางพาร์ทิชันเก่าทันทีโดยไม่มีผลกระทบต่อดัชนีในพาร์ติชันอื่น ๆ คุณสามารถใส่พาร์ติชั่นในกลุ่มไฟล์ที่แตกต่างกันซึ่งหมายความว่าพาร์ติชั่นเก่าสามารถนำไปม้วนหรือรีดไปที่ที่เก็บสินค้าราคาถูกได้ถ้าไม่ได้ใช้กันโดยทั่วไป สุดท้าย แต่ไม่ท้ายสุดใน SQL 2012 คุณ 'ในพาร์ติชันที่เก่ากว่าและเป็นแบบอ่านอย่างเดียวของคุณในขณะที่มีรูปแบบการจัดทำดัชนีแบบแทรกที่แตกต่างกันมากขึ้นบนพาร์ติชันที่ใช้งานอยู่ซึ่งคุณใส่ข้อมูลเซ็นเซอร์ทั้งหมดของคุณ

หวังว่านี่จะช่วยได้ คุณมีงานวิจัยเกี่ยวกับการแบ่งพาร์ติชันและการแบ่งพาร์ติชันเป็นจำนวนมาก แต่หวังว่าตอนนี้คุณจะรู้ทิศทางที่คุณต้องการ

PS: โอ้และฉันลืมรายการคำถามที่มีสัญลักษณ์แสดงหัวข้อย่อยของคุณ ... คำตอบ 1, 2 และ 5 ดูด้านบน คำตอบ 3: ใน SQL Server คุณสามารถบีบอัดพาร์ติชันตามพาร์ติชันพื้นฐานดังนั้นบีบอัดพาร์ติชันเก่าของคุณโดยใช้การบีบอัดหน้า แต่ฉันเชื่อว่าประเภทข้อมูลขนาดใหญ่ที่อยู่นอกแถวของคุณจะไม่ถูกบีบอัดหากคุณทำเช่นนี้ - อีกครั้งคุณอาจต้องการบรรเทาปัญหานี้ด้วยการทำให้ค่าเซ็นเซอร์ของคุณเป็นปกติ คำตอบ 4: ไม่อย่างแน่นอน แต่ถ้าคุณต้องการทำคือเก็บข้อมูลแบบสแตติกในแต่ละวันและไม่เคยค้นหาด้วยวิธีอื่นไฟล์แบบแฟลตที่บีบอัดอาจเป็นวิธีที่ง่ายกว่ามาก

PPS: โอ้และอีกอย่าง คุณไม่ต้องการโซลูชันสองตารางเพื่อให้ทำงานได้ทั้งหมด ข้อมูลเซ็นเซอร์ไบนารีขนาดใหญ่ควรเป็นประเภท VARBINARY (MAX) เนื่องจากค่าสามารถจัดเก็บได้ " นอกแถว " แต่ยังคงเป็นคอลัมน์ในตารางเดียว (ดูเอกสารประกอบsp_tableoption ) คุณอาจต้องการพิจารณาปรับข้อมูลเซ็นเซอร์ของคุณให้เป็นปกติจากข้อมูลเลขฐานสองที่คุณมีในตารางเนื่องจากฐานข้อมูลของคุณจะไม่ดีเกินกว่าการเรียกค้นข้อมูลเซ็นเซอร์ตามเวลาหากคุณไม่ต้องการ

พิจารณาโซลูชัน Hadoop 2 Tb / วันเพิ่มขึ้นอย่างรวดเร็ว ให้พิจารณาการบันทึกเฉพาะระเบียนเดลต้าเช่นค่าเริ่มต้นและเมื่อมีการเปลี่ยนแปลงเกิดขึ้นเท่านั้น