การเปรียบเทียบ MySQL และ PostgreSQL เลือกฐานข้อมูลระหว่าง mysql, postgresql, mariadb และ mssql? การเปรียบเทียบประสิทธิภาพของเซิร์ฟเวอร์ ms sql และ postgresql

พูดตามตรงแม้ว่า 1C Enterprise จะเข้ากันได้กับ DBMS จำนวนมาก แต่ในความเป็นจริง 99 เปอร์เซ็นต์ทำงานได้ใน MS SQL หรือใน PostgreSQL ฟรี

กล่าวอีกนัยหนึ่ง "โต๊ะย่อย" ทั้งสองนี้ได้พิชิตตลาด 1C ไคลเอนต์และเซิร์ฟเวอร์

และเราสามารถสรุปได้อย่างปลอดภัยว่าหากบริษัทไม่ทำงานใน MS SQL ก็มีแนวโน้มว่าพวกเขาจะใช้ PostgreSQL เพียงอย่างเดียว

ดังนั้นจึงเหมาะสมที่จะเปรียบเทียบ Postgres กับ MS SQL เท่านั้น

ทุกวันนี้ มีการเขียนมากมายเกี่ยวกับทั้ง MS SQL และ PostgreSQL แต่โดยปกติแล้วจะไม่ได้เปรียบเทียบกันอย่างเป็นกลาง

ในบทความนี้ เราจะวิเคราะห์ประเด็นทางเทคนิคหลักของ PostgreSQL ฟรี โดยเปรียบเทียบกับ MS SQL

สิ่งที่จะช่วยให้คุณตัดสินใจได้ดีที่สุดในอนาคต และเตรียมพร้อมสำหรับ "ความประหลาดใจ" ต่างๆ หรืออะไรจะเหมาะสมกับ "คุณสมบัติ" ของการทำงานใน DBMS ฟรีนี้มากกว่า

เราจะประเมินทุกอย่างตามที่เป็นอยู่ โดยไม่เพิ่มข้อดีที่ยังไม่มีและไม่ต้องตกแต่ง MS แบบชำระเงินให้กับ Postgres

ฉันจะตอบคำถามที่ทำให้มือใหม่หลายคนกังวลทันที!

ใช่! MS SQL ทำงานได้เร็วกว่า PostgreSQL นั่นคือข้อเท็จจริง! และมีเหตุผลหลายประการสำหรับเรื่องนี้!

บางทีฉันอาจทำให้ใครบางคนผิดหวังในทันทีและบางทีคุณอาจไม่เห็นด้วยกับข้อความนี้ฉันต้องขออภัย แต่ฟิสิกส์ของ DBMS ฟรีนี้ไม่อนุญาตให้นำหน้า MS SQL โดยเฉพาะอย่างยิ่งหากเรากำลังพูดถึงการรวมกันเช่น "มอนสเตอร์ 1C" และ PostgreSQL.

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

อย่างไรก็ตาม ประสิทธิภาพของ PostgreSQL ก็เพียงพอสำหรับผู้ใช้ สามารถทำงานได้อย่างสะดวกสบายใน 1C

ไม่ว่าจะเป็นผู้ใช้หลายสิบคนหรือหลายร้อยคนที่ทำงานพร้อมกันใน 1C Enterprise

ทำไมต้อง "มอนสเตอร์ 1C"?

ที่จริงแล้วนี่คือวิธีที่ 1C เห็น PostgreSQL โดยไม่ต้องติดตั้ง "แพตช์" และส่วนขยายพิเศษ

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

เหตุใดจึงเกิดเหตุการณ์เช่นนี้ และเหตุใดจึง "แพทช์"

ความจริงก็คือ 1C Enterprise สร้างตารางชั่วคราวจำนวนมากในกระบวนการทำงานที่เราสามารถพูดถึงได้ ประมาณหลายพันตารางต่อวินาทีและหากคุณใช้การลงทะเบียน "Slice of the ล่าสุด" - "ส่วนที่เหลือและการหมุนเวียน" ก็อาจจะเป็นไปได้เช่นกัน และเส้นละล้านบรรทัดเป็น.

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

ดังนั้นเบรกขนาดใหญ่ใน 1C!

แน่นอนว่าปัญหาเหล่านี้ไม่ใช่ทั้งหมดที่ต้องแก้ไขเพื่อให้ PostgreSQL ทำงานอย่างถูกต้องร่วมกับ 1C จำเป็นต้องมี "แพตช์" อื่น ๆ และ ส่วนขยายพิเศษและหลังจากผู้ใช้ 15-20 ราย จะมีเพิ่มอีก การตั้งค่าใน "config"

ใช่ ในความเป็นจริงทุกอย่างดูซับซ้อนกว่าที่ฉันอธิบายไว้ข้างต้นมาก แต่หากทำให้ง่ายขึ้นอย่างมาก ปัญหาหลักของการทำงานช้าของ 1C ด้วย PostgreSQL จะเป็นอย่างไร

สิ่งที่สองที่ฉันไม่ชอบเกี่ยวกับ PostgreSQL ก็คือ ขาดมัลติเธรดภายในคำขอเดียวเมื่อเทียบกับ MS SQL

(ตั้งแต่เวอร์ชัน 9.6 เป็นต้นไป เราได้พยายามดำเนินการค้นหาแบบคู่ขนานกันเป็นครั้งแรก แต่จนถึงตอนนี้ก็ยังทำงานได้ไม่ดี บางครั้งผลลัพธ์ก็ตรงกันข้าม) แต่สำหรับการพยายาม 5!)

แน่นอนว่ามีผลกระทบต่อประสิทธิภาพอย่างไรเพื่อให้คุณเข้าใจในแง่ง่ายๆ -

PostgreSQL สามารถทำให้เซิร์ฟเวอร์ 48 คอร์ของคุณเสียหายได้ด้วยคำถามสำคัญเพียงคำเดียว!

ง่ายมาก โดยไม่มีการขนานเธรดภายในคำขอเดียว และคำขอขนาดใหญ่หนึ่งคำขอจะ "โหลด" เพียงคอร์เดียวเท่านั้น

ใช่ หากมีคำขอจำนวนมาก ระบบจะโหลดคอร์ทั้งหมดและทุกอย่างจะทำงานได้ดี

และฉันเกือบลืมไปแล้ว เรากำลังเปรียบเทียบ PostgreSQL กับ MS SQL Standard ไม่ใช่ Express!

แม้ว่า Express จะสามารถใช้เพื่อวัตถุประสงค์ทางการค้าได้ แต่ก็มีข้อจำกัดหลายประการ

เช่น 10 GB ต่อฐาน, การใช้งานโปรเซสเซอร์เดี่ยว, 1 GB แรม,

ทำให้การใช้ผลิตภัณฑ์ดังกล่าวแทบจะเป็นไปไม่ได้เลยที่จะทำงานใน 1C Enterprise

ยกเว้นในกรณีที่คุณมีฐานข้อมูลขนาดเล็กมากและมีผู้ใช้เพียงไม่กี่คน (และถึงกระนั้นก็มีเบรกขนาด 1 GB น้อยมากสำหรับ DBMS)

เรามาเปรียบเทียบ PostgreSQL กับเวอร์ชัน Standard ยอดนิยมกันดีกว่า

สคริปต์!!!

PostgreSQL นั้นเป็นสคริปต์โดยหลักแล้วเมื่อเปรียบเทียบกับ MS SQL การดำเนินการส่วนใหญ่จะต้องทำด้วยมือ และแน่นอนว่าคุณสามารถติดตั้งและทำสิ่งพื้นฐานบางอย่างผ่านอินเทอร์เฟซได้ แต่ฉันขอย้ำว่าสิ่งพื้นฐานและขั้นตอนทางซ้ายคือ ก้าวไปทางขวาแล้วคุณต้องเขียนสคริปต์หรือ BAS บน Linux หรือ cmd, powershell บน Windows

ดูและวิเคราะห์การติดตามโดยใช้ SQL Server Profiler

SQL Server Profiler ที่รู้จักกันดีไม่มีอยู่ใน PostgreSQL และคำว่า "ขาดหายไป" ฉันหมายถึงโดยสิ้นเชิง อนิจจาไม่มีอะไรที่เหมือนกับใน PostgreSQL

แน่นอนว่ามียูทิลิตี้ที่ช่วยให้คุณถ้าคุณมีเวลาสกัดกั้นคำขอหรือตั้งค่าเบรกพอยต์ 1C ในดีบักเกอร์และรับบางสิ่งบางอย่างและดู แต่เมื่อเปรียบเทียบกับ Profiler อย่างที่พวกเขาพูดกันว่ามันไม่ใช่ ไม่ได้ปิดเลย

คุณสามารถตั้งค่าบันทึกแล้วจัดเรียงข้อมูลทั้งหมดได้ แต่จะใช้เวลานาน!

นี่คือตัวอย่าง:

โปรแกรมเมอร์ 1C กำลังพยายามแก้ไขข้อบกพร่องของแบบสอบถามขนาดใหญ่ โดยจะใช้เวลานานในการดำเนินการ เช่น 30 นาที แต่ใน PostgreSQL เพื่อให้ข้อมูลถูกรวมไว้ในบันทึก จะต้องดำเนินการแบบสอบถามนี้! คุณลองจินตนาการดูว่าจะใช้เวลานานเท่าใดในการแก้ไขข้อบกพร่องของคำขอดังกล่าว

ขณะที่อยู่ใน MS SQL คุณสามารถขัดจังหวะการดำเนินการสืบค้นและแยกวิเคราะห์ใน Profiler ได้ เนื่องจากจะมีอยู่แล้ว แต่มีสถานะ "ล้มเหลว"

Postgres มีทางเลือกในการสร้างการสำรองข้อมูลที่หลากหลายไม่เท่ากัน!

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

ตามความเป็นจริง มีการสำรองข้อมูลบางส่วนและการกู้คืนข้อมูลบางส่วน

คุณสามารถกำหนดค่าการเก็บถาวรแบบต่อเนื่องและการกู้คืนแบบช่วงเวลาได้ (การกู้คืนช่วงเวลา (PITR)).

อีกด้วย การจำลองแบบพร้อมใช้งานใน PostgreSQl โดยไม่มี "แพตช์" ของยูทิลิตี้หรือส่วนเพิ่มเติม!

• การจำลองแบบเรียงซ้อน
• การจำลองแบบสตรีมมิ่ง
• การจำลองแบบซิงโครนัส
• การเก็บถาวรอย่างต่อเนื่องบนเซิร์ฟเวอร์สำรอง

ทั้งหมดนี้มีให้บริการอยู่แล้วใน PostgreSQl และแน่นอนว่าไม่มีใน "express" และไม่มีในเวอร์ชัน MS SQL Standard

หากต้องการใช้ MS SQL ทั้งหมดข้างต้น คุณต้องซื้อ MS SQL Enterprise ที่มีราคาแพงมาก ซึ่งตอนนี้มีราคาประมาณ 15,000 เหรียญสหรัฐ

สิ่งที่ขาดหายไปเมื่อเปรียบเทียบกับ MS SQL?

ไม่มี "การสำรองข้อมูล" ที่แตกต่างกัน

ใช่ ใน PostgreSQl ไม่มี "การสำรองข้อมูล" ที่แตกต่างกัน แต่มีอะนาล็อกต่างๆ มากมายสำหรับการสร้าง "การสำรองข้อมูล" แบบเพิ่มทีละขั้น

ตัวอย่างเช่น การเพิ่ม "การสำรองข้อมูล" ในระดับบล็อก

มีการแยก TABLESPACE ซึ่งรองรับ 1C ตามค่าเริ่มต้นแล้ว!

ซึ่งยังไงก็ไม่ใช่ใน MS SQL!

ตัวอย่างเช่นคุณสามารถกำหนดค่าว่าคุณจะมี "ดัชนี" บนดิสก์ใดและ "ตาราง" จะอยู่ที่ดิสก์ใด ซึ่งสะดวกมากเมื่อวางแผนโครงสร้างพื้นฐานด้านไอทีของคุณเมื่อพูดถึงฐานข้อมูล 1C ขนาดใหญ่ ONLINE_ANALYZE เพื่อคำนวณสถิติใหม่ เช่นเดียวกับไฟล์ *dt

การใช้ PostgreSQl คุณแทบจะไม่ต้องการ REINDEX!

ที่จริงแล้วควรใช้เมื่อมีข้อสงสัยว่าความสมบูรณ์ของฐานข้อมูลเสียหายเท่านั้น

คุณสามารถ "สำรองข้อมูล" ได้โดยไม่รวมตาราง!

ตัวอย่างเช่น หากคุณมีโปรแกรมเมอร์ 1C หลายคนทำงานในบริษัทของคุณ พวกเขารับประกันว่าจะสร้างเองได้ การสำรองข้อมูลสร้าง “ข้อมูลสำรอง” เพื่อการพัฒนาต่อไป

เป็นผลให้ผู้ใช้ต้องทนทุกข์ทรมาน ฐานข้อมูลช้าลงในระหว่างการสร้าง "การสำรองข้อมูล" ขนาดใหญ่ โดยเฉพาะอย่างยิ่งหากฐานข้อมูลนี้มีสิ่งต่าง ๆ เช่นไฟล์ที่แนบมา ไฟล์เก็บถาวร และเอกสารจากตัวอักษร ตารางที่มีไฟล์ดังกล่าวสามารถมีได้หลายร้อยกิกะไบต์ได้อย่างง่ายดาย และสามารถยกเว้นใน PostgreSQl ได้ด้วยการสร้าง "ข้อมูลสำรอง" ซึ่งมีขนาดเล็กและมีฟังก์ชันการทำงานทั้งหมดในเวลาเดียวกัน

ด้วยวิธีนี้เราจะไม่โอเวอร์โหลด อุปกรณ์เครือข่ายเราไม่อุดตันช่องเราใช้เวลาน้อยกว่ามากในการสร้าง "ข้อมูลสำรอง"

ในที่สุดทุกคนก็ชนะ! ทั้งผู้ใช้โปรแกรมเมอร์และผู้ดูแลระบบนอนหลับอย่างสงบสุข

ในบทความนี้เราตรวจสอบเฉพาะความแตกต่างพื้นฐานระหว่าง PostgreSQl และ MS SQL (ยังมีอย่างอื่นอีก) แต่เมื่อตัดสินใจเลือก DBMS อย่างใดอย่างหนึ่งบทความนี้น่าจะช่วยได้!

โชคดีนะเพื่อนร่วมงาน!

ป.ล. ตอนนี้ฉันกำลังพัฒนาหลักสูตรใหม่ “1C และ PostgreSQL” (อยู่ในขั้นตอนการบันทึกแล้ว รออีกไม่นาน!)

ขอแสดงความนับถือ Bogdan

เพื่อรอการบรรยายของฉันที่ PGCONF.RUSSIA 2015 ฉันจะแบ่งปันข้อสังเกตบางประการเกี่ยวกับความแตกต่างที่สำคัญระหว่าง MySQL DBMSและ PostgreSQL เนื้อหานี้จะเป็นประโยชน์สำหรับทุกคนที่ไม่พอใจกับความเป็นไปได้อีกต่อไปและ คุณสมบัติ MySQLรวมถึงผู้ที่กำลังก้าวแรกใน Postgres แน่นอนว่าโพสต์นี้ไม่ควรถือเป็นรายการความแตกต่างที่ครบถ้วนสมบูรณ์ แต่จะเพียงพอที่จะตัดสินใจสนับสนุน DBMS อย่างใดอย่างหนึ่ง

การจำลองแบบ

ปัญหาคือระบบการจัดการพื้นที่จัดเก็บข้อมูลจำนวนมาก... มักจะทำ WAL และ PITR ของตัวเอง บางตัวจัดการบัฟเฟอร์ การล็อค และการจัดการการจำลอง/โหลดของตนเองด้วย อย่างที่คุณพูด มันยากที่จะบอกว่าอินเทอร์เฟซควรอยู่ที่ไหน
เป็นนามธรรม

10 กว่าปีผ่านไป เราเห็นอะไรบ้าง? MySQL มีปัญหาที่น่ารำคาญกับธุรกรรมระหว่างตารางในเอ็นจิ้นการจัดเก็บข้อมูลที่แตกต่างกัน และ MySQL มีปัญหากับการจำลองแบบ ในช่วงสิบปีที่ผ่านมา PostgreSQL ได้เพิ่มประเภทข้อมูลและดัชนีปลั๊กอินและยังมีการจำลองข้อมูล นั่นคือข้อดีของ MySQL ได้รับการปรับระดับ ในขณะที่ปัญหาทางสถาปัตยกรรมของ MySQL ยังคงอยู่และรบกวนชีวิต MySQL 5.7 พยายามแก้ไขปัญหาประสิทธิภาพการจำลองแบบโดยการทำแบบขนาน เนื่องจากโปรเจ็กต์ในที่ทำงานมีความอ่อนไหวต่อประสิทธิภาพการจำลองแบบมากเนื่องจากขนาดของมัน ฉันจึงพยายามทดสอบว่าดีขึ้นหรือไม่ ฉันพบว่าการจำลองแบบขนานใน 5.7 นั้นช้ากว่าการจำลองแบบเธรดเดียวใน 5.5 และในบางกรณีเท่านั้น - ใกล้เคียงกัน หากคุณกำลังใช้ MySQL 5.5 และต้องการอัปเกรดเป็นเวอร์ชันล่าสุด โปรดทราบว่าการโยกย้ายไม่สามารถทำได้สำหรับโปรเจ็กต์ที่มีการโหลดสูง เนื่องจากการจำลองแบบจะตามทันไม่ได้อีกต่อไป

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

ไม่ทราบสาเหตุที่แท้จริงของการถดถอยของประสิทธิภาพนี้ มีข้อสันนิษฐานหลายประการ - ตัวอย่างเช่น Christian Nelsen หนึ่งในนักพัฒนา MariaDB เขียนในบล็อกของเขาว่าอาจมีปัญหากับรูปแบบประสิทธิภาพและการซิงโครไนซ์เธรด ด้วยเหตุนี้ จึงมีการถดถอยถึง 40% ซึ่งมองเห็นได้ในการทดสอบปกติ นักพัฒนาของ Oracle ปฏิเสธสิ่งนี้ และพวกเขายังทำให้ฉันเชื่อว่าไม่มีอยู่จริง เห็นได้ชัดว่าฉันเห็นปัญหาอื่น ๆ (และมีกี่ปัญหา)

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

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

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

ใน PostgreSQL ในแง่นี้ สถาปัตยกรรมมีความรอบคอบและนำไปใช้งานได้ดีขึ้นมาก เพิ่งประกาศฟีเจอร์ที่เรียกว่า Logical Decoding ซึ่งช่วยให้คุณทำสิ่งที่น่าสนใจทุกประเภทซึ่งยากมากที่จะทำภายในขอบเขตของนิตยสารฉบับจริง ใน PostgreSQL นี่เป็นส่วนเสริมที่ด้านบน การถอดรหัสแบบลอจิคัลทำให้คุณสามารถทำงานกับบันทึกทางกายภาพราวกับว่ามันเป็นบันทึกแบบลอจิคัล ฟังก์ชั่นนี้จะลบข้อดีทั้งหมดของการจำลองแบบ MySQL ออกไปในไม่ช้า ยกเว้นขนาดบันทึก - การจำลองแบบ MySQL ตามคำสั่งจะชนะ - แต่การจำลองแบบ MySQL ตามคำสั่งมีปัญหาร้ายแรงอย่างสมบูรณ์ในสถานที่ที่ไม่คาดคิดที่สุด และไม่ควรพิจารณา การตัดสินใจที่ดี(ฉันจะพูดถึงทั้งหมดนี้ในรายงานด้วย)

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

เอกสารประกอบ

ตัวอย่างเช่น บริษัท Percona เริ่มดำเนินการ: พวกเขาดำเนินการ MySQL Performance Blog และในบล็อกนี้มีบทความมากมายที่กล่าวถึงแง่มุมบางประการของการใช้ MySQL สิ่งนี้นำมาซึ่งความนิยมอย่างล้นหลาม นำลูกค้ามาให้คำปรึกษา และช่วยให้เราดึงดูดทรัพยากรเพื่อเปิดตัวการพัฒนา Percona-Server fork ของเราเอง การมีอยู่และความนิยมของ MySQL Performance Blog พิสูจน์ให้เห็นว่าเอกสารอย่างเป็นทางการยังไม่เพียงพอ

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

ตัวอย่างของโปรเจ็กต์ขนาดใหญ่บน PostgreSQL คือ 1C: PostgreSQL มาเป็นตัวเลือกแทน Microsoft SQL และ Microsoft SQL นั้นเป็น DBMS ที่ยอดเยี่ยมอย่างแท้จริง ซึ่งเป็นหนึ่งใน DBMS ที่ทรงพลังที่สุด PostgreSQL สามารถแทนที่ MS SQL ได้ และพยายามแทนที่ด้วย MySQL... เรามาลดม่านแห่งความสงสารกับฉากนี้ลง ดังที่ Mark Twain เขียนไว้

มาตรฐาน

ประสิทธิภาพและความซับซ้อนในการบริหาร

MySQL มีปัญหากับการสืบค้นที่ซับซ้อน ตัวอย่างเช่น MySQL ไม่ทราบวิธีการลดกลุ่มออกเป็นส่วนต่าง ๆ ของสหภาพทั้งหมด ความแตกต่างระหว่างสองแบบสอบถาม ในตัวอย่างของเรา การจัดกลุ่มตามตารางแต่ละตารางและการรวมกลุ่มที่อยู่ด้านบนทั้งหมดจะทำงานได้เร็วกว่าการรวมแบบสอบถามทั้งหมดแล้วจัดกลุ่มถึง 15 เท่า แม้ว่าเครื่องมือเพิ่มประสิทธิภาพจะต้องนำทั้งสองแบบสอบถามมาไว้ในแผนการดำเนินการแบบสอบถามเดียวกันและมีประสิทธิภาพก็ตาม เราจะต้องสร้างคำขอดังกล่าวด้วยตนเอง - นั่นคือทำให้นักพัฒนาเสียเวลากับสิ่งที่ฐานข้อมูลควรทำ

“ความเรียบง่าย” ของผลลัพธ์ MySQL ดังที่เห็นข้างต้น จากความสามารถที่ต่ำมาก MySQL ทำงานได้แย่ลงและต้องใช้เวลาและความพยายามมากขึ้นในระหว่างการพัฒนา ในทางตรงกันข้าม PostrgreSQL มีฮิสโตแกรมและเครื่องมือเพิ่มประสิทธิภาพปกติ และจะดำเนินการค้นหาดังกล่าวได้อย่างมีประสิทธิภาพ แต่หากมีฮิสโตแกรม แสดงว่ามีการตั้งค่า - อย่างน้อยก็ขนาดที่เก็บข้อมูล คุณจำเป็นต้องรู้เกี่ยวกับการตั้งค่าและเปลี่ยนแปลงในบางกรณี ดังนั้น คุณต้องเข้าใจว่าการตั้งค่านี้คืออะไร รับผิดชอบอะไร สามารถรับรู้สถานการณ์ดังกล่าว และดูวิธีเลือกพารามิเตอร์ที่เหมาะสมที่สุด

บางครั้งทักษะของ PostrgreSQL อาจเป็นอุปสรรคมากกว่าจะช่วยได้ 95% ของเวลาทุกอย่างทำงานได้ดี - ดีกว่า MySQL - แต่แบบสอบถามโง่ ๆ หนึ่งคำนั้นช้ากว่ามาก หรือทุกอย่างทำงานได้ดี และทันใดนั้น (จากมุมมองของผู้ใช้) เมื่อโปรเจ็กต์เติบโตขึ้น คิวรีบางรายการก็เริ่มทำงานได้ไม่ดี (มีข้อมูลมากขึ้น เริ่มเลือกแผนดำเนินการคิวรีอื่น) เป็นไปได้มากว่าหากต้องการแก้ไขเพียงเรียกใช้การวิเคราะห์หรือปรับแต่งการตั้งค่าเล็กน้อย แต่คุณจำเป็นต้องรู้ว่าต้องทำอะไรและทำอย่างไร อย่างน้อยที่สุด คุณจะต้องอ่านเอกสาร PostgreSQL ในหัวข้อนี้ แต่ด้วยเหตุผลบางอย่าง พวกเขาจึงไม่ชอบอ่านเอกสาร อาจเป็นเพราะช่วยได้น้อยใน MySQL? -

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

แล้วคุณควรเลือกอะไร?

ก่อนอื่นทีมงานมีประสบการณ์อะไรบ้าง? หากทั้งทีมมีประสบการณ์ 10 ปีในการทำงานกับ MySQL และจำเป็นต้องเริ่มต้นและใช้งานโดยเร็วที่สุด ก็ไม่คุ้มที่จะเปลี่ยนเครื่องมือที่คุ้นเคยเป็นเครื่องมือที่ไม่คุ้นเคย แต่หากกำหนดเวลาไม่สำคัญ PostgreSQL ก็คุ้มค่าที่จะลองใช้

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

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

เป็นการยากที่จะหาองค์กรที่ไม่ใช้ระบบบัญชีจาก 1C - แม้ใน megaholdings ที่มีการใช้งาน SAP หรือ OEBS มาเป็นเวลานาน แต่ก็มักจะใช้ในพื้นที่ใดพื้นที่หนึ่งเสมอ เป็นเรื่องน่ายินดีที่แอพพลิเคชั่นซอฟต์แวร์ของรัสเซียกลายเป็นมาตรฐานโดยพฤตินัยสำหรับ บริษัท ของเรา แต่มีข้อละเอียดอ่อนประการหนึ่ง: มาตรฐานโดยพฤตินัยเดียวกันสำหรับ 1C:Enterprise ได้กลายเป็นมาตรฐานเดียวกัน การใช้งานไมโครซอฟต์ SQL Server เป็น DBMS

ในบรรดาผู้ปฏิบัติงาน 1C ความคิดเห็นที่พบบ่อยที่สุดคือหากไม่มี DBMS เชิงพาณิชย์จากผู้ผลิตในอเมริกาจะไม่มีอะไรดีเกิดขึ้น พวกเขากล่าวว่าผู้ใช้หลายร้อยคนจำเป็นต้องติดตั้งฐานข้อมูลบน MS SQL, Oracle Database หรือ IBM DB2 ในกรณีนี้อย่างหลีกเลี่ยงไม่ได้ ความคิดเห็นของผู้ปฏิบัติงานที่เรารู้จักเกี่ยวกับการทำงานภายใต้เสรีภาพของ PostgreSQL DBMS นั้นแตกต่างกัน แต่ในช่วงตั้งแต่ "ใช้งานไม่ได้เลย" ไปจนถึง "เหมาะสำหรับผู้ใช้หลายสิบคน และไม่มากไปกว่านี้อีกแล้ว"

มีคำอธิบายที่เป็นไปได้หลายประการสำหรับการประมาณค่าเล็กน้อยดังกล่าว: การใช้งานกลไกตารางชั่วคราวอย่างแข็งขันโดยแพลตฟอร์ม 1C (ซึ่งใน Postgres มีการใช้งานแบบ "ตรงไปตรงมา" ด้วย - ด้วย DDL ของธุรกรรม ความสามารถในการกู้คืนทั้งหมด) และลักษณะเฉพาะของการทำงานกับข้อมูลข้อความ (ในขณะที่ข้อความหลายภาษา Vanilla Postgres ค่อนข้างอนุรักษ์นิยมเกินไป ไม่ได้ใช้ไลบรารีระบบที่มีประสิทธิภาพสูงที่สุด) และประเด็นอื่นๆ ที่สำคัญน้อยกว่าอีกหลายประการ

แต่เราแอบเชื่อใน Postgres โดยเฉพาะอย่างยิ่งเมื่อสภาอ้างว่าสามารถแก้ไขปัญหาทั้งหมดที่ผู้คลางแคลงใช้เพื่อพิสูจน์การเลือก DBMS เชิงพาณิชย์ นอกจากนี้ สิ่งสำคัญสำหรับเราคือการได้รับตัวบ่งชี้ปลายทางสำหรับฮาร์ดแวร์และซอฟต์แวร์ที่ซับซ้อน ซึ่งเป็นกลไกฐานข้อมูลสำหรับ DBMS ที่สร้างขึ้นบนพื้นฐานของอุปกรณ์และซอฟต์แวร์ที่ปลอดภัยจากการคว่ำบาตร ซึ่งพัฒนาโดย IBS ร่วมกับ Postgres Professional

ในบรรดาแอปพลิเคชันที่จำลองแบบ แอปพลิเคชันที่ชัดเจนที่สุดสำหรับเครื่องดังกล่าวควรเป็นระบบ 1C และผลลัพธ์ของการวัดประสิทธิภาพได้ย้ายเราจากหมวดหมู่ของ "ผู้เชื่อในความลับ" (และแม้แต่ผู้สงสัย) ไปเป็นหมวดหมู่ "มั่นใจ" อย่างสมบูรณ์: ตอนนี้เราสามารถพูดได้อย่างปลอดภัยแล้วว่า 1C:Enterprise เวอร์ชัน 8.3 บน PostgreSQL EE 1.5 สร้างขึ้นสำหรับ Skala-SR / PostgreSQL ทำงานได้ดีกว่า MS SQL 2012 บนฮาร์ดแวร์เดียวกันพร้อมการปรับแต่งที่เป็นไปได้ทั้งหมด

ดังนั้นรายละเอียดบางส่วนของการทดลอง ในแง่ของการทดสอบประสิทธิภาพ 1C มีทุกอย่างอย่างเป็นระบบและเป็นวิทยาศาสตร์ การกำหนดค่าทั่วไป“การทดสอบโหลดมาตรฐาน” ซึ่งเปิดตัวเกณฑ์มาตรฐาน จะค่อยๆ เพิ่มผู้ใช้ใหม่ในการโหลดจนกว่าแอปพลิเคชันจะตอบสนองเพียงพอสำหรับการทำงานที่สะดวกสบาย (แม่นยำยิ่งขึ้น ผู้ใช้จะถูกเพิ่มจนกว่าคะแนนประสิทธิภาพแอปพลิเคชัน Apdex มาตรฐานจะต่ำกว่าเกณฑ์ 0.85 และจำนวนสูงสุดของผู้ใช้ที่มีประสิทธิภาพดังกล่าวถือเป็นผลลัพธ์การวัดประสิทธิภาพ)

เราใช้เวอร์ชัน 8.3.9.1850 ของ 1C:Enterprise การทดสอบโหลดมาตรฐานในเวอร์ชัน 2.0.17.36 ในขั้นต้นมีการตัดสินใจว่าจะไม่ให้ส่วนลดใด ๆ แก่ Postgres: เราทำการเพิ่มประสิทธิภาพสูงสุดบน MS SQL บนโหนดจากคอมเพล็กซ์ Skala-SR / PostgreSQL (เราติดตั้ง Windows บนโลหะเปลือยกำหนดค่าตามหลักการทั้งหมดเพื่อความรวดเร็วที่เรา สร้าง ramdisk สำหรับตารางชั่วคราว) จากนั้นเราจะส่งคืนโหนดเดียวกันไปยัง Scala-SR complex ติดตั้ง Linux และ Postgres Pro EE และบนมันเพียงอย่างเดียว (โดยไม่มีชิปคลัสเตอร์ในคอมเพล็กซ์) เราจะทำการทดสอบเดียวกัน

การทดสอบที่หนึ่ง: เราเริ่มต้นด้วยเวิร์กสเตชัน 100 เครื่อง ปริมาณงานคือ 50/50 - ครึ่งหนึ่งสร้างเอกสาร ครึ่งหนึ่งสร้างรายงาน ทดสอบที่สอง: เริ่มต้นด้วย 400 โหลด 70/30 MS SQL “สิ้นสุด” ในการทดสอบครั้งแรกกับผู้ใช้ 360 ราย ครั้งที่สองกับผู้ใช้ 540 ราย และขีดจำกัดในการรันทั้งสองรันทำงานกับ I/O ภายในเครื่อง แม้ว่าที่จริงแล้วโปรเซสเซอร์จะโหลดโดยเฉลี่ยเพียง 30% เท่านั้น PostgreSQL เข้าถึงงานได้ถึง 440 งานในการทดสอบครั้งแรก และสูงถึง 660 งานในการทดสอบครั้งที่สอง และทุกอย่างบนเซิร์ฟเวอร์ฐานข้อมูลก็ตกอยู่ที่โปรเซสเซอร์ ซึ่งโหลดมากกว่า 90% สำหรับ "ผู้ใช้สูงสุด"

สำหรับ 1C ซึ่งจำนวนผู้ใช้พร้อมกันเป็นปัจจัยจำกัดปัญหามากที่สุด นี่เป็นผลลัพธ์ที่น่าทึ่ง และที่สำคัญที่สุดคือบ่งชี้ว่าระบบแอปพลิเคชันรัสเซียที่สำคัญที่สุดเหล่านี้ไม่เพียงสามารถทำงานได้หากไม่มี DBMS เชิงพาณิชย์ของตะวันตก แต่ยังทำงานได้ดีกว่ามากอีกด้วย .

ซีรี่ส์เนื้อหา:

1. ประวัติความเป็นมาของการพัฒนา MySQL และ PostgreSQL

ประวัติความเป็นมาของ MySQL เริ่มต้นในปี 1979 โดยมีบริษัทเล็กๆ แห่งหนึ่งที่นำโดย Monty Widenius ในปี 1996 การเปิดตัวครั้งแรกของ 3.11 สำหรับ Solaris พร้อมใบอนุญาตสาธารณะปรากฏขึ้น จากนั้น MySQL ก็ถูกย้ายไปยังที่อื่น ระบบปฏิบัติการมีใบอนุญาตการค้าพิเศษปรากฏขึ้น ในปี 2000 หลังจากเพิ่มอินเทอร์เฟซที่คล้ายกับ Berkeley DB ฐานข้อมูลก็กลายเป็นธุรกรรม มีการเพิ่มการจำลองแบบในเวลาเดียวกัน ในปี 2544 เวอร์ชัน 4.0 ได้เพิ่มกลไก InnoDB ให้กับ MyISAM ที่มีอยู่ ส่งผลให้มีแคชและประสิทธิภาพเพิ่มขึ้น ในปี พ.ศ. 2547 เวอร์ชัน 4.1 ได้รับการเผยแพร่ ซึ่งแนะนำแบบสอบถามย่อย การทำดัชนีบางส่วนสำหรับ MyISAM และ Unicode ในเวอร์ชัน 5.0 ในปี 2548 กระบวนการจัดเก็บ เคอร์เซอร์ ทริกเกอร์ และมุมมองปรากฏขึ้น MySQL กำลังพัฒนาเทรนด์เชิงพาณิชย์: ในปี 2009 MySQL กลายเป็นเครื่องหมายการค้าของ Oracle

ประวัติความเป็นมาของ Postgres เริ่มต้นในปี 1977 ด้วยฐานข้อมูล Ingress

ในปี 1986 มีการเปลี่ยนชื่อเป็น PostgreSQL ที่ University of Berkeley, California

ในปี 1995 Postgres ได้กลายเป็นฐานข้อมูลแบบเปิด psql แบบโต้ตอบปรากฏขึ้น

ในปี 1996 Postgres95 ได้เปลี่ยนชื่อเป็น PostgreSQL เวอร์ชัน 6.0

Postgres มีนักพัฒนาหลายร้อยรายทั่วโลก

2. สถาปัตยกรรมของ MySQL และ PostgreSQL

PostgreSQL– เซิร์ฟเวอร์ฐานข้อมูลแบบครบวงจรพร้อมเอ็นจิ้นเดียว – เอ็นจิ้นการจัดเก็บข้อมูล Postgres ใช้โมเดลไคลเอ็นต์-เซิร์ฟเวอร์

สำหรับลูกค้าแต่ละราย กระบวนการใหม่(ไม่ใช่กระแส!) เพื่อทำงานกับกระบวนการไคลเอนต์ดังกล่าว เซิร์ฟเวอร์ใช้เซมาฟอร์

คำขอของลูกค้าต้องผ่านขั้นตอนต่อไปนี้

1. เชื่อมต่อ.
2. การแยกวิเคราะห์: มีการตรวจสอบความถูกต้องของคำขอและสร้างแผนผังแบบสอบถาม parser ขึ้นอยู่กับยูทิลิตี้ Unix พื้นฐาน yacc และ lex
3. เขียนใหม่: มีการใช้แผนผังแบบสอบถามและมีการตรวจสอบกฎที่อยู่ในนั้นซึ่งอยู่ในไดเร็กทอรีระบบ แต่ละครั้งที่แบบสอบถามของผู้ใช้ถูกเขียนใหม่ลงในแบบสอบถามที่เข้าถึงตารางฐานข้อมูล
4. เครื่องมือเพิ่มประสิทธิภาพ: สำหรับแต่ละคำขอ จะมีการสร้างแผนแบบสอบถามซึ่งจะถูกส่งต่อไปยังผู้ดำเนินการ จุดประสงค์ของแผนคือทุกคนจะผ่านมันไปได้ ตัวเลือกที่เป็นไปได้รับผลลัพธ์ (ไม่ว่าจะใช้ดัชนี การรวม ฯลฯ) และเลือกตัวเลือกที่เร็วที่สุด
5. การดำเนินการสืบค้น: ตัวดำเนินการจะวนซ้ำไปตามแผนผังและรับผลลัพธ์ โดยใช้การเรียงลำดับ การรวม ฯลฯ และส่งคืนแถว Postgres เป็นฐานข้อมูลเชิงวัตถุสัมพันธ์ แต่ละตารางในนั้นแสดงถึงคลาส และการสืบทอดจะถูกนำไปใช้ระหว่างตาราง ใช้มาตรฐาน SQL92 และ SQL99

โมเดลธุรกรรมถูกสร้างขึ้นบนพื้นฐานของสิ่งที่เรียกว่าการควบคุมพร้อมกันหลายเวอร์ชัน (MVCC) ซึ่งให้ ประสิทธิภาพสูงสุด- ความสมบูรณ์ของการอ้างอิงนั้นมั่นใจได้ด้วยการมีอยู่ของคีย์หลักและรอง

MySQLมีสองชั้น - เลเยอร์ sql ภายนอกและชุดเอ็นจิ้นภายในซึ่งเอ็นจิ้น InnoDb ถูกใช้บ่อยที่สุดเนื่องจากรองรับ ACID อย่างเต็มที่ที่สุด

ใช้มาตรฐาน SQL92

จากมุมมองแบบโมดูลาร์ โค้ด MySQL สามารถแบ่งออกเป็นโมดูลต่อไปนี้

1. การเริ่มต้นเซิร์ฟเวอร์
2. ผู้จัดการการเชื่อมต่อ
3. ผู้จัดการสตรีม
4. ตัวจัดการคำสั่ง
5. การรับรองความถูกต้อง
6. พาร์เซอร์
7. เครื่องมือเพิ่มประสิทธิภาพ
8. ผู้จัดการโต๊ะ
9. เครื่องยนต์ (MyISAM, InnoDB, หน่วยความจำ, Berkeley DB)
10. การบันทึก
11. การจำลองแบบ
12. API เครือข่าย
13. เคอร์เนล API

ลำดับการทำงานของโมดูลมีดังนี้: ขั้นแรกให้โหลดโมดูลแรกซึ่งจะอ่านตัวเลือกต่างๆ บรรทัดคำสั่ง, กำหนดค่าไฟล์, จัดสรรหน่วยความจำ, เริ่มต้นโครงสร้างส่วนกลาง, โหลดตารางระบบ และถ่ายโอนการควบคุมไปยังตัวจัดการการเชื่อมต่อ

เมื่อไคลเอนต์เชื่อมต่อกับฐานข้อมูล การควบคุมจะถูกถ่ายโอนไปยังตัวจัดการเธรด ซึ่งสร้างเธรด (ไม่ใช่กระบวนการ!) สำหรับไคลเอนต์ และตรวจสอบการรับรองความถูกต้อง

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

รหัสที่สำคัญที่สุดอยู่ในไฟล์ sql/mysqld.cc ประกอบด้วยฟังก์ชันพื้นฐานที่ไม่มีการเปลี่ยนแปลงตั้งแต่เวอร์ชัน 3.22: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_options() handle_connections_sockets() create_new_thread () handle_one_connection () check_connection () acl_check_host () // sql/sql_acl.cc create_random_string () // sql/password.cc check_user () // sql/sql_parse.cc mysql_parse () // sql/sql_parse.cc จัดส่ง_command () Query_cache ::store_query() // sql/sql_cache.cc เข้าร่วม::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mysql_check_table() // sql/sql_table.cc

ส่วนหัว sql/sql_class.h กำหนดคลาสพื้นฐาน: Query_arena, Statement, Security_context, คลาส Open_tables_state, THD อ็อบเจ็กต์ของคลาส THD เป็นตัวอธิบายเธรดและเป็นอาร์กิวเมนต์ของฟังก์ชันจำนวนมาก

3. การเปรียบเทียบ MySQL และ PostgreSQL: ความเหมือนและความแตกต่าง

มาตรฐานกรด

มาตรฐาน ACID อิงจากความเป็นอะตอมมิก ความสมบูรณ์ การแยกตัว และความน่าเชื่อถือ โมเดลนี้ใช้เพื่อรับประกันความสมบูรณ์ของข้อมูล สิ่งนี้ถูกนำไปใช้บนพื้นฐานของการทำธุรกรรม PostgreSQL เป็นไปตามมาตรฐาน ACID โดยสมบูรณ์ สำหรับ การสนับสนุนอย่างเต็มที่ ACID ใน MySQL ในการกำหนดค่าคุณต้องตั้งค่า default-storage-engine=innodb

ผลงาน

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

• ดัชนีบางส่วน
• การบีบอัดข้อมูล
• การจัดสรรหน่วยความจำ
• ปรับปรุงแคช

MySQL รองรับดัชนีบางส่วนใน InnoDB หากคุณใช้เอ็นจิ้น MySQL ISAM มันจะเร็วขึ้นสำหรับการสืบค้นแบบแบน ในขณะที่ไม่มีการบล็อกการแทรก ไม่รองรับธุรกรรม คีย์ต่างประเทศ

การบีบอัด

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

การบีบอัด MySQL สำหรับเอ็นจิ้นที่แตกต่างกันได้รับการสนับสนุนบางส่วน บางส่วนไม่รองรับ และขึ้นอยู่กับเวอร์ชันเฉพาะของเอ็นจิ้นเฉพาะ

ในแง่ของประสิทธิภาพของโปรเซสเซอร์หลายตัว PostgreSQL มีข้อได้เปรียบเหนือ MySQL แม้แต่นักพัฒนา MySQL เองก็ยอมรับว่าเอ็นจิ้นของพวกเขาไม่ค่อยดีนักในเรื่องนี้

ประเภทข้อมูล

MySQL: ใช้ประเภท TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB เพื่อจัดเก็บข้อมูลไบนารีซึ่งมีขนาดต่างกัน (สูงสุด 4 GB)

ตัวอักษร: สี่ประเภท - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT

PostgreSQL: รองรับกลไกข้อมูลผู้ใช้ด้วยคำสั่ง CREATE TYPE, ประเภท BOOLEAN, ประเภทเรขาคณิต

อักขระ: TEXT (ข้อจำกัด – ขนาดแถวสูงสุด)

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

ขั้นตอนการจัดเก็บ

ทั้ง PostgreSQL และ MySQL รองรับขั้นตอนการจัดเก็บ PostgreSQL เป็นไปตามมาตรฐาน Oracle PL/SQL ส่วน MySQL เป็นไปตามมาตรฐาน IBM DB2 MySQL รองรับการขยาย SQL สำหรับการเขียนฟังก์ชันใน C/C++ ตั้งแต่เวอร์ชัน 5.1 PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C สำหรับการเขียนขั้นตอนการจัดเก็บ

กุญแจ

ทั้ง PostgreSQL และ MySQL รองรับคีย์หลักและคีย์ต่างประเทศที่ไม่ซ้ำกัน MySQL ไม่รองรับข้อจำกัดในการตรวจสอบ รวมถึงมีการใช้คีย์รองบางส่วน PostgreSQL: การใช้งานเต็มรูปแบบพร้อมการสนับสนุน ON DELETE CASCADE และ ON UPDATE CASCADE

ทริกเกอร์

MySQL: การสนับสนุนขั้นพื้นฐาน PostgreSQL: ทริกเกอร์ที่ประกาศ: SELECT, INSERT, DELETE, UPDATE, แทน; ทริกเกอร์ขั้นตอน: CONSTRAINT TRIGGER เหตุการณ์: ก่อนหรือหลังเมื่อ INSERT, DELETE, UPDATE

เพิ่มอัตโนมัติ

MySQL: ในตารางจะมีคอลัมน์ดังกล่าวได้เพียงคอลัมน์เดียวเท่านั้น ซึ่งจะต้องจัดทำดัชนี PostgreSQL: ชนิดข้อมูลแบบอนุกรม

การจำลองแบบ

รองรับทั้ง MySQL และ PostgreSQL PostgreSQL มีสถาปัตยกรรมแบบโมดูลาร์ และการจำลองแบบจะรวมอยู่ในโมดูลแยกกัน:

• Slony-I เป็นกลไกการจำลองหลักใน Postgres ประสิทธิภาพลดลงเมื่อฟังก์ชันกำลังสองของจำนวนเซิร์ฟเวอร์

การจำลองแบบใน PostgreSQL เป็นแบบทริกเกอร์และช้ากว่าใน MySQL มีการวางแผนที่จะเพิ่มการจำลองแบบให้กับเคอร์เนลโดยเริ่มจากเวอร์ชัน 8.4

ใน MySQL การจำลองแบบจะรวมอยู่ในคอร์และมีสองรสชาติ โดยเริ่มจากเวอร์ชัน 5.1:

• SBR – การจำลองแบบตามคำสั่ง
• RBR – การจำลองแบบตามแถว

ประเภทแรกขึ้นอยู่กับบันทึกการบันทึกในบันทึกไบนารี ประเภทที่สองขึ้นอยู่กับการเปลี่ยนแปลงการบันทึก ตั้งแต่เวอร์ชัน 5.5 เป็นต้นไป MySQL รองรับสิ่งที่เรียกว่าการจำลองแบบกึ่งซิงโครนัส ซึ่งเซิร์ฟเวอร์หลัก (ต้นแบบ) จะรีเซ็ตข้อมูลไปยังเซิร์ฟเวอร์อื่น (สเลฟ) ในแต่ละคอมมิต กลไก NDB ทำการจำลองแบบสองเฟสแบบซิงโครนัสเต็มรูปแบบ

การทำธุรกรรม

MySQL: InnoDB เท่านั้น สนับสนุน SAVEPOINT ย้อนกลับไปยัง SAVEPOINT ระดับการล็อค: ระดับตาราง (MyISAM) PostgreSQL: รองรับ รวมถึงระดับการอ่านและการแยกส่วน สนับสนุนการย้อนกลับ การย้อนกลับไปยัง SAVEPOINT ระดับการล็อค: ระดับแถว, ระดับตาราง

ระดับสิทธิพิเศษ

PostgreSQL: สามารถกำหนดสิทธิ์ให้กับผู้ใช้หรือกลุ่มผู้ใช้ได้

ข้อมูลการส่งออก-นำเข้า

MySQL: ชุดยูทิลิตี้การส่งออก: mysqldump, mysqlhotcopy, mysqlsnapshot นำเข้าจาก ไฟล์ข้อความ, html, dbf. PostgreSQL: ส่งออก - ยูทิลิตี้ pg_dump นำเข้าระหว่างฐานข้อมูลและระบบไฟล์

แบบสอบถามที่ซ้อนกัน

ใช้งานได้ทั้ง MySQL และ PostgreSQL แต่อาจทำงานได้ไม่มีประสิทธิภาพใน MySQL

การจัดทำดัชนี

การแฮชดัชนี: บางส่วนใน MySQL, เต็มรูปแบบใน PostgreSQL การค้นหาข้อความแบบเต็ม: บางส่วนใน MySQL, เต็มรูปแบบใน PostgreSQL ดัชนีบางส่วน: ไม่รองรับใน MySQL, รองรับใน PostgreSQL ดัชนีหลายคอลัมน์: ใน MySQL ขีดจำกัดคือ 16 คอลัมน์ ใน PostgreSQL – 32 ดัชนีนิพจน์: ใน MySQL – การจำลอง ใน PostgreSQL – เต็ม ดัชนีการสร้างแบบไม่บล็อก: ใน MySQL - บางส่วน, ใน PostgreSQL - เต็ม

การแบ่งพาร์ติชัน

MySQL รองรับการแบ่งพาร์ติชันแนวนอน: ช่วง, รายการ, แฮช, คีย์, การแบ่งพาร์ติชันแบบคอมโพสิต PostgreSQL รองรับ RANGE และ LIST การแบ่งพาร์ติชันตารางและดัชนีโดยอัตโนมัติ

การกู้คืนอัตโนมัติจากความล้มเหลว

MySQL: บางส่วนสำหรับ InnoDB - คุณต้องทำการสำรองข้อมูลด้วยตนเอง PostgreSQL: เขียนการบันทึกล่วงหน้า (WAL)

เครื่องมือจัดเก็บข้อมูล

PostgreSQL รองรับกลไกเดียว – Postgres Storage System มีหลายอย่างใน MySQL 5.1:

• MyISAM – ใช้เพื่อจัดเก็บตารางระบบ
• InnoDB – การปฏิบัติตามข้อกำหนด ACID สูงสุด จัดเก็บข้อมูลด้วยคีย์หลัก การแทรกแคช รองรับการบีบอัดที่เริ่มต้นจากเวอร์ชัน 5.1 – ดูแอตทริบิวต์ ROW_FORMAT=COMPRESSED
• NDB Cluster – เอ็นจิ้นที่เน้นหน่วยความจำ สถาปัตยกรรมคลัสเตอร์โดยใช้การจำลองแบบซิงโครนัส
• ARCHIVE – รองรับการบีบอัด ไม่ใช้ดัชนี
• และยัง: ผสาน, หน่วยความจำ (HEAP), CSV

InnoDB ได้รับการพัฒนาโดย InnoBase ซึ่งเป็นบริษัทในเครือของ Oracle ในเวอร์ชัน 6 ควรมีสองเอ็นจิ้นปรากฏขึ้น - มาเรียและฟอลคอน Falcon เป็นเครื่องมือที่อิงตามธุรกรรม ACID

การออกใบอนุญาต

PostgreSQL: โอเพ่นซอร์ส BSD (Berkeley Software Distribution) MySQL: GPL (Gnu General Public License) หรือเชิงพาณิชย์ MySQL เป็นผลิตภัณฑ์โอเพ่นซอร์ส Postgres เป็นโครงการโอเพ่นซอร์ส

บทสรุป

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

เราจะหารือเกี่ยวกับปัญหาการกำหนดค่าสำหรับ MySQL และ PostgreSQL

แหล่งข้อมูลสำหรับการดาวน์โหลด

static.content.url=http://www.site/developerworks/js/artrating/

โซน=โอเพ่นซอร์ส, Linux

ArticleID=779830

ArticleTitle=MySQL & PostgreSQL: ตอนที่ 1 การวิเคราะห์เชิงเปรียบเทียบ

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

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

ฐานข้อมูลได้รับการออกแบบสำหรับการจัดเก็บข้อมูลที่มีโครงสร้างและ เข้าถึงได้อย่างรวดเร็วไปยังข้อมูลต่างๆ แต่ละฐานข้อมูล นอกเหนือจากตัวข้อมูลเองแล้ว จะต้องมีรูปแบบการดำเนินงานเฉพาะตามการประมวลผลข้อมูลที่จะดำเนินการ ในการจัดการฐานข้อมูล มีการใช้ DBMS หรือระบบการจัดการฐานข้อมูล โปรแกรมดังกล่าว ได้แก่ MySQL และ Postgresql

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

ประวัติโดยย่อ

MySQL

การพัฒนา MySQL เริ่มขึ้นในยุค 90 การเปิดตัวฐานข้อมูลภายในครั้งแรกเกิดขึ้นในปี 1995 ในช่วงเวลานี้ หลายบริษัทกำลังพัฒนาโครงการนี้ การพัฒนาเริ่มต้นโดยบริษัท MySQL AB ของสวีเดน ซึ่ง Sun Microsystems เข้าซื้อกิจการ ซึ่งกลายเป็นทรัพย์สินของ Oracle บน ในขณะนี้ตั้งแต่ปี 2010 Oracle ได้พัฒนาสิ่งนี้

PostgreSQL

การพัฒนา Postrgresql เริ่มต้นในปี 1986 ที่มหาวิทยาลัยแคลิฟอร์เนีย เบิร์กลีย์ การพัฒนาใช้เวลาเกือบแปดปี จากนั้นโครงการก็แบ่งออกเป็นสองส่วน: ฐานข้อมูล IIlustra เชิงพาณิชย์และโครงการ Postrgesql ที่ไม่เสียค่าใช้จ่ายใด ๆ ซึ่งพัฒนาโดยผู้ที่ชื่นชอบ

การจัดเก็บข้อมูล

MySQL

MySQL เป็นฐานข้อมูลเชิงสัมพันธ์ เอ็นจิ้นต่าง ๆ ใช้เพื่อจัดเก็บข้อมูลในตาราง แต่การทำงานกับเอ็นจิ้นนั้นถูกซ่อนอยู่ในระบบเอง กลไกจัดการไม่ส่งผลต่อไวยากรณ์ของคำขอและการดำเนินการ เอ็นจิ้นหลักที่รองรับ ได้แก่ MyISAM, InnoDB, MEMORY, Berkeley DB พวกเขาแตกต่างกันในลักษณะการเขียนข้อมูลลงดิสก์ตลอดจนวิธีการอ่านข้อมูล

PostgreSQL

Postgresql เป็นฐานข้อมูลเชิงวัตถุที่ทำงานบนเอ็นจิ้นเดียวเท่านั้น - เอ็นจิ้นการจัดเก็บข้อมูล ตารางทั้งหมดจะแสดงเป็นออบเจ็กต์ สามารถสืบทอดได้ และการดำเนินการทั้งหมดกับตารางจะดำเนินการโดยใช้ฟังก์ชันเชิงวัตถุประสงค์ เช่นเดียวกับใน MySQL ข้อมูลทั้งหมดจะถูกเก็บไว้ในดิสก์ในไฟล์ที่จัดเรียงเป็นพิเศษ แต่โครงสร้างของไฟล์เหล่านี้และบันทึกในไฟล์นั้นแตกต่างกันมาก

มาตรฐาน SQL

ไม่ว่าระบบการจัดการฐานข้อมูลที่ใช้จะเป็นอย่างไรก็ตาม SQL เป็นภาษาคิวรีมาตรฐาน และได้รับการสนับสนุนจากโซลูชันทั้งหมด แม้แต่ MySQL หรือ Postgresql มาตรฐาน SQL ได้รับการพัฒนาในปี 1986 และในระหว่างนี้มีหลายเวอร์ชันที่เผยแพร่แล้ว

MySQL

MySQL ไม่รองรับคุณสมบัติใหม่ทั้งหมดของมาตรฐาน SQL นักพัฒนาเลือกเส้นทางการพัฒนานี้เพื่อให้ MySQL ใช้งานง่าย บริษัทพยายามที่จะบรรลุมาตรฐาน แต่ไม่ได้สูญเสียความเรียบง่าย หากคุณสมบัติบางอย่างสามารถปรับปรุงการใช้งานได้ นักพัฒนาก็สามารถนำไปใช้เป็นส่วนขยายของตนเองได้โดยไม่ต้องใส่ใจกับมาตรฐาน

PostgreSQL

Postgresql เป็นโครงการโอเพ่นซอร์สซึ่งพัฒนาโดยทีมงานผู้กระตือรือร้นและนักพัฒนาพยายามปฏิบัติตามมาตรฐาน SQL ให้มากที่สุดและใช้มาตรฐานล่าสุดทั้งหมด แต่ทั้งหมดนี้มาพร้อมกับความเรียบง่าย Postgresql มีความซับซ้อนมากและด้วยเหตุนี้จึงไม่ได้รับความนิยมเท่ากับ MySQL

ความสามารถในการประมวลผล

ความแตกต่างอื่น ๆ ระหว่าง postgresql และ mysql เกิดจากย่อหน้าก่อนหน้า: ความสามารถในการประมวลผลข้อมูลและข้อจำกัด โดยปกติแล้ว การปฏิบัติตามมาตรฐานใหม่จะนำมาซึ่งความสามารถใหม่ๆ

MySQL

เมื่อดำเนินการตามคำขอ MySQL จะโหลดการตอบสนองของเซิร์ฟเวอร์ทั้งหมดลงในหน่วยความจำของไคลเอ็นต์ สำหรับข้อมูลจำนวนมาก สิ่งนี้อาจไม่สะดวกนัก โดยพื้นฐานแล้ว Postgresql นั้นเหนือกว่า Mysql ในแง่ของฟังก์ชั่น เราจะดูว่าอันไหนต่อไป

PostgreSQL

Postgresql รองรับการใช้เคอร์เซอร์เพื่อนำทางผ่านข้อมูลที่ได้รับ คุณได้รับเพียงตัวชี้เท่านั้น การตอบสนองทั้งหมดจะถูกเก็บไว้ในหน่วยความจำของเซิร์ฟเวอร์ฐานข้อมูล ตัวชี้นี้สามารถบันทึกระหว่างเซสชันได้ รองรับการสร้างดัชนีสำหรับคอลัมน์ตารางหลายคอลัมน์พร้อมกัน นอกจากนี้ดัชนียังสามารถ ประเภทต่างๆนอกเหนือจากแฮชและ b-tree แล้ว GiST และ SP-GiST ยังใช้งานได้สำหรับการทำงานกับเมือง, GIN สำหรับการค้นหาข้อความ, BRIN และ Bloom

รองรับ PostgreSQL การแสดงออกปกติในแบบสอบถาม แบบสอบถามแบบเรียกซ้ำ และการสืบทอดตาราง แต่มีข้อจำกัดหลายประการ เช่น คุณสามารถเพิ่มได้เฉพาะช่องใหม่ที่ท้ายตารางเท่านั้น

ผลงาน

ฐานข้อมูลจะต้องได้รับการปรับให้เหมาะสมกับสภาพแวดล้อมที่คุณจะทำงาน ในอดีต MySQL มุ่งเน้นไปที่ประสิทธิภาพสูงสุด และ Postgresql ได้รับการพัฒนาเป็นฐานข้อมูลที่มีการตั้งค่าจำนวนมากและสอดคล้องกับมาตรฐานให้มากที่สุด แต่เมื่อเวลาผ่านไป Postgresql ได้รับการปรับปรุงและเพิ่มประสิทธิภาพมากมาย

MySQL

ในกรณีส่วนใหญ่ ตาราง InnoDB ใช้เพื่อจัดระเบียบงานกับฐานข้อมูลใน MySQL ตารางนี้เป็น B-tree พร้อมดัชนี ดัชนีช่วยให้คุณสามารถดึงข้อมูลจากดิสก์ได้อย่างรวดเร็วและต้องการการดำเนินการกับดิสก์น้อยลง แต่การสแกนต้นไม้จำเป็นต้องค้นหาดัชนีสองตัว ซึ่งถือว่าช้าอยู่แล้ว ทั้งหมดนี้หมายความว่า MySQL จะเร็วกว่า Postgresql เมื่อใช้คีย์หลักเท่านั้น

PostgreSQL

ข้อมูลส่วนหัวทั้งหมดของตาราง Postgresql อยู่ใน RAM คุณไม่สามารถสร้างตารางที่มีหน่วยความจำไม่เพียงพอ รายการในตารางจะถูกจัดเรียงตามดัชนี ดังนั้นคุณจึงสามารถดึงข้อมูลได้อย่างรวดเร็ว เพื่อความสะดวกยิ่งขึ้น คุณสามารถใช้ดัชนีหลายรายการในตารางเดียวได้

โดยทั่วไปแล้ว PostgreSQL จะเร็วกว่า ยกเว้นการใช้คีย์หลัก มาดูการทดสอบบางส่วนที่มีการดำเนินการที่แตกต่างกัน:

ประเภทข้อมูล

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

MySQL

MySQL รองรับประเภทข้อมูลต่อไปนี้:

• เล็กๆ น้อยๆ: จำนวนเต็มน้อยมาก;
• สมอลลินต์:ทั้งหมดขนาดเล็ก;
• ปานกลาง:ขนาดกลางทั้งหมด
• อินท์:ทั้งหมดเป็นขนาดปกติ
• ใหญ่:ใหญ่ทั้งหมด;
• ลอย:เลขทศนิยมความเที่ยงตรงเดียวที่เซ็นชื่อ
• สองเท่า ความแม่นยำสองเท่า จริง:ลงนามหมายเลขจุดลอยตัวที่มีความแม่นยำสองเท่า
• ทศนิยม, ตัวเลข:เลขทศนิยมที่ลงนาม
• วันที่:วันที่;
  วันที่และเวลา:การรวมวันที่และเวลา
• ประทับเวลา:ประทับเวลา;
• เวลา:เวลา;
  ปี:ปีในรูปแบบ ปปป หรือ ปปปป
• ถ่าน: สตริงขนาดคงที่ บุด้านขวาโดยเว้นวรรคให้มีความยาวสูงสุด
• วาร์ชาร์:สตริงความยาวแปรผัน
• TINYBLOB, TINYTEXT:ข้อมูลไบนารีหรือข้อความที่มีความยาวสูงสุด 255 อักขระ
• หยดข้อความ: ข้อมูลไบนารีหรือข้อความที่มีความยาวสูงสุด 65535 อักขระ
• ปานกลางBLOB, ข้อความกลาง:ข้อความหรือข้อมูลไบนารี
• ลองบล็อบ, ข้อความยาว:ข้อความหรือข้อมูลไบนารีมีความยาวสูงสุด 4294967295 อักขระ
• อีนัม:การแจงนับ;
• ชุด:ฝูงชน

PostgreSQL

ประเภทฟิลด์ที่รองรับใน Postgresql ค่อนข้างแตกต่างกัน แต่อนุญาตให้คุณบันทึกข้อมูลเดียวกันทุกประการ:

• ความคิดใหญ่:จำนวนเต็ม 8 ไบต์ที่เซ็นชื่อ
• เรื่องใหญ่: จำนวนเต็ม 8 ไบต์ที่เพิ่มขึ้นอัตโนมัติ
• นิดหน่อย:สตริงไบนารี่ที่มีความยาวคงที่
• แตกต่างกันเล็กน้อย:สตริงไบนารี่ที่มีความยาวผันแปรได้
• บูลีน:ธง;
• กล่อง:สี่เหลี่ยมผืนผ้าบนเครื่องบิน
• ไบต์: ข้อมูลไบนารี;
• ตัวละครที่แตกต่างกัน:สตริงอักขระที่มีความยาวคงที่
• อักขระ:
• ไซเดอร์:ที่อยู่เครือข่าย IPv4 หรือ IPv6;
• วงกลม:วงกลมบนเครื่องบิน
• วันที่: วันที่ตามปฏิทิน;
• ความแม่นยำสองเท่า:จำนวนจุดลอยตัวที่มีความแม่นยำสองเท่า
• ไอเน็ต:ที่อยู่อินเทอร์เน็ต IPv4 หรือ IPv6;
• จำนวนเต็ม: ลงนามจำนวนเต็ม 4 ไบต์;
• ช่วงเวลา:ช่วงเวลา;
• เส้น:เส้นตรงอันไม่มีที่สิ้นสุดบนเครื่องบิน
• คำสั่ง:ส่วนบนเครื่องบิน
• มาคาดเดอร์:ที่อยู่ MAC;
• เงิน:มูลค่าเงิน
• เส้นทาง:เส้นทางเรขาคณิตบนเครื่องบิน
• จุด:จุดเรขาคณิตบนเครื่องบิน
• รูปหลายเหลี่ยม:รูปหลายเหลี่ยมบนเครื่องบิน
• จริง:หมายเลขจุดลอยตัวที่มีความแม่นยำเดี่ยว
• ขนาดเล็ก:จำนวนเต็มสองไบต์
• อนุกรม:จำนวนเต็มสี่บิตเพิ่มขึ้นโดยอัตโนมัติ
• ข้อความ:สตริงอักขระที่มีความยาวผันแปรได้
• เวลา:เวลาของวัน;
• ประทับเวลา:วันที่และเวลา
• แบบสอบถาม: ข้อความค้นหา;
• เวกเตอร์:เอกสารค้นหาข้อความ
• อุ๊ย: ตัวระบุที่ไม่ซ้ำ;
• xml:ข้อมูล XML

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

การพัฒนา

ทั้งสองโครงการเป็นโอเพ่นซอร์ส แต่ได้รับการพัฒนาแตกต่างกัน ไม่ใช่ทุกคนที่ชอบการพัฒนา MySQL และนี่คือจุดที่การเปรียบเทียบระหว่าง mysql และ postgresql ให้ความแตกต่างมากมาย

MySQL

ฐานข้อมูล MySQL กำลังได้รับการพัฒนาโดย Oracle และมีข่าวลือว่าบริษัทตั้งใจที่จะชะลอการพัฒนาเครื่องยนต์ มีการสร้างทางแยกจำนวนมากของโครงการ รวมถึงทางแยกของ MariaDB จากผู้พัฒนา MySQL ดั้งเดิม แต่การพัฒนายังคงช้า

PostgreSQL

ตามที่กล่าวไว้ในตอนต้นของบทความ การพัฒนาเริ่มต้นที่ University of Berkeley จากนั้นเธอก็ย้ายไปอยู่บริษัทการค้า ขณะนี้โปรแกรมนี้กำลังได้รับการพัฒนาโดยกลุ่มโปรแกรมเมอร์อิสระและคณะกรรมการของบริษัทหลายแห่ง เวอร์ชันใหม่เปิดตัวค่อนข้างกระตือรือร้นและได้รับฟีเจอร์ใหม่ ๆ มากขึ้นเรื่อย ๆ

ข้อสรุป

ในบทความนี้ เราเปรียบเทียบ mysql และ postgresql ดูความแตกต่างหลักระหว่างระบบการจัดการฐานข้อมูลทั้งสอง และพยายามทำความเข้าใจว่า postgresql หรือ mysql ไหนดีกว่ากัน โดยทั่วไปแล้ว Postgresql เป็นความสามารถที่ดีที่สุด แต่มีความซับซ้อนและไม่สามารถใช้งานได้ทุกที่ MySQL นั้นง่ายกว่า แต่ไม่รองรับคุณสมบัติที่น่าสนใจบางอย่าง คุณจะเลือกฐานข้อมูลใดสำหรับโครงการของคุณ ทำไมต้องเธอ? เขียนในความคิดเห็น!

หากต้องการสรุปวิดีโอที่อธิบายความสามารถและแนวโน้มของ Postgresql: