PostgreSQL: ไม่มีทั้ง VACUUM และ Bloat อีกต่อไป

 (orioledata.com)
2 คะแนน โดย GN⁺ 2023-07-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OrioleDB เอนจินสตอเรจใหม่สำหรับ PostgreSQL ช่วยตัดขั้นตอน VACUUM ที่ใช้ทรัพยากรสูงออกไป และแก้ปัญหา table bloat
  • PostgreSQL แบบเดิมต้องพึ่ง MVCC จึงต้องมีทั้ง manual vacuum และ autovacuum ซึ่งทั้งสองแบบใช้ทรัพยากรระบบค่อนข้างมาก
  • OrioleDB ใช้ undo log ระดับแถวและระดับบล็อก พร้อม การรวมเพจอัตโนมัติ เพื่อจัดการการเปลี่ยนแปลงข้อมูลอย่างมีประสิทธิภาพและรวมข้อมูลที่กระจัดกระจายเข้าด้วยกัน
  • ใน synthetic benchmark การอัปเดตเพียงอินเด็กซ์เดียว การรวม sparse page อัตโนมัติ และการใช้ WAL ระดับแถว ทำให้ได้ TPS สูงขึ้น 5 เท่า พร้อมลดการใช้ทรัพยากร
  • ช่วยแก้ปัญหาเรื้อรังอย่าง VACUUM เพื่อลดภาระการดูแลรักษา และมอบ ประสิทธิภาพและประสบการณ์ผู้ใช้ที่ดีขึ้น ให้กับ PostgreSQL

ประวัติและข้อจำกัดของ PostgreSQL VACUUM

  • กระบวนการ VACUUM เป็นมรดกทางประวัติศาสตร์ที่มีที่มาจากแนวคิด infinite time-travel ของโครงการ Berkley Postgres ซึ่งต่อมาถูกยกเลิกโดยคอมมูนิตี้
    • อย่างไรก็ตาม สิ่งนี้นำไปสู่การใช้งานระบบ MVCC(Multi-Version Concurrency Control) ที่เปราะบางต่อ table bloat
  • MVCC เหมาะกับการจัดการทรานแซกชันพร้อมกัน แต่ก็นำมาซึ่งความจำเป็นของ manual vacuuming สำหรับล้างข้อมูลเก่าและข้อมูลที่ไม่จำเป็น
    • manual vacuuming เป็นงานที่ใช้แรงมากและอาจเป็นสาเหตุของความไม่มีประสิทธิภาพในระบบ
  • ต่อมาได้มีการเพิ่ม autovacuum แบบอัตโนมัติเพื่อลดภาระงานแบบแมนนวล
    • นับเป็นความก้าวหน้าครั้งใหญ่ แต่ไม่ใช่คำตอบที่สมบูรณ์ และถึงจะเป็นอัตโนมัติก็ยังใช้ทรัพยากรระบบมาก
    • นี่เป็นหนึ่งในเหตุผลที่ Uber ย้ายจาก PostgreSQL ไป MySQL และยังถูกกล่าวถึงว่าเป็นหนึ่งใน 10 ข้อไม่พอใจ PostgreSQL ที่ Richard Branson เคยพูดถึง
  • การเพิ่ม Heap-Only Tuples(HOT) updates และ microvacuum ช่วยลดความจำเป็นในการทำ vacuum ทั้งตาราง
    • ถึงอย่างนั้น VACUUM ก็ยังคงเป็นงานที่ใช้ทรัพยากรสูง และตารางก็ยังเสี่ยงต่อ bloat
    • เรื่องนี้ถูกกล่าวถึงว่าเป็นส่วนที่ ทีม OtterTune เกลียดที่สุด ใน PostgreSQL
  • แม้มีข้อจำกัดเหล่านี้ หลายองค์กรและนักพัฒนาก็ยังคงใช้ PostgreSQL ต่อไป เพราะความเสถียร ความสามารถในการขยายระบบ และคอมมูนิตี้ที่แข็งแกร่ง
    • OtterTune ยอมรับปัญหาเหล่านี้ แต่ก็ตัดสินใจใช้งาน PostgreSQL ต่อไป

ความสามารถหลักของ OrioleDB

  • OrioleDB คือ เอนจินใหม่สำหรับ PostgreSQL ที่พัฒนาขึ้นโดยมีเป้าหมายหลักเพื่อปกป้องตารางจาก bloat และตัดความจำเป็นของงานบำรุงรักษาเป็นระยะอย่าง VACUUM
  • ใช้ undo log ระดับแถวและระดับบล็อก ร่วมกับ การรวมเพจอัตโนมัติ เพื่อทำสิ่งนี้ให้เกิดขึ้น
    • undo log ระดับแถวและระดับบล็อกให้การควบคุมที่ละเอียดมากขึ้น จึงจัดการการเปลี่ยนแปลงข้อมูลได้อย่างมีประสิทธิภาพ
    • ฟีเจอร์รวมเพจอัตโนมัติจะรวมข้อมูลที่กระจัดกระจายอยู่เบื้องหลังอย่างต่อเนื่อง
  • วิธีการทำงานของแต่ละเทคนิค
    • undo log ระดับแถวรองรับ in-place update
    • undo log ระดับบล็อกช่วยลบ tuple ที่ถูกลบไปแล้วแต่ยังมองเห็นได้จากบางทรานแซกชันออกจากสตอเรจหลัก เพื่อเปิดพื้นที่ให้ tuple ใหม่
    • การรวม sparse page อัตโนมัติช่วยป้องกันไม่ให้ตารางและอินเด็กซ์เกิด bloat แม้จะมีการลบจำนวนมาก
  • ผลลัพธ์คือ ลดการแทรกแซงด้วยมือ ลดการใช้ทรัพยากร และลดความเปราะบางต่อ table bloat

เบนช์มาร์ก

  • ใช้ synthetic benchmark ที่ประกอบด้วยสคริปต์เริ่มต้นซึ่งสร้าง 1 ตารางและ 5 อินเด็กซ์
    • สร้างตาราง test ที่มีคอลัมน์ id เป็น primary key และ value1~value4 (float8), ts (timestamp)
    • สร้างอินเด็กซ์แยกสำหรับ value1, value2, value3, value4, ts
  • สคริปต์ pgbench เป็นรูปแบบ upsert ที่เมื่อเกิด conflict จะทำ sparse update กับอินเด็กซ์เพียงตัวเดียว
    • ทำ INSERT ด้วย id แบบสุ่มในช่วง 1~10,000,000 และเมื่อเกิด conflict จะอัปเดตเฉพาะ ts
    • sparse update ลักษณะนี้ทำให้เกิด index bloat ในตาราง heap ปกติของ PostgreSQL
  • ข้อดีของการออกแบบ OrioleDB ที่เบนช์มาร์กนี้แสดงให้เห็น
    • ด้วย undo log และ in-place update ทำให้ OrioleDB อัปเดตเฉพาะอินเด็กซ์เดียวที่ค่ามีการเปลี่ยนแปลง ขณะที่ heap engine ของ PostgreSQL จะถูก HOT ทำให้ใช้ไม่ได้ เมื่อมีการอัปเดตฟิลด์อินเด็กซ์เพียงตัวเดียว จึงต้องอัปเดตทุกอินเด็กซ์
    • การรวมเพจอัตโนมัติช่วยป้องกัน sparse index จาก bloat และ sparse page จะถูกรวมโดยอัตโนมัติ
    • WAL ระดับแถวใช้พื้นที่น้อยกว่า WAL ระดับบล็อกมาก จึง ลด IOPS ตอนเขียน WAL
  • ตัวเลขที่ OrioleDB ทำได้จากผลการปรับปรุงสะสม
    • TPS สูงขึ้น 5 เท่าต่อทรานแซกชัน
    • ภาระ CPU ต่ำลง 2.3 เท่าต่อทรานแซกชัน
    • IOPS ต่ำลง 22 เท่าต่อทรานแซกชัน
    • ไม่มี table และ index bloat

ความสำคัญของ OrioleDB

  • การมาของ OrioleDB ทำให้คอมมูนิตี้ PostgreSQL เข้าสู่ยุคใหม่ที่ VACUUM อาจกลายเป็นเรื่องของอดีต
  • นำเสนอแนวทางแก้ปัญหาสำคัญที่เก่าแก่ที่สุดข้อหนึ่งของ PostgreSQL พร้อมมอบประสิทธิภาพที่ดีขึ้นและลดภาระการดูแลรักษาให้ผู้ใช้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-16
ความคิดเห็นจาก Hacker News

  • ถึงอย่างนั้นก็ยังมีบางอย่างที่ติดใจอยู่ การประมวลผลระดับแถว ทำให้เกิดปัญหาเรื่องการจัดเรียงการเขียนและการจัดเรียง fsync และหน้านั้นจัดเรียงได้ง่ายกว่าแถวที่มีขนาดไม่แน่นอน
    PostgreSQL ระมัดระวังเรื่องความปลอดภัยของข้อมูลอย่างมาก หรืออาจถึงขั้นอนุรักษ์นิยมจัด ๆ และสิ่งนี้ทำได้หลัก ๆ ผ่าน fsync ในจังหวะที่เหมาะสม ซึ่งผลกระทบของมันลามไปทั่วทั้ง I/O stack รวมถึงเฟิร์มแวร์ SSD ทำให้ช้าลง
    MVCC ดีมากสำหรับการเข้าถึงพร้อมกัน แต่เอกสารของ Oriole ไม่ได้บอกว่ากราฟนั้นมาจากเงื่อนไขด้าน concurrency แบบใด
    ชื่อเรื่องและบทนำของเอกสาร Oriole เน้นที่การ แก้ปัญหา VACUUM แต่ดูเหมือนจะยังไม่ได้พิสูจน์จริง ๆ ว่ากราฟ “คลื่นสี่เหลี่ยม” ที่เห็นใน PostgreSQL ส่วนใหญ่เกิดจาก VACUUM จริง Percona มี benchmark อื่น(https://www.percona.com/blog/evaluating-checkpointing-in-postgresql/)ที่ไม่แสดงรูปแบบคลื่นสี่เหลี่ยมชัดเจนแบบนี้
    ผู้เขียนเองก็น่าจะรู้ปัญหาเหล่านี้อยู่แล้ว จึงอาจเขียนภาพรวมว่าเข้าหามันอย่างไรได้

    • OrioleDB ใช้ WAL ระดับแถว แต่ก็ยังใช้หน้าอยู่ WAL ระดับแถวทำได้เพราะมี copy-on-write checkpoint ซึ่งให้ภาพของ B-tree ที่สอดคล้องกันในเชิงโครงสร้าง ดูรายละเอียดได้ในเอกสารสถาปัตยกรรม
      https://github.com/orioledb/orioledb/blob/main/doc/arch.md
      เพราะ PostgreSQL ระมัดระวังเรื่องความปลอดภัยของข้อมูลมาก เป้าหมายแรกจึงคือการเป็นส่วนขยายแบบล้วน ๆ หากจะกลายเป็นส่วนหนึ่งของ PostgreSQL ก็ต้องผ่านการพิสูจน์ตามกาลเวลา
      จริงที่ข้อมูลเรื่อง concurrency ขาดไป และได้เพิ่มประเภท VM กับข้อมูล concurrency ลงในบล็อกโพสต์แล้ว
      รูปแบบคลื่นสี่เหลี่ยมเกิดจาก checkpoint จริง สาเหตุของการปรับปรุงตรงนี้จริง ๆ ไม่ใช่ VACUUM แต่เป็นวิธีที่แก้ไขเฉพาะดัชนีที่เกี่ยวข้อง และ WAL ระดับแถวที่ช่วยลด I/O โดยรวม

  • น่าสนใจดี แต่ก็สงสัยว่ามีแผนจะตาม รอบการออกรุ่น ของโปรเจ็กต์แม่อย่างไร
    ถ้า fork โปรเจ็กต์โอเพนซอร์สขนาดใหญ่แล้วใส่การเปลี่ยนแปลงจำนวนมากเข้าไป และไม่ได้คิดว่าการเปลี่ยนแปลงนั้นจะถูกรับเข้า upstream ก็ไม่แน่ใจว่านี่เป็นความคิดที่ดีไหม
    ควรทำให้ชัดว่าเป็นของเล่นที่ทำเอาสนุก หรือเป็นโปรเจ็กต์จริงจังที่จะดูแลต่อไป
    ถ้าเป็นโปรเจ็กต์จริงจัง ก็ควรระบุแผนว่าจะไม่ให้กลายเป็นซอฟต์แวร์ที่ถูกทิ้งในอนาคตอย่างไร จะรับเอารีลีสในอนาคตของโปรเจ็กต์เดิมมาอย่างไร หรือจะไปแยกเป็นโปรเจ็กต์อิสระเต็มตัว
    เพราะเป็นส่วนขยายก็ดูเหมือนว่าน่าจะรับการเปลี่ยนแปลง upstream ของ PostgreSQL ได้ แต่ถ้ามันง่ายขนาดนั้นก็คงได้กลายเป็นส่วนหนึ่งของโปรเจ็กต์ PostgreSQL ไปตั้งแต่แรกแล้ว เลยดูไม่น่าง่ายนัก

    • ผู้เขียนตอบไว้แล้วในคอมเมนต์ของโพสต์
      “ใช่ครับ แต่ยังอีกไกล ตอนนี้ OrioleDB เป็นส่วนขยายที่มาพร้อมแพตช์ของ PostgreSQL core เป้าหมายระยะกลางคือทำให้ OrioleDB เป็นส่วนขยายแบบล้วน ๆ และเป้าหมายระยะยาวคือทำให้ OrioleDB กลายเป็นส่วนหนึ่งของ PostgreSQL core”
    • ฟังดูแรงเกินไปทั้งที่ไม่ได้จะเอาไปใช้โปรดักชันในอีกไม่กี่วันนี้ แถมก็ไม่ได้แสดงความตั้งใจจะสนับสนุนโปรเจ็กต์ในทางการเงิน และอย่างที่คนอื่นชี้ คำถามนี้ก็มีคำตอบอยู่แล้ว
      คราวหน้าคงดีกว่าถ้าไม่เปิดมาด้วยน้ำเสียงหนักขนาดนี้ตั้งแต่แรก
    • มีลิงก์อ้างอิงที่ตอบไว้แล้ว :)
      https://news.ycombinator.com/item?id=36742001
    • เป็นประเด็นที่สมเหตุสมผล ในฐานะคนที่เคยเจอปัญหา VACUUM มาก่อน ก็สงสัยว่านี่เป็นสิ่งที่จำเป็นโดยพื้นฐานจริง ๆ หรือเป็นสิ่งที่แก้ไขได้
      แค่ได้เห็นตัวอย่างที่แก้ได้ก็ช่วยได้มากแน่นอน ถ้าเป็นบริษัทที่มีทรัพยากรพอจะดูแล Postgres fork เองก็ดีไป ไม่อย่างนั้นก็ต้องประเมินว่าความยากในการใช้ fork นี้คุ้มกับประโยชน์ด้านประสิทธิภาพหรือไม่

  • อยากให้เลิกพูดทำนองว่า “Uber ย้ายจาก Postgres ไป MySQL” ได้แล้ว จริง ๆ แล้ว Uber ย้ายจาก Postgres ที่ใช้เป็นฐานข้อมูลเชิงสัมพันธ์ ไปเป็นระบบที่ใช้ MySQL เป็นที่เก็บคีย์-แวลูแบบกระจาย จนแทบจะเป็น ฐานข้อมูลแบบไม่เชิงสัมพันธ์ ที่ทำขึ้นเอง ดังนั้นจึงไม่ใช่กรณีที่เอามาใช้กับผู้ใช้ Postgres ส่วนใหญ่ได้ตรง ๆ
    อย่างไรก็ตาม การออกแบบ MVCC แบบย้ายข้อมูลเก่าไปไว้ใน undo log/segment นั้น Oracle DB ก็ใช้เหมือนกัน จึงถือว่ากลไกนี้ผ่านการพิสูจน์แล้ว
    ความยากที่พบร่วมกันคือความเร็วในการอ่านข้อมูลเวอร์ชันเก่าจะช้าลง เพราะต้องไปค้นจาก log และบางครั้งข้อมูลก็อาจถูกลบออกจาก log ก่อนที่ทรานแซกชันจะจบ ทำให้เกิดข้อผิดพลาด Snapshot Too Old อันเลื่องชื่อได้
    ในบทความผมไม่เห็นว่าระบุไว้ว่าแถวข้อมูลจะถูกลบออกจาก undo log เมื่อใด ถ้าลบเมื่อไม่จำเป็นแล้ว ก็น่าจะยังต้องมีงานดูแลจัดการในปริมาณใกล้เคียงกัน เลยยังไม่ค่อยเห็นว่าจุดที่ดีขึ้นอยู่ตรงไหน และถ้ามันเป็น circular buffer ที่พื้นที่เต็มได้แบบ Oracle ก็จะค่อนข้างน่าหงุดหงิด เพราะภายใต้ภาระงานเขียนสูง ทรานแซกชันที่รันนานจะเริ่มล้มเหลว

    • undo record จะถูกตัดทิ้งเมื่อไม่มีทรานแซกชันใดต้องใช้อีกต่อไป
      คำว่า “งานดูแลจัดการ” หมายถึงอะไรอย่างเจาะจงก็มีผล ถ้ามองในแง่ปริมาณงาน undo record เก่าสามารถลบแบบยกชุดได้ในราคาถูกมาก เช่น unlink ไฟล์ทิ้ง จึงมีจุดที่ดีขึ้นอยู่ตรงนี้ ไม่ต้องมีการสแกน VACUUM
      ถ้ามองในแง่การใช้พื้นที่ จำนวนเวอร์ชันเท่ากันก็ย่อมกินพื้นที่เท่ากันอยู่แล้ว แต่การย้าย row version เก่าไปไว้ในสตอเรจแยก จะช่วยป้องกันไม่ให้สตอเรจหลักเสื่อมสภาพในระยะยาว และ OrioleDB ก็มีการรวม sparse page อัตโนมัติด้วย
      OrioleDB ใช้ circular buffer ในหน่วยความจำสำหรับ undo log ถ้า circular buffer เก็บ undo record ทั้งหมดไม่ไหว ก็จะส่ง record ที่เก่าที่สุดออกไปยังสตอเรจ ตอนนี้ไม่มีการจำกัดขนาด undo log และจะเก็บ record ไว้ตราบเท่าที่ทรานแซกชันใด ๆ อาจยังต้องใช้ ดังนั้นจึงไม่มีข้อผิดพลาด “Snapshot Too Old”
      อย่างไรก็ตาม อาจพิจารณาทำข้อผิดพลาดแบบ Oracle เป็นตัวเลือก เพื่อให้สามารถจำกัดขนาด undo ได้ ลองดูเอกสารสถาปัตยกรรมบน GitHub ด้วยก็น่าจะดี
      https://github.com/orioledb/orioledb/blob/main/doc/arch.md
    • SQL Server ก็หลีกเลี่ยง VACUUM เช่นกัน และอาจใช้แนวทางลักษณะนี้
      ส่วน MySQL ก็หลีกเลี่ยง VACUUM โดยยอมลดทอนเรื่อง concurrency ลงพอสมควร

  • ชื่อเรื่องชวนคาดหวัง แต่ความประทับใจแรกกลับค่อนข้างอึดอัด README หลักบน GitHub[1] ให้ความรู้สึกเหมือน ข้อความประชาสัมพันธ์สไตล์องค์กร
    เท่าที่อ่านมาจนถึงตอนนี้ สิ่งที่รู้ก็คือ OrioleDB เป็น storage engine ใหม่สำหรับ PostgreSQL, PostgreSQL เป็นฐานข้อมูลที่ “คนรักมากที่สุด”, OrioleDB เป็น extension ที่ซ้อนอยู่บน extension อื่น ๆ และ OrioleDB จะเปิดประตูสู่คลาวด์ อะไรทำนองนั้น
    ถ้าเป็นหลังจากยุคหลอกลวงคริปโตกับ Web 3.0 ผ่านไปแล้ว ผมคงคิดว่าควรหลีกเลี่ยงวิธีนำเสนอลักษณะนี้เวลาจะเปิดตัวโครงการที่ใช้ขยายและปรับปรุงสิ่งสำคัญอย่าง PostgreSQL
    [1] https://github.com/orioledb/orioledb

    • น่าจะหมายถึงส่วนนี้: “OrioleDB consists of an extension, building on the innovative table access method framework and other standard Postgres extension interfaces.”
      ผมว่าแทบจะเขียนให้ชัดกว่านี้ไม่ได้แล้ว table access method เป็นความสามารถที่ถูกเพิ่มเข้ามาใน PostgreSQL เพื่อรองรับรูปแบบสตอเรจทางเลือก เช่น zheap หรือสตอเรจแบบคอลัมน์
      การกล่าวถึงเรื่องนี้สำคัญ เพราะมี PostgreSQL fork อยู่ไม่น้อยที่เอาระบบจัดเก็บข้อมูลทางเลือกมาครอบไว้ แต่ OrioleDB ถูกออกแบบให้ทำงานเป็น extension บน PostgreSQL ที่ไม่ได้ fork แม้ตอนนี้จะยังไม่ถึงจุดนั้นเต็มตัว แต่ทิศทางคือแบบนั้น
      ถ้าคุ้นเคยกับ PostgreSQL อยู่แล้ว README นี้ก็น่าจะถือว่าชัดเจนมาก

  • ดีไซน์ของ Oriole ดูเหมือนจะต้องใช้อินเด็กซ์ที่รับรู้สถานะของทรานแซกชัน และต้องรองรับการลบเอนทรีแบบระบุตำแหน่งเป็นจุด ซึ่งมีต้นทุนแฝงของมันเอง
    ตัวอย่างเช่น สิ่งที่เทียบได้กับ GiST สำหรับ spatial index น่าจะดูแลยาก เพราะโดยธรรมชาติแล้วเรามักไม่รู้ตำแหน่งที่แน่นอนของแต่ละ index tuple ขณะที่สิ่งที่เทียบได้กับ GIN สำหรับ full-text search indexing ก็อาจมีขนาดใหญ่มาก เพราะการบีบอัด posting tree ทำได้ไม่ดีนัก
    นอกจากนี้ ในกรณีที่ใช้ index-organized table ก็ยังนึกภาพไม่ค่อยออกว่าจะทำสิ่งที่เทียบได้กับ BRIN อย่างไร BRIN น่าสนใจเพราะช่วยตัดช่วงใหญ่ ๆ ของตารางจริงออกจากผลลัพธ์คิวรีได้อย่างรวดเร็วเมื่อไม่มีข้อมูลที่น่าสนใจอยู่ อาจพาร์ทิชันตามช่วงของ primary key ได้ก็จริง แต่ความหนาแน่นของค่าของ primary key อาจต่างกันมากตามเวลาและช่วงค่า
    เลยอยากรู้ว่ามีแผนจะทำ index method ที่ซับซ้อนกว่าแต่มีประโยชน์มากเหล่านี้อย่างไร
    อีกประเด็นคือปัญหาที่อาจเกิดขึ้นเมื่อกฎการเรียงลำดับหรือ collation เปลี่ยนไป heap และ VACUUM ของ Postgres ไม่รับรู้ลำดับการเรียง จึงมักซ่อมความเสียหายได้โดยลบแถวที่อยู่ผิดตำแหน่งหลังจากเปลี่ยน collation แล้วแทรกกลับเข้าไปใหม่ จากนั้น VACUUM ก็ค่อยเก็บ tuple ที่แตกหักออกในภายหลัง
    แต่ Oriole ดูเหมือนจะทำแบบนั้นได้ยาก เพราะไม่สามารถหา tuple ต้นฉบับที่จะต้องลบด้วย point lookup ได้ และการซ่อมกรณี index เสียหายที่รู้จักกันอยู่แล้วอาจต้อง rebuild index ทั้งหมด ทำให้ภาระการดูแลรักษาดูสูงพอสมควร

    • สำหรับสิ่งที่คล้าย GiST เรากำลังคิดในแนวทางสร้าง B-tree บน space-filling curve บางแบบ และยังมีแผนเพิ่ม union key ใน internal page เพื่อให้การค้นหาในต้นไม้นี้เร็วขึ้นและง่ายขึ้น
      สำหรับสิ่งที่คล้าย GIN การบีบอัด posting list ก็ยังทำได้อยู่ ทางเลือกหนึ่งคือผูก undo record เข้ากับ posting list ทั้งชุด แทนที่จะผูกกับแต่ละรายการใน posting list
      ส่วน BRIN น่าจะไม่มีของที่เทียบตรงตัวได้ เพราะเราใช้ index-organized table แต่ก็อาจทำอะไรน่าสนใจได้กับ union key ใน internal page ของ primary key
      เรื่อง collation นั้นถูกต้องและเป็นประเด็นสำคัญ ก่อนจะไปถึง GA เราน่าจะต้องตรึงอินเด็กซ์ทั้งหมดที่รับรู้ collation ไว้กับ libicu collation version ที่ระบุแน่นอน

  • ตรรกะของบทความก็ดูน่าเชื่อถือ และเบนช์มาร์กก็ดูเหมือนจะรองรับข้ออ้างเรื่องประสิทธิภาพ แต่ยังไม่ค่อยเข้าใจการแบ่งแยกระหว่างเอนจินจัดเก็บข้อมูลใหม่ที่เสนอ คือ OrioleDB กับตัว PostgreSQL เอง
    นอกจากแรงจูงใจเชิงพาณิชย์และเหตุผลที่อยากสร้างรายได้จากนวัตกรรมที่กล่าวถึงในบทความแล้ว มีเหตุผลอะไรไหมที่ต้องทำการตลาดมันเป็น ฐานข้อมูลใหม่ชื่อ OrioleDB แทนที่จะส่งปรับปรุงนี้กลับเข้า upstream?

    • มองว่า OrioleDB เป็นเอนจินแห่งอนาคตของ PostgreSQL และอยากให้มันกลายเป็นเอนจินเริ่มต้น
      แต่การเปลี่ยนแปลงของ OrioleDB ใหญ่เกินกว่าจะค่อย ๆ ใส่เข้าไปได้ ดังนั้นตอนนี้จึงกำลังเปรียบเทียบ OrioleDB กับเอนจินปัจจุบันของ PostgreSQL ซึ่งไม่ใช่แค่ heap แต่รวมถึงซับซิสเต็มย่อยหลายส่วนด้วย
    • ความเห็นของ Alexander Korotkov ดูเหมือนจะตั้งอยู่บนประสบการณ์ในฐานะ committer ของ Postgres ว่าการเปลี่ยนแปลงเหล่านี้มีขนาดใหญ่เกินกว่าจะถูกยอมรับเข้า upstream ได้ จึงต้องไปในรูปแบบเอนจินแยก
      รายละเอียดดูได้ที่ https://www.socallinuxexpo.org/sites/default/files/presentations/solving-postgres-wicked-problems.pdf โดยเฉพาะสไลด์ 9–11
    • การเปลี่ยนแปลงเหล่านี้ใหญ่เกินกว่าจะรวมเข้ากับเอนจินของ PostgreSQL เองได้ เพราะมันเปลี่ยน แนวทาง MVCC ในระดับพื้นฐาน

  • ถ้าเป็นส่วนขยายของเอนจิน ก็สงสัยว่าจะมีผลกระทบเมื่อใช้ร่วมกับส่วนขยายอื่นหรือไม่ เช่น timescaledb[0] ทำงานกับตารางลูก
    อยากรู้ว่าถ้าทำแบบนี้จะเกิดผลอย่างไร
    create table xyz(...) using orioledb;
    select create_hypertable(xyz, ts);
    [0] https://github.com/timescale/timescaledb

  • OrioleDB สนใจจะรับปากเรื่อง รูปแบบ on-disk ที่เสถียร เพื่อไม่ให้ต้องมีขั้นตอนอัปเกรดระหว่าง Postgres เวอร์ชันหลักหรือไม่? มันดูเหมือนเป็นโอกาสในการแก้ปัญหานี้

    • เหตุผลที่ PostgreSQL ต้องมีขั้นตอนอัปเกรด ปกติไม่ได้มาจากรูปแบบ on-disk ระดับล่างของ Postgres heap หรือ table access method ของ OrioleDB แต่เป็นเพราะ การเปลี่ยนแปลงของ catalog ของ Postgres
      เรื่องอย่างการเพิ่ม type ใหม่และฟังก์ชันสนับสนุนของมัน จำเป็นต้องถูกใส่ผ่านขั้นตอนอัปเกรดบางอย่าง ยังมีการเปลี่ยนแปลง catalog อื่น ๆ ที่ไปปรับ layout ของคอลัมน์ในตาราง catalog ซึ่งกรณีนั้นก็ต้องมีขั้นตอนสำหรับอัปเดตข้อมูลที่เก็บอยู่ระหว่างเวอร์ชันด้วย
      ถ้าไม่มีขั้นตอนอัปเกรด ก็จะเปลี่ยน catalog ไม่ได้ นั่นจึงเป็นเหตุผลว่าทำไมมีเพียงการอัปเกรด PostgreSQL เวอร์ชันย่อยเท่านั้นที่ทำได้ด้วยการสลับไบนารีอย่างเดียว และ rollback กลับได้อย่างปลอดภัยโดยไม่มีปัญหา
      ถ้าการอัปเกรดถูกจำกัดให้มีแค่การเปลี่ยนแปลง internal API, planner และ executor การพัฒนาก็จะถูกจำกัดอย่างหนัก ดูแล้ว OrioleDB คงช่วยตัดความจำเป็นของขั้นตอนอัปเกรดนี้ออกไปได้ยาก
    • มองเผิน ๆ แล้วดูเหมือนเป็นไปไม่ได้ เว้นแต่จะยอมแลกประสิทธิภาพไปมากพอสมควร รูปแบบ on-disk จะเปลี่ยนก็ต่อเมื่อมีเหตุผลที่ดีเท่านั้น
    • ไม่ค่อยแน่ใจว่าสิ่งนั้นจะช่วยได้อย่างไร PostgreSQL ให้คำมั่นเรื่องรูปแบบ on-disk ของตารางและดัชนีที่เสถียรอยู่แล้วในทางปฏิบัติ จึงทำให้ pg_upgrade ทำงานได้
      งานส่วนใหญ่ของการอัปเกรดคลัสเตอร์มาจากการเขียนตาราง catalog ใหม่ อีกทั้งสำหรับเวิร์กโหลดส่วนใหญ่ pg_upgrade ก็เร็วมากอยู่แล้ว จึงไม่ค่อยเห็นว่าประโยชน์ก้อนใหญ่จะเกิดขึ้นตรงไหน

  • สะดุดใจกับคำว่า “ลดโอเวอร์เฮด CPU ต่อทรานแซ็กชันลง 2.3 เท่า” อยู่เหมือนกัน Postgres มีการใช้ CPU ขึ้น ๆ ลง ๆ ตั้งแต่ 5% ถึง 65% แต่ Oriole อยู่ที่ 90% ตลอด
    ความคาดเดาได้เป็นเรื่องดี แต่การดันช่วงล่างขึ้นมาอีก 85% ก็ดูน่ากังวลพอสมควรไม่ใช่หรือ

    • ปกติแล้วการใช้ CPU ให้เต็มที่ที่สุดถือว่าเป็นเรื่องดี Oriole ดูเหมือนจะมีความต้องการ I/O ต่ำกว่ามาก จึงประมวลผลทรานแซ็กชันได้มากกว่ามากและไปติดคอขวดที่ CPU
      ข่าวดีก็คือหมายความว่าถ้าสเกลขึ้นในแนวตั้งด้วย CPU ที่แรงกว่า ก็จะรีดประสิทธิภาพจาก Oriole ได้มากขึ้นอีก ในทางกลับกัน Postgres น่าจะไม่สามารถเพิ่มประสิทธิภาพต่อไปได้แบบเดียวกัน
      ถ้ามองจากมุมของระบบปฏิบัติการเดสก์ท็อป เวลาว่างของเซิร์ฟเวอร์ Postgres อาจเอาไปใช้ทำอย่างอื่นได้ แต่สำหรับเซิร์ฟเวอร์ ปกติแล้วเราต้องการให้มันทำงานอย่างเดียว และอยากได้เครื่องที่ปรับแต่งมาสำหรับงานนั้น
    • การตีความของผมคือ CPU ถูกทำให้เต็มถึง 90% เพราะค่า TPS threshold ที่ใช้ในการเปรียบเทียบ อย่างน้อยในกราฟนี้ TPS ของ Oriole คงที่และสูงกว่า pg มาก
      ถ้าลด TPS ลง CPU ก็น่าจะลดลงตามสัดส่วน และที่นี่น่าจะตั้งใจแสดงให้เห็นว่ามันขึ้นไปได้สูงแค่ไหน
    • ถ้าปลดเพดานการใช้ CPU ได้ ก็ไม่ใช่ปัญหา เพราะจะลดการใช้งานลงพร้อมรักษาประสิทธิภาพตามสัดส่วนไว้ได้ค่อนข้างง่าย
      ถ้าจำกัดระบบไว้ที่ CPU 60% ตัวเลขรวมอาจเปลี่ยนไป แต่ถ้าที่การใช้งานเท่ากัน TPS สูงกว่า 1.8 เท่า ก็ยังถือว่าชนะอยู่ดี ดูไม่ใช่กลเม็ดการตลาดเท่าไร แต่เป็นตัวเลขที่ค่อนข้างดี
      ถ้า CPU เซิร์ฟเวอร์ราคาแพงมีต้นทุน X ดอลลาร์ต่อหน่วย แต่ใช้ได้แค่ 60% และในความเป็นจริงก็ใช้ได้เท่านั้น เท่ากับคุณเผาเงินไป 0.4X ดอลลาร์ต่อหน่วย
      ถ้าคุณยกเวิร์กโหลดขึ้นในแนวตั้งจนทำให้เครื่องหนึ่งเครื่องอิ่มตัวได้ถึง 90% โดยทั่วไปก็สามารถใช้เทคนิค QoS และการแยกงานเพื่อรักษาระดับความอิ่มตัวที่ต่ำกว่าและประสิทธิภาพตามสัดส่วนได้ง่ายกว่า ตรงกันข้ามไม่เป็นจริง ถ้าคุณใช้ความอิ่มตัวของทั้งเครื่องได้แค่ 60% แล้วต้องสเกลเอาต์ ก็ต้องรีดีไซน์ใหม่ถึงจะไปเกิน 90% ได้ และตรงนี้ก็คือการรีดีไซน์นั้นเอง
    • ตอนนี้ประสิทธิภาพบนฮาร์ดแวร์ชุดเดิมดีขึ้น 5 เท่าแล้ว TPS สูงขึ้น 5 เท่า แม้จะต้องทดสอบใหม่ด้วยฮาร์ดแวร์ที่มากขึ้น แต่ถ้ายังรักษาประสิทธิภาพได้ 3 เท่าในช่วงล่าง ก็อาจเป็นทางเลือกที่ดีสำหรับผู้ใช้บางกลุ่ม
      จากผลสะสมของการปรับปรุง OrioleDB ระบุว่ามีคุณสมบัติคือ TPS สูงขึ้น 5 เท่า, ภาระ CPU ต่อทรานแซ็กชันต่ำลง 2.3 เท่า, IOPS ต่อทรานแซ็กชันต่ำลง 22 เท่า และไม่มีการพองตัวของตารางและดัชนี
    • นี่เป็นการทดสอบประสิทธิภาพ และมีความเป็นไปได้สูงว่าจุดประสงค์คือการใส่โหลดสูงสุดที่ DB engine แต่ละตัวรับได้อย่างต่อเนื่องเป็นเวลานาน
      การที่ภาระ CPU ขึ้น ๆ ลง ๆ ไม่ได้หมายความว่า Postgres “สเกล” แต่หมายความว่ามันเจอคอขวดด้านประสิทธิภาพเป็นระยะ ๆ น่าจะเป็นเพราะต้องรัน VACUUM ซึ่งไวต่อ I/O มาก
      ดังนั้น Postgres จึงเอา I/O ไปใช้กับงานทำความสะอาดแทนการประมวลผลคิวรี และ TPS กับการใช้ CPU ก็ร่วงลงพร้อมกัน
      ส่วน Oriole จัดการ throughput ที่สูงกว่ามากได้อย่างสม่ำเสมอกว่ามาก ถ้าคุณเหยียบคันเร่งสุด คุณจะชอบรถที่วิ่ง 100mph ได้คงที่ หรือรถที่แม้จะเหยียบคันเร่งจมพื้นแล้วก็ยังแกว่งหนัก ๆ ระหว่าง 40~70mph มากกว่ากัน?

  • ในบทความมีลิงก์ที่ใช้ชื่อค่อนข้างน่าสนใจว่า “10 things Richard Branson hates about PostgreSQL” ปรากฏว่าคนเขียนบล็อกนั้นไม่ใช่ Richard แต่เป็น Rick Branson

    • Rick เป็นชื่อเล่นของ Richard
    • “Richard Branson” ไม่ใช่ตัวระบุที่เป็นเอกลักษณ์ บางทีพวกเราทุกคนอาจควรใช้ UUID
    • ผมก็สะดุดกับส่วนนั้นเหมือนกัน คิดอยู่ว่าทำไมผมต้องสนด้วยว่า CEO ของ Virgin คิดอย่างไรกับฐานข้อมูล
      อ้อ ไม่ใช่คนนั้นนี่เอง