วิธีที่ดีในการจัดเก็บคอลัมน์จำนวนมากคืออะไร

ฉันมีปัญหาในการตัดสินใจว่าจะเก็บข้อมูลนี้ในฐานข้อมูลของฉันอย่างไร ข้อเสนอแนะเกี่ยวกับวิธีที่ดีที่สุดที่จะทำมัน? ฉันไม่รู้เกี่ยวกับฐานข้อมูลจำนวนมากฉันอาจเพิ่ม

ฉันมีข้อมูลมาในรูปแบบเช่นนี้ แต่มากกว่า 4 จำนวนคอลัมน์คือประมาณ 240 ดังนั้นวันที่แต่ละวันจึงมีค่าที่ไม่ซ้ำกันจำนวน 240 ค่าที่เกี่ยวข้อง:

Date/Time 200,00 202,50 205,00  
2010.11.12  13:34:00  45,8214 43,8512  41,5369   
2010.11.12  13:35:00  461,9364  454,2612  435,5222 

นอกจากนี้แถวยังเชื่อมโยงกับ DataSites ด้วย

ความคิดแรกของฉันคือการมีตารางดังนี้: DataID (pk), DataSiteID, ParameterID, Date, Value พร้อมดัชนีใน DataSite, Parameter และ Date พารามิเตอร์ ID อ้างถึงตารางอื่นที่เก็บส่วนหัวคอลัมน์อินพุต (200,00 202,50 205,00 ... )

ความคิดที่สองของฉันคือการมีโต๊ะที่มีคอลัมน์ทั้งหมด 240 คี่ ฉันคิดวิธีอื่นมาสองสามวิธี แต่มันก็ค่อนข้างน่าพอใจเช่นกัน

ปัญหาที่ฉันมีกับวิธีแก้ปัญหาแรกของฉัน (ไม่ใช่ปัญหาใหญ่ แต่ฉันไม่ชอบ) ก็คือวันที่และ DataSiteID จะถูกทำซ้ำสำหรับค่า 240 ทั้งหมดในแถวอินพุตนั้นดังนั้นจึงใช้ค่อนข้างน้อย ของพื้นที่พิเศษ

จะมีข้อมูลประมาณ 40gb ต่อปีที่เข้ามา (ในรูปแบบข้อความด้านบน) และข้อมูลจะถูกค้นหาโดย DataSite, Parameter และ Date จำนวนข้อมูลที่เข้ามาจะเป็นสี่เท่าในปีหรือมากกว่านั้น

มีความคิดที่ดีไหม? ขอบคุณเจมส์

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

แก้ไข:ขอบคุณสำหรับคำตอบพวกฉันขอบคุณจริง ๆ :) ฉันคิดว่าฉันอาจหาเวลาทำการทดลองด้วยข้อมูลทดสอบ 500gb หรือมากกว่านั้น ฉันจะโพสต์กลับพร้อมข้อสรุปใด ๆ ;)

คุณสามารถทำกรณีใดกรณีหนึ่ง แต่ถ้าข้อมูลจะถูกนำมาใช้สำหรับการวิเคราะห์และคุณมักจะต้องการเห็นหลายคอลัมน์จากข้อมูลในเวลาเดียวกันให้ไปกับตารางกว้าง ตรวจสอบให้แน่ใจว่าคุณทราบจำนวนคอลัมน์ฐานข้อมูลและขีด จำกัด ขนาดของแถว ตรวจสอบให้แน่ใจว่าคุณได้รับประเภทข้อมูลที่ถูกต้อง หากหลายคอลัมน์เป็นโมฆะ SQL Server จะอนุญาตให้คุณปรับตารางให้เหมาะสม คุณสามารถลองใช้โซลูชัน NOSQL (ไม่ใช่แค่ SQL) สำหรับการวิเคราะห์ข้อมูลประเภทนี้

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

ฉันมีสถานการณ์ที่คล้ายกันมากกับคุณฟิลด์ 257 แห่งที่มี 30-50gb ต่อปีฉันจบลงด้วยการทำให้มันง่ายโต๊ะโตหนุ่มตัวยาวหนึ่งตัวใน SQL Server ข้อมูลของฉันถูกถามค่อนข้างยุติธรรม แต่ส่วนใหญ่อยู่ในวันที่และมันทำงานได้ดี

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

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

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

ความคิดแรกของฉันคือการมีตารางดังนี้: DataID (pk), DataSiteID, ParameterID, Date, Value พร้อมดัชนีใน DataSite, Parameter และ Date พารามิเตอร์ ID อ้างถึงตารางอื่นที่เก็บส่วนหัวคอลัมน์อินพุต (200,00 202,50 205,00 ... )

การตั้งค่าฐานข้อมูลเป็นการติดตั้ง PostgreSQL มาตรฐานบนเครื่อง dual core เก่าที่มี RAM ขนาด 3gb ฉันใช้แบบสอบถามที่แตกต่างกันประมาณโหลโดยเลือกข้อมูลตาม DataSite Date และ ParameterID ข้อมูลเฉลี่ยในช่วงเวลา 1 ชั่วโมงระยะเวลา 1 วันและแทรกข้อมูลใหม่ ๆ จากหน่วยความจำแบบสอบถามทั้งหมดใช้เวลาดำเนินการน้อยกว่าหนึ่งวินาที มันเร็วกว่าที่คาดไว้มากและใช้งานได้ดีอย่างแน่นอน สิ่งหนึ่งที่ฉันไม่ได้คิดก็คือเมื่อตารางทำดัชนีด้วยวิธีนี้ไฟล์ดัชนีก็เกือบ 500gb เช่นกันดังนั้นการมีตารางที่มีคอลัมน์กว้าง 240 คอลัมน์แทนที่จะช่วยประหยัดพื้นที่ดิสก์ได้อย่างแน่นอน

ใน Postgres ฉันจะแก้ปัญหานี้ด้วยประเภทอาเรย์หรือvarrayใน Oracle

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

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

Otoh หากการกระจายการสืบค้นของพวกเขามากหรือน้อยฉันจะโหลดชุดตัวอย่างที่มีมูลค่าไม่กี่วันในตารางที่หนึ่งระเบียนเก็บค่าทั้งหมดเพื่อดูว่าอัตราส่วนอยู่ระหว่าง records / db-blocks (หรือถ้า แม้จะมีปัญหาการผูกมัดแถวซึ่งน่าจะเป็น) ขึ้นอยู่กับว่าฉันจะตัดสินใจออกแบบเพิ่มเติมแล้ว

ทีนี้หลังจากที่อ่านมันฉันอาจทำทั้งสองวิธีเพื่อให้มีการแบ่งออกเป็นสองส่วน

ฉันกำลังอ่านคำถามอีกครั้ง - ถ้าฉันถูกต้องแล้วในแต่ละระเบียนที่คุณได้รับเป็นอินพุตมีค่าต่าง ๆ ที่ถูกติดตาม (ขึ้นอยู่กับพารามิเตอร์ ID):

พารามิเตอร์ ID อ้างถึงตารางอื่นที่เก็บส่วนหัวคอลัมน์อินพุต (200,00 202,50 205,00 ... )

... ฉันไม่รู้มากพอเกี่ยวกับวิธีที่คุณโต้ตอบกับข้อมูล แต่ฉันอยากจะไปกับตัวเลือกอื่น - มีตารางแยกต่างหากสำหรับแต่ละพารามิเตอร์ ID จากนั้นหากจำเป็นต้องมีมุมมองที่จะ เข้าร่วมพารามิเตอร์ต่าง ๆ ตามวันที่และสถานที่ลงในตารางที่กว้างขึ้น (240 คอลัมน์); หากเป็นสิ่งสำคัญที่จะต้องให้ DataID สามารถเข้าถึงได้ในมุมมองคุณสามารถใช้ a UNIONแทนJOINได้ แต่คอลัมน์จะมีประชากรเบาบาง