PostgreSQL สำหรับธุรกรรมปริมาณมากและคลังข้อมูล

ค่อนข้างใหม่สำหรับ PostgreSQL ฉันไม่เคยใช้งานขนาดใหญ่มาก่อน แต่ฉันมีประสบการณ์ที่ดีในโซลูชันระดับองค์กรและฉันต้องการลองใช้สิ่งที่ฉันเรียนรู้โดยใช้ PostgreSQL

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

การออกแบบควรมีสองฐานข้อมูลฐานข้อมูลธุรกรรมหลักและคลังข้อมูลเพื่อจัดการการวิเคราะห์และการรายงาน

ฐานข้อมูลธุรกรรมหลัก

จะถูกใช้สำหรับเว็บไซต์สดเว็บไซต์นี้สร้างขึ้นบนหลายโหนดเพื่อขยายขนาดผู้ใช้พร้อมกัน ส่วนใหญ่เราต้องการฐานข้อมูลสำหรับกรณีนี้ที่จะรวดเร็วในการดำเนินการอ่านเราคาดว่า> ข้อมูล 100GB กับการเติบโต 30% ต่อปี ณ จุดนี้เราวางแผนที่จะใช้เซิร์ฟเวอร์ EC2 สองเครื่อง ( และเพิ่มในภายหลังตามที่เราต้องการ )

คำถามของฉันการตั้งค่าที่แนะนำสำหรับข้อกำหนดข้างต้นคืออะไร นอกจากนี้มีวิธีจัดการตารางและการแบ่งพาร์ติชันของไดรฟ์ข้อมูลหรือไม่? มีคำแนะนำสำหรับการใช้การตั้งค่า AWS หรือไม่

ฐานข้อมูลคลังข้อมูล

ส่วนใหญ่จะใช้สำหรับการจับข้อมูลทั้งหมดจากฐานข้อมูลธุรกรรมหลักในมิติเวลา ดังนั้นแม้ลบบันทึกจากฐานข้อมูลหลักจะถูกจับใน DWH ดังนั้นข้อมูลจะมีขนาดใหญ่มากและการเติบโตจะยิ่งใหญ่ขึ้น นอกจากนี้เรายังจะใช้อินสแตนซ์คู่ EC2 ขึ้นไปหากต้องการ

การตั้งค่าที่แนะนำในกรณีนี้คืออะไร? สิ่งนี้จะต้องใช้การเขียนที่รวดเร็วเนื่องจากการเขียนคงที่ (ETL) เราสามารถสร้าง OLAP คิวบ์ใน PostgreSQL ได้ไหม? ถ้าใช่มีใครลองทำบ้างไหม?

กำลังเชื่อมต่อกับฐานข้อมูล

เว็บเซิร์ฟเวอร์จะเชื่อมต่อกับฐานข้อมูลหลักเพื่อสืบค้นและเขียน ขณะนี้เรากำลังพัฒนาแอปพลิเคชั่นโดยใช้ django ซึ่งใช้ไลบรารีดั้งเดิมสำหรับการเชื่อมต่อ แนะนำให้ใช้วิธีการพื้นฐานเดียวกันหรือไม่ หรือเราควรกำหนดค่า pgpool?

คลังข้อมูล (ETL)

วิธีที่แนะนำสำหรับการสร้างกระบวนการ ETL เพื่ออ่านจากหลักและโหลดไปยังคลังข้อมูลคืออะไร? มีเครื่องมืออะไรบ้าง? วิธีการที่จะปฏิบัติตาม? PostgreSQL เสนอฟังก์ชั่น / เครื่องมือที่เป็นประโยชน์ในการสร้างกระบวนการ ETL หรือไม่?

บริการโครงสร้างพื้นฐาน / ฐานข้อมูล

คุณควรอ่านบทความนี้เพื่อดูภาพรวมของไซต์ปริมาณมากที่ทำงานบน AWS ด้วย EBS พวกเขาย้ายไปที่ที่จัดเก็บชั่วคราว แต่ต้องสร้างความซ้ำซ้อนในการจัดเก็บข้อมูลอีกครั้ง

http://blog.reddit.com/2012/01/january-2012-state-of-servers.html

Data Warehouse / ETL

ฉันเคยใช้ Pentaho มาก่อน ไม่ใช่กับ postgres โดยตรง แต่ฉันพบว่าเป็นวิธีแก้ปัญหาที่ดีสำหรับทั้ง OLAP (Mondrian) และ ETL (Kettle)

http://www.pentaho.com/

แก้ไข: "Community Editions" สามารถพบได้ที่นี่

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

สัมพันธ์

คนเหล่านี้ดูเหมือนจะชอบ pgbouncer จริงๆ /programming/1125504/django-persistent-database-connection

แม้ว่าฉันจะไม่มีประสบการณ์กับมัน เห็นได้ชัดว่า Disqus ใช้มัน

การตั้งค่าของคุณคล้ายกับที่ฉันพัฒนาขึ้นสำหรับมหาวิทยาลัย ฐานข้อมูลไม่ใหญ่มาก แต่มีขนาดค่อนข้างใหญ่ประมาณ 300GB และตารางที่ใหญ่ที่สุดมีระเบียนประมาณ 500 ล้านระเบียน และยังคงเติบโต

เพื่อจุดประสงค์สองเซิร์ฟเวอร์ที่มีเนื้อมาก ๆ (เหล็กจริงไม่ใช่เวอร์ช่วลไลเซชัน) เซิร์ฟเวอร์หนึ่งสำหรับการจัดการข้อมูลจากเว็บไซต์และเซิร์ฟเวอร์อื่นที่ใช้สำหรับการคำนวณและวิเคราะห์ทางสถิติ ข้อมูลถูกจำลองแบบทั้งสองทิศทางโดยใช้ Slony ข้อมูล OLTP ถูกจำลองแบบไปยังเซิร์ฟเวอร์ OLAP อย่างต่อเนื่องและ schema ที่บางและตารางเดียวถูกจำลองแบบจาก OLAP- เซิร์ฟเวอร์ไปยัง OLTP ด้วยวิธีนี้การคำนวณจำนวนมากสามารถทำได้บนเซิร์ฟเวอร์การวิเคราะห์โดยไม่ส่งผลกระทบต่อเซิร์ฟเวอร์ OLTP ปัจจุบันมีทางเลือกบางอย่างสำหรับ Slony สำหรับการจำลองข้อมูล: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

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

ในขณะที่เซิร์ฟเวอร์ OLAP จะเติบโตอย่างต่อเนื่องคุณควรพิจารณาใช้พาร์ทิชันบางประเภทถ้ามี

หากมีความเป็นไปได้ให้ใช้การรวมการเชื่อมต่อ ฉันใช้ PgPool เพียงอย่างเดียวและใช้งานได้อย่างไม่มีที่ติ PgBouncer เป็นอีกทางเลือกหนึ่ง นอกจากการลดเวลาแฝง init แล้วยังช่วยลดการเริ่มต้นเซสชันและการจัดการเซสชัน http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

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

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

โครงสร้างของฐานข้อมูลจำเป็นต้องได้รับการพิจารณาอย่างรอบคอบ การใช้สคีมานั้นดีสำหรับการรวบรวมและทำให้ง่ายต่อการจัดการกับวัตถุ มันอาจดูยุ่งยากที่จะเริ่มต้นด้วยการใช้ schemas แต่เมื่อจำนวนวัตถุเพิ่มขึ้นคุณจะต้องขอบคุณตัวเอง การรู้ว่าคุณต้องนำหน้าวัตถุด้วยสคีมาของวัตถุอย่างชัดเจนคุณจะรู้ว่าคุณใช้วัตถุใดอยู่ http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

สำหรับคนที่กล้าหาญ PostgreSQL XC เป็นทางเลือกที่น่าสนใจหรือเป็นเพียงชุดที่มีขนาดใหญ่http://postgres-xc.sourceforge.net/