Technology

SQLite vs MySQL vs PostgreSQL เลือก RDMS ตัวไหนมาลง Project หน้าดี

By Arnon Puitrakul - 18 สิงหาคม 2021 - 1 min read min(s)

SQLite vs MySQL vs PostgreSQL เลือก RDMS ตัวไหนมาลง Project หน้าดี

ช่วงนี้กำลังทำงานแล้วต้องขึ้นระบบใหม่พอดี แล้วต้องใช้ Database เมื่อก่อนก็ไม่ได้คิดอะไรเท่าไหร่ เพราะระบบไม่ได้ใหญ่มากกด MySQL ไปก็จบ งานส่วนใหญ่เราทำได้หมด การทำ Execute Plan Optimisation ก็ทำได้เยอะมาก ๆ แต่พอรอบนี้ต้องทำจริง ๆ จัง ๆ ละ เลยลองหาทางเลือกอื่น ๆ เพิ่มเข้ามา PostgreSQL มันก็แว่บเข้ามา ไหน ๆ ก็มาแล้วเอา SQLite เข้ามาเล่นด้วยเลยละกัน หลังจากอ่าน ๆ กับเข้าไปดู Source Code จริง ๆ จัง ๆ แล้ว วันนี้จะมาเล่าแบบง่าย ๆ ว่าแต่ละตัวมันมีข้อดี ข้อเสียยังไงและแบบไหนละที่จะเหมาะกับงานของเรา

ปล. มานั่งอ่าน ๆ ช่วงนี้แล้วนึกย้อนกลับไป ถึงพวก Connector ที่ใช้เมื่อก่อนพวก JetDB หรือ ODBC ที่แบบเก่ามาก ๆ พวก DB2 Version แรก ๆ เลย เห้ยยย โลกเรามันมาไกลเนอะ ว่าแต่ทำไมตรูดูแก่จังอะเห้ยยย

SQLite

เริ่มที่ SQLite กันก่อน ถือว่าเป็นตัวที่ง่ายที่สุดแล้ว เพราะสิ่งที่มันเป็นจริง ๆ มันคือ File-Based RDBMS บ้างก็เรียกว่า Serverless RDBMS แต่เอาเป็นว่า มันเป็น RDBMS ที่เราไม่ต้องใช้ Server หรือสร้าง Service ในการรันเลย เราสามารถรันได้ผ่านการสร้างไฟล์สักตัวนึงอยู่ในเครื่องของเรา แล้วเราก็สามารถเรียกได้เลย

วิธีการทำงาน จะต่างจากเพื่อน ๆ ของเขาสักหน่อย ด้วยความที่ SQLite มันเป็นแค่ไฟล์ ๆ หนึ่งเท่านั้น ดังนั้น การจัดการทั้งหมด เช่น การเขียนต่าง ๆ หรือการอ่านตรงไหน ๆ มันเป็นเรื่องของโปรแกรมที่เราเอาเข้ามาต่อทั้งหมด โดยที่โปรแกรมที่ใช้อ่านและเขียนต่าง ๆ มันจะรู้ว่า มันต้องไปดู หรือ เขียนตรงไหน โดยที่มันยังรองรับสมบัติ ACID อย่างปกติเลย ทำให้ถ้าเราต้องการที่จะ Migrate ไป DB ที่ใหญ่กว่าได้ง่าย ๆ เลย

ข้อดีของมันคือ ความง่าย เราสามารถสร้าง Database ได้ง่ายมาก ๆ แทบไม่ต้องมานั่ง Setup อะไรเลย นอกจากสร้างไฟล์ใหม่ และ Migrate Table ลงไปได้เลย ไม่จำเป็นต้อง Setup Service อะไรทั้งนั้น แล้วพอเป็นไฟล์จริง ๆ แล้ว ถ้าเราต้องการทำสำเนา หรือ ต้องการจัดการต่าง ๆ เราก็สามารถ Copy ออกมาเป็นไฟล์ธรรมดาได้เลย ไม่ต้องผ่านขั้นตอนอะไรที่ยุ่งยากเลย นอกจากนั้น Footprint ของมันทั้งเรื่อง Memory และ Space เป็นอะไรที่น้อยมาก ๆ

แต่ข้อเสีย เราแบ่งเป็น 2 ส่วนคือ Concurrency และ Security เรื่องแรก มันขาด เพราะหลักการของการอ่านเขียน Database พวกนี้คือการเขียนไฟล์แล้วระหว่างนั้น เราต้องมีการ Lock File ไว้ชั่วคราว ทำให้เมื่อเรามี User จำนวนมากทะลักเข้ามาในระบบ เขียนข้อมูลลงไป เราอาจจะเจอปัญหา File มันโดน Lock โดย OS ได้ง่าย ๆ เลย ส่วนเรื่องของ Security เราพูดถึงการขาด เรื่องของ Access Control ต่าง ๆ ด้วยความที่เป็นไฟล์มันไม่มีการเข้ารหัส ดังนั้น ถ้ามีผู้ไม่หวังดีได้ไฟล์ไปคือ แตกทั้งบริษัทเลยทีเดียว

แต่จากข้อดีข้อเสีย ทำให้เรามองว่ามันเหมาะกับการทำงานบนอุปกรณ์ขนาดเล็ก ก็เหมือนส่วนที่ใช้เก็บข้อมูล ที่ดีกว่าการเขียนไฟล์โง่ ๆ แน่ ๆ ลดเวลาในการจัดการ Format Data ได้เยอะ หรือจะเป็นการเก็บข้อมูลเพื่อ Cache ข้อมูล และ ถึงเวลาเราก็ยัดขึ้น Server ทีหลัง ก็ได้เหมือนกัน หรือบ้าง ก็เอาไปสอนเด็ก ๆ ในเรื่องของ Database เพราะราคามันถูกไม่ต้อง Setup Server อะไรทั้งนัน ส่วนตัวปกติ เราจะชอบเอามาเก็บพวก Settings ต่าง ๆ ที่ซับซ้อนมาก ๆ แล้วทำเป็น Class ขึ้นมาเลย เวลาเรียก เราก็จะดูดจาก Database เอาเลย หรือจะ Sync ขึ้น Server มันก็ทำได้ง่าย ซึ่งเอาจริง ๆ คนส่วนใหญ่ก็มีการใช้ SQLite อยู่นะ

MySQL

MySQL เป็น RDBMS ที่ก่อนหน้านี้เราใช้ Implement หลาย ๆ Project มาก ๆ เรียกได้ว่า ส่วนใหญ่ที่ทำและใช้ Relational Database เราใช้เกือบหมดเลยทีเดียว โดยที่ทางผู้พัฒนาเคลมว่าเขาเป็น MySQL has been the most popular open-source RDBMS หรือก็คือเป็น RDBMS แบบ Open-Source ที่ได้รับความนิยมสูงมาก ๆ

ทำให้ข้อดีของพวกนี้คือการ Support จาก Community ที่เยอะมาก ๆ เพราะหลาย ๆ คนก็ใช้เหมือนกัน นอกจากนั้น มันมี 3rd-Party Tools ออกมารองรับเยอะมาก ๆ กับพวก Boilerplate ส่วนใหญ่ที่มี Database ติดมาด้วย ก็จะ Implement ด้วย MySQL ซะเยอะ เรามองว่า เพราะมันง่ายแหละจริง ๆ คนเข้าใจง่าย (เพราะชิน) ไม่อึนตอนใช้งาน อารมณ์ว่า ห่ะ Database อะไรนะ !! อะไรแบบนั้น สำหรับคนส่วนใหญ่

ถ้าเทียบกับ SQLite ตัว MySQL มี Data Type ทั่ว ๆ ไปให้เราใช้ค่อนข้างหลากหลาย ตัวอย่างเช่น ฝั่งของการเก็บจำนวนเต็ม (Integer) เองที่ใน SQLite เราอาจจะเก็บเป็น Integer ธรรมดาเลย เก็บได้ใหญ่สุด 8 bytes เท่านั้น แต่ในขณะที่ MySQL มันมีตั้งแต่พวก smallint, mediumint และ bigint กันไปใหญ่ จัดไปจุก ๆ หรืออันที่เราใช้แล้วรู้สึกคุ้มมาก ๆ คือพวก Boolean เพราะเมื่อก่อน ตอนเราเด็ก ๆ เลยประถม เราไม่เข้าใจเลยนะว่า ก็ทำไมละ เราจะเก็บเป็น Boolean เป็นตัวเลข ก็ใช้ Integer ก็ได้นิน่า โตมาก็อ่ออออ มันกินที่ !!!!! เราเก็บแค่ 1,0 ทำไมต้องใช้ถึง 8 Bytes มาเก็บฟร๊ะ ถ้าเราเข้าไปศึกษาข้างในจริง ๆ เราจะรู้เลยว่า การเลือก Data Type ให้เหมาะกับข้อมูล มันไม่ได้ช่วยแค่เรื่องของการกินพื้นที่การจัดเก็บที่ลดลง มันยังส่งผลต่อเรื่องของการทำ Indexing และการค้นหาต่าง ๆ ด้วย ดังนั้นการเลือก Data Type ให้เหมาะเลยเป็นเรื่องสำคัญไม่แพ้กับการออกแบบเลย อีกเรื่องที่ทำให้เรา Happy กับการใช้ MySQL มาก ๆ คือ Footprint ของมันที่อัตราส่วนของ User ต่อ Memory Consumption มันน้อยกว่า Postgres อยู่พอตัวเลย อันนี้มันก็นานมาแล้วละ ไม่รู้ว่าเดี๋ยวนี้ PostgreSQL เขาปรับรึยัง ถ้าเราย้อนกลับไปเมื่อก่อนตอนที่ MySQL ยังใช้ MyIASM อยู่ตอนนั้น คือ Feature หลาย ๆ อย่างสู้เพื่อน ๆ มันไม่ได้เลย แต่เรื่องที่มันโคตรเก่งเลยคือ Read Speed ดุดันมาก ๆ แต่พอในยุคปัจจุบัน เราอยู่ที่การใช้ InnoDB พวกเรื่อง Feature Set หลาย ๆ อย่างก็ถูก Implement มาเยอะจนเทียบกับเพื่อน ๆ ได้เลย

เรื่อง Performance ถ้าเทียบกับ PostgreSQL เดี๋ยวนี้ดูจาก Benchmark ใหม่ ๆ ก็สูสีกันแล้วละ เราเลยไม่เอามาเป็นข้อดีหรือข้อเสียอะไรเท่าไหร่ ทำให้ไปที่ข้อเสียต่อเลยละกันอย่างแรกคือ การขาด Advance Feature บางอย่าง เอาชัด ๆ เลยคือ FULL JOIN ทำไมพี่ไม่ทำมาคะ !!! แต่เอาเถอะมันพอจะ Workaround ได้อยู่แหละ เอาจริง ๆ เราว่าเดี๋ยวนี้ก็มีแค่นั้นเลยนะ และอีกข้อ เราไม่รู้จะเรียกข้อเสียดีมั้ย คือค่าพื้นฐานของระบบรักษาความปลอดภัย มันจะใช้ ACL (Access Control List) ซึ่งถ้าเทียบกับเพื่อน ๆ ของมัน ก็จะมีการ Implement พวก SE (Security Enhanced) ต่าง ๆ ตาม SELinux

MySQL เหมาะกับอะไรละ จริง ๆ เรามองว่า General Case อะไรก็ได้เลย มันเป็น Database ที่เริ่มใช้งานได้ง่ายมาก ๆ เพราะมันมี Community ที่ค่อนข้างใหญ่มาก ๆ มี Resource ให้เราหาอ่านได้ค่อนข้างเยอะ ตั้งแต่การ Setup ด้วยท่าต่าง ๆ จนไปถึงการ Optimise และการ Maintain ท่าแปลก ๆ ก็จะมีเยอะกว่า เมื่อเทียบกับตัวอื่น ๆ แต่เคสที่เราว่าทำให้ MySQL โดดเด่นมาก ๆ คือ เมื่อเราต้องการทำ Replication บน Transaction มหาศาล จากประสบการณ์ การใช้ MySQL คือตัวเลือกที่ปัญหาน้อยสุดแล้ว (ไม่เคยไปหามาเหมือนกันว่าเพราะอะไร อันนี้จากประสบการณ์ที่ใช้งานมา)

PostgreSQL

PostgreSQL เป็น Database ที่เรารู้จักในช่วงแบบมหาลัยเลยต้น ๆ เข้ากลาง ๆ ของชีวิตการเขียนโปรแกรมละ ก่อนหน้านั้น 6-7 ปีก่อนกด MySQL อย่างเดียวเลยจ้าาา ฮ่า ๆ (แหม่ แกร ตอนนั้น Xampp มันก็ดังอยู่นะแกรเก๋ ๆ มันมีมาให้แล้วก็ใช้ไป พอมี Docker ชีวิตอิฉันก็เปลี่ยนไปจากหลังเท้าเป็นหน้ามือทันที) แต่พอมารู้จักจริง ๆ แล้ว PostgreSQL มันเป็น Database ที่น่าสนใจมาก ๆ ตัวนึงเลยนะ เขาเคลมตัวเองว่าเป็น "The World's Most Advanced Open Source Relational Database" เลยนะ อย่าง Feature ที่เราชอบพวก MVCC (Multiversion Concurrency Control) ก็มีเป็นเจ้าแรกเลย จน MySQL ก็ตามทันตอนที่ออก InnoDB มา แต่สิ่งที่ทำให้ PostgreSQL มันต่างจาก MySQL คือคำว่า "object-relational database system" อันนี้แหละทำให้มันต่างมาก ๆ Feature อย่างการทำ Inheritance ก็จะมีให้ใน PostgreSQL เลย แต่มันก็จะไปคล้าย ๆ กับ Concept Foreign Key นั่นเอง หรือจริง ๆ เวลาเราเอาไปต่อกับ Application ของเรา เราอาจจะใช้พวก ORM ช่วยได้ มันก็จะให้ฟิลเวลาเขียนส่วนของ Application เป็น Object-Based เลย

แต่สิ่งที่เรามองว่ามันเป็นข้อดีของ PostgreSQL คือการรองรับ Data Type ที่เป็น NoSQL ด้วย เช่น พวก Geometric ต่าง ๆ เช่น Points, Circles และ Polygons ซึ่งเอาจริง ๆ นะ ยังไม่เคยใช้เหมือนกันฮ่า ๆ แต่ถ้าใครที่ใช้ มันก็ทำให้เราเก็บ และจัดการข้อมูลได้ง่ายขึ้นเยอะ แต่อีกอันที่เราชอบคือพวก Text Search Types คือ tsvector กับ tsquery พวกนี้บอกเลยว่าเปรี้ยวจี๊ดดดด มันทำให้เราทำพวก Text Search ในสเกล ย่อม ๆ ได้เลย โดยที่ไม่ต้องไปพึ่งพวก Full-Text Search ใหญ่ ๆ กินที่เยอะกว่ามาก เช่น Apache Solr กับไหน ๆ ก็พูดถึง NoSQL แล้ว ตัว PostgreSQL เองมันยังสามารถเก็บ และ ค้นหาของที่อยู่บน JSON ได้ด้วย ถ้าทำความเข้าใจง่าย ๆ มันเหมือนกับเราเอาพวก Document-Based DB มาแซมเป็นอีก Column นึงใน PostgreSQL แล้วค้นหามันได้ด้วยแหละ ดังนั้นข้อดีที่ทำให้ PostgreSQL มันไม่เหมือนเพื่อน ๆ คือการผสมความ NoSQL ลงไปใน RDBMS และทำงานพร้อม ๆ กันนี่แหละ เป็นลูกครึ่ง ๆ หน่อย และข้อดีอีกข้อคือ Security ที่เป็นค่าเริ่มต้นจะดีกว่า MySQL มาก เพราะมันมีการ Implement SEPostgreSQL ที่จะเข้ามาเสริมเรื่องความปลอดภัยได้ดี

มาที่ข้อเสียกันบ้าง PostgreSQL มันกิน Memory ดุมาก โดยเฉพาะเมื่อ Concurrent เราสูง ๆ เราต้องซื้อ RAM มาถวายมันเลย เพราะสิ่งที่มันทำเมื่อมันเจอ Concurrent คือ มัน Fork Process ออกมาเลยจ้าาา โอ้โห้ งามใส้กับ Memory อยู่ ในสเกลขนาดใหญ่อะนะ ถ้าสู้กับ MySQL เลย PostgreSQL แพ้เรื่อง Memory ไปเลย กับเมื่อเทียบกับ MySQL แล้ว PostgreSQL ความนิยมยังสู้ไม่ได้ ทำให้พวก Community มันจะใหญ่สู้ไม่ได้ กับ ต้องไปเช็คให้ดี ๆ นิดนึงว่าส่วนไหนมันรองรับหรือไม่รองรับ PostgreSQL หรือมันมี Driver อะไรที่ใช้ติดต่อ เช่น เคสส่วนตัวของเราเองเลยคือ เวลาเราทำงานกับ Python เราจะหลีกเลี่ยงการใช้ PostgreSQL เลย เพราะ Library ที่เราต้องใช้มันชื่อ psycopg เราโคตรมีปัญหากับมันเลย โดยเฉพาะเวลาติดตั้ง บางเครื่องติดตั้งแบบปกติได้เลยให้มันโหลด Source Code แล้วมา Compile ในเครื่องได้ บางเครื่องโดยเฉพาะพวก Apple Silicon ณ วันที่เขียน เราจะไม่สามารถลงแบบปกติได้ เราต้องไปโหลดแบบที่มันเป็น Binary มาแล้วอีก คือ งง ใจ งง ชีวิตมาก เลยพยายามเลี่ยงเมื่อต้องใช้ Python

ถามสุดท้ายคือ แล้วมันเหมาะกับใคร เอาจริง ๆ เราก็ให้เคสเฉพาะที่มันทั่วไปยากอยู่นะ ในเคสปกติการทำ Website ทั่ว ๆ ไปอะไรพวกนั้น เรามองว่าการใช้ MySQL มันตอบโจทย์กว่า อันที่เจ๋งขึ้นมา อาจจะต้องมีการจัดการกับข้อมูลที่เป็น NoSQL ด้วยเช่นการทำงานกับ JSON ต่าง ๆ แต่เคสที่ทำให้ PostgreSQL มันดูเด่นขึ้นมา จากที่เห็นน่าจะเป็นการเก็บข้อมูลที่ขนาดใหญ่มาก ๆ หลาย ๆ Terabyte เช่น เราใช้มันจัดการพวก Genomics Data ขนาดใหญ่ ๆ เราก็ใช้ PostgreSQL หรือการทำ Data Warehousing พวกนี้ทำให้ PostgreSQL เด่นจัด ๆ เลย

สรุป

3 RDBMS ที่เรายกตัวอย่างมาในบทความนี้เป็นแค่บางส่วนเท่านั้น จริง ๆ มันยังมี RDBMS ตัวอื่น ๆ อยู่อีกเช่น MariaDB ที่เป็นลูกของ MySQL (ก่อนที่จะโดน Oracle หิ้วไปอะนะ) ถ้าถามหาความเป็น Open-Source ขั้นสุดยอด MariaDB คือสุด ๆ ละ หรือจะเป็นจากฝั่ง Oracle กับ Microsoft เองก็มีของตัวเองเหมือนกัน การเลือกจริง ๆ มันขึ้นกับ Requirement ของ Application เลยว่า เราต้องใช้อะไรบ้าง แล้ว RDBMS ตัวไหนมันตอบโจทย์มากกว่า หรือบางที การกระโดดไป NoSQL มันจะตอบโจทย์กว่า อันนี้ก็ขึ้นกับการพิจารณาแล้วละ