การจัดเก็บและการสืบค้นข้อมูลการกลิ้งใน PostgreSQL

ฉันมีข้อมูลโมเดลสภาพอากาศจำนวนมากถูกใส่ลงในฐานข้อมูล PostgreSQL เครื่องมี 8 คอร์และ RAM 16 GB ฉันใช้ PostgreSQL 9.3 กับ PostGIS 2.1 แต่ละตารางจะมีข้อมูลสภาพอากาศที่แตกต่างกัน (อุณหภูมิจุดน้ำค้างลม ฯลฯ ) แต่ละตารางจะมีคอลัมน์ 6-7 คอลัมน์: ละติจูดลองจิจูดลองจิจูดเรขาคณิตระดับความสูงวันที่และเวลาที่แบบจำลองนั้นเกี่ยวข้องและค่าข้อมูลที่น่าสนใจ 1-2 รายการ ข้อมูลจะถูกสอบถามเป็นหลักสำหรับกล่อง bounding ตามเวลาและระดับความสูง จะมีประมาณ 145,757,360 แถวต่อตาราง (ข้อมูลที่เก่ากว่าตอนนี้จะไม่ถูกลบอีกต่อไป) ฉันประมาณขนาดของตารางโดยประมาณประมาณ 10 GB โดยไม่มีดัชนี (นั่นคือข้อมูล 52 ไบต์บวก 23 ไบต์ค่าใช้จ่ายต่อแถว) ข้อมูลจะถูกอัปเดต / แทรกเป็นประจำเมื่อมีข้อมูลโมเดลใหม่ บันทึก:

ดังนั้นฉันดูที่แผนสองข้อนี้:

เพียงจัดทำดัชนีและจัดกลุ่มตาม (วันที่และเวลา, ระดับความสูง) พร้อมดัชนีเพิ่มเติมสำหรับรูปทรงเรขาคณิตของจุด รันงาน cron ปกติที่ลบแถวเก่ารันสุญญากาศ / วิเคราะห์และคลัสเตอร์อีกครั้ง
แบ่งพาร์ติชันตามวันที่และเวลาจากนั้นจัดกลุ่มและจัดทำดัชนีตามระดับความสูงต่อตารางด้วยดัชนีบนรูปทรงเรขาคณิต รันงาน cron ปกติเพื่อเพิ่มตารางใหม่ในอนาคตและวางตารางเก่า

เพิ่มเติม

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

เมื่อส่งข้อมูลการเลือกจะเร็วกว่าดัชนีคลัสเตอร์หรือไม่ คำตอบเปลี่ยนไปหรือไม่หากมีการร้องขอหลายครั้งพร้อมกัน?

ขอขอบคุณ. ฉันหวังว่าจะรวบรวมข้อมูลที่จำเป็นทั้งหมด ถ้าไม่แจ้งให้เราทราบและฉันจะเพิ่ม

— bshender
แหล่งที่มา

อย่างไรก็ตามแถวแคบ ๆ เหล่านี้เป็นที่ที่ส่วนหัวของแถวขนาดใหญ่ของ PostgreSQL เริ่มเจ็บจริงๆ สงสารมีไม่มากที่สามารถลบออกได้; มันไม่เหมือนกับที่เราสูญเสียxminหรือxmaxอื่น ๆ มีคุณสมบัติที่อาจทำให้เป็น 9.4 ที่อาจทำให้คุณตื่นเต้นซึ่งเรียกว่าดัชนี minmax ซึ่งจะทำให้สิ่งต่าง ๆ เช่นนี้สะดวกยิ่งขึ้น

— Craig Ringer

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

— AK

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

— bshender

Craig: พวกเขาดูน่าสนใจที่ฉันตั้งตาคอยที่จะทดลองกับพวกเขาเมื่อพวกเขาออกมา มีความคิดเห็นเกี่ยวกับการตั้งค่าของฉันใน 9.3 ไหม

— bshender

คุณช่วยให้ข้อมูลสองชิ้นได้โปรด: 1) อะไรคือสิ่งที่สำคัญที่สุดสำหรับคุณการเพิ่มความเร็วหรือความเร็วการสืบค้น? 2) ข้อความค้นหาใดที่พบบ่อยที่สุด

— โทมัส Kejser

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

ด้วยตัวเลือกที่มีอยู่การทำงานของข้อมูลที่สะอาดขึ้นและการหลีกเลี่ยงการสูญญากาศประจำวันเป็นสิ่งที่ดี

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

— Carlos Bueno
แหล่งที่มา