ใหญ่แค่ไหนสำหรับตาราง PostgreSQL?

127

ฉันกำลังดำเนินการออกแบบโครงการ RoR สำหรับ บริษัท ของฉันและทีมพัฒนาของเราได้พบกับการถกเถียงกันเล็กน้อยเกี่ยวกับการออกแบบโดยเฉพาะฐานข้อมูล

เรามีรูปแบบที่เรียกMessageว่าต้องคงอยู่ เป็นโมเดลขนาดเล็กมากที่มีคอลัมน์ db เพียงสามคอลัมน์นอกเหนือจาก id แต่จะมีโมเดลเหล่านี้จำนวนมากเมื่อเราไปที่การผลิต เรากำลังดูการแทรกมากถึง 1,000,000 ครั้งต่อวัน โมเดลจะถูกค้นหาโดยคีย์ต่างประเทศสองคีย์เท่านั้นซึ่งสามารถจัดทำดัชนีได้ เช่นกันแบบจำลองไม่จำเป็นต้องถูกลบ แต่เราไม่จำเป็นต้องเก็บไว้เมื่อมันมีอายุประมาณสามเดือน

ดังนั้นสิ่งที่เราสงสัยคือการใช้ตารางนี้ใน Postgres จะทำให้เกิดปัญหาด้านประสิทธิภาพที่สำคัญหรือไม่? ใครมีประสบการณ์เกี่ยวกับฐานข้อมูล SQL ขนาดใหญ่มากช่วยบอกเราได้หรือไม่ว่าปัญหานี้จะเป็นปัญหา? ถ้าเป็นเช่นนั้นเราควรเลือกทางเลือกใด

— Dylan Karr
แหล่งที่มา

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

— แซม

คำถามที่เกี่ยวข้องที่นี่และที่นี่

— Erwin Brandstetter

เราประมวลผลข้อความประมาณ 30 ล้านข้อความต่อวันในฐานข้อมูล PostgreSQL ขนาด 5+ TB ซึ่งทำงานได้ดี

— Frank Heikens

ดูstackoverflow.com/questions/3132444/…

— rogerdpack

FYI ฉันบังเอิญอ่านpostgresql.org/aboutวันนี้และสังเกตเห็นว่า (โดยหลักการ) จำนวนแถวในตารางไม่ จำกัด

— Al Chou

คำตอบ:

115

แถวต่อตารางจะไม่เป็นปัญหาในตัวมันเอง

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

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

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited

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

ฉันยอมรับว่า 90 ล้านแถวจะไม่เป็นปัญหาสำหรับ PostgreSQL แต่อาจเป็นปัญหาสำหรับ ORM กับ PostgreSQL (เป็น ORM ที่มี dbms จริง ๆ )

— Mike Sherrill 'Cat Recall'

@ MikeSherrill'Catcall 'จุดดีคือผมเน้นแค่ว่า "ตาราง PostgreSQL ใหญ่เกินไปแค่ไหน"

— Kuberchaun

@yeyo: เนื่องจาก ORM มักจะใช้แบบสอบถามจำนวนมากเพื่อรับข้อมูลที่สามารถส่งคืนได้โดยมีเพียงหนึ่งหรือสองรายการ OP ใช้ Ruby on Rails

— Mike Sherrill 'Cat Recall'

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

— Stefan Theard

URL เกี่ยวกับที่อ้างถึงใน URL ไม่แสดงขีด จำกัด เหล่านี้ในปัจจุบัน - ใครทราบว่าถูกย้ายไปที่ใด?

— ตัด

อีกวิธีหนึ่งในการเร่งความเร็วการสืบค้นของคุณอย่างมีนัยสำคัญบนตารางที่มีมากกว่า 100 ล้านแถวคือในช่วงนอกเวลาทำการจัดกลุ่มตารางในดัชนีที่มักใช้ในการสืบค้นของคุณ เรามีตารางที่มี> 218 ล้านแถวและพบว่ามีการปรับปรุง 30 เท่า

นอกจากนี้สำหรับตารางที่มีขนาดใหญ่มากคุณควรสร้างดัชนีบนคีย์ต่างประเทศของคุณ

— เจมส์โดเฮอร์ตี้
แหล่งที่มา

> ในช่วงนอกเวลาทำการจัดกลุ่มตารางในดัชนีที่ใช้บ่อยที่สุดในการสืบค้นของคุณ .... คุณสามารถอธิบายได้ว่าทำอย่างไร

— สายลับ

ใช่นี่คือทีละขั้นตอนตัวอย่าง: 1) ตารางที่ฉันอ้างถึงเรียกว่าการลงทุนในตัวอย่างนี้ 2) ดัชนีที่ใช้บ่อยที่สุดในการสืบค้นคือ (bankid, record_date) ดังนั้นนี่คือขั้นตอนของคุณ: 1) psql -c "drop index investment_bankid_rec_dt_idx;" dbname 2) psql -c "สร้างดัชนีการลงทุน _bankid_rec_dt_idx ในการลงทุน (bankid, record_date);" 3) psql -c "คลัสเตอร์ Investment_bankid_rec_dt_idx ในการลงทุน" 4) vacuumdb -d ccbank -z -v -t การลงทุนดังนั้นในขั้นตอนที่หนึ่งและสองเราจะวางดัชนีและสร้างขึ้นใหม่

— James Doherty

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

— James Doherty