SQLite โครงการฐานข้อมูล SQL ขนาดเล็กออกเวอร์ชั่น 3.45.0 เวอร์ชั่นแรกของปีนี้ โดยมีความเปลี่ยนแปลงสำคัญคือการเปลี่ยนโครงสร้างข้อมูลของฟิลด์แบบ JSON ให้เป็นไบนารี JSONB เพื่อเร่งประสิทธิภาพการทำงาน
การเปลี่ยนแปลงครั้งนี้ทำให้การประมวลผล JSON ทำได้เร็วขึ้นเพราะไม่ต้อง parse ข้อมูลจากข้อความโดยตรงทุกรอบที่ต้องการประมวลผลอีกต่อไป การทำงานยังคงแทบเหมือนเดิม โดยฟังก์ชั่นใน SQL ทั้งหมดที่เคยรองรับ JSON เดิมจะรองรับ JSONB ด้วย และแทบทุกฟังก์ชั่นที่คืนค่าเป็น JSON จะมีฟังก์ชั่นเทียบเคียงกันแต่คืนค่าเป็น JSONB
JSONB เป็นชื่อประเภทข้อมูลที่เริ่มใช้งานโดย PostgreSQL เพื่อเร่งความเร็วการประมวลผล JSON อย่างไรก็ดี SQLite นั้นไม่ได้ใช้โค้ดของ PostgreSQL แต่เขียนขึ้นใหม่เอง และมีความแตกต่างกันพอสมควร การประมวลผลบางอย่างมี big-O ไม่เท่ากัน
ตัวฟิลด์ JSONB นั้นเป็น BLOB ธรรมดา และผู้ใช้สามารถแก้ไขไบนารีได้โดยตรง แต่ทางโครงการเตือนว่าการแก้ไขจน JSONB ผิดรูปแบบ (malformed) อาจจะทำให้ผลลัพธ์คาดเดาไม่ได้ บางทีอาจจะคืนค่าถูก บางทีอาจจะคืนค่า error ว่าอ่านไม่ได้ รวมถึงแต่ละเวอร์ชั่นก็จะไม่รับประกันว่าจะได้ค่าเหมือนเดิม
ที่มา - SQLite
Comments
อันนี้งงๆ นิดนึงครับ
คำว่า "ไม่" เกินมา :/
lewcpe.com , @wasonliw
คนออกแบบ database สมัยใหม่ เริ่มจะลืม normalization N1 N2 N3 หมดแล้วจะใช้ field type เป็น json ลูกเดียว พอต้องแก้ schema ทีนี้อย่างเหนื่อย
+1 ออกโจทย์สัมภาษณ์ต้องบอกเพิ่มว่าไม่ใช้ JSON 🥲
ต้องออกโจทย์แก้โครงสร้าง JSON ด้วย SQL ด้วยเปล่าครับ ? หรือว่าไม่ได้ใช้ ?
ผมเห็นด้วยว่า normal forms เป็นเรื่องสำคัญนะครับ แต่สงสัยว่าทำไมเวลาแก้ schema และใช้ json แล้วเหนื่อย
เวลาแก้โครงสร้างไม่ได้สั่ง update ธรรมดาหรือครับ ? หรือว่า record เยอะก็เลยเหนื่อย ? หรือว่าเขียน schema ไว้ด้วยภาษาอื่นแล้วต้องมาแปลงเป็น SQL update ก็เลยเหนื่อย ?
ผมว่าเขาน่าจะหมายถึงวิธีการจัดเก็บข้อมูล บางคนเล่นเก็บแบบ JSON ล้วน ไม่ใช้ความสามารถของ Database กันเลย องค์ความรู้เดิมเกี่ยวกับ Relational Database เลยหายไป และความบรรลัยบังเกิดเมื่อฐานข้อมูลสเกลขึ้นแล้วต้องแยกข้อมูลออกจาก JSON
พอผมมองอีกที ถ้าใช้แต่ JSON ทำไมคนพวกนั้นเขาไม่ใช้ MongoDB หรือพวก Document Database กันไปเลยนะ
MongoDB เคยพบว่าเปลี่ยน version แล้ว query เก่าใช้ไม่ได้ กอปรกับมีประเด็นเรื่อง license นอกจากนั้นหลายกรณี SQLite ตัดตั้งสะดวกกว่ามากครับ
จริง ๆ มี ferretdb ที่เป็น proxy ให้ PostgreSQL กับ SQLite ใช้ wire protocol ได้ แต่ไม่แน่ใจว่ามันพร้อมใช้งานขนาดไหน
ผมไม่เคยใช้ของ MongoDB เลยไม่รู้ว่าความเป็นมาเป็นอย่างไร แต่โดยปกติแล้วไม่ว่าซอฟต์แวร์อะไรก็ไม่ควรอัปเกรดข้าม Major Version เพราะทุกอย่างจะเปลี่ยนตามหลักการ SemVer ต้องมาเช็กทุกอย่างว่ามีอะไรเปลี่ยนไปบ้าง ยกเว้นว่าเจ้านั้นมีเครื่องมือช่วย Migrate ที่ดี ซึ่งก็น้อยเจ้าที่ทำ
PostgreSQL นี่ upgrade ข้าม major มาหลายรอบ นิ่งมากๆ นะครับ จำไม่ได้เลยว่าเคยเจอปัญหา
lewcpe.com , @wasonliw
ถูกครับ แต่ไม่ควรใช้ซอฟต์แวร์ที่ end of life ด้วยและ MongoDB 2.X หมดอายุไปตั้งแต่ค.ศ. 2018
PostgreSQL ทำได้ดีหรืออย่างอย่างน้อยก็พอใช้ได้ครับ ทั้งเอกสารและ migration tool ภาษา SQL เองส่วนมากก็ backward compatible ด้วยครับ
รวบเม้นทั้งสองท่านมาตอบตรงนี้ หลักการ SemVer มันยังทำงานเหมือนเดิม เพียงแต่ว่าเจ้าของซอฟต์แวร์เลือกที่จะตามหรือไม่ก็ได้ ซึ่ง MongoDB เห็นได้ชัดเลยว่าไม่ทำตาม (แอบขอบคุณด้วยที่เตือนล่วงหน้า) ส่วนตัวผมก็ไม่เคยใช้ ผมเคยใช้เฉพาะบริการที่ใช้งานง่าย ๆ และ API ไม่ได้เปลี่ยนเยอะ
และในโลกอุดมคติผมก็เห็นด้วยมาก ๆ เคยไปเถียงอยู่รอบหนึ่งกับเกมเอนจิน Open-source บางเจ้าที่พังแม้กระทั่ง Minor Version เป็นประจำ (ให้ทาย) ก็เถียงอยู่นั่นแหละว่าหลักการ SemVer เราจะ Break Compat ยังไงก็ได้ แต่มันก็ควรจะมีแผน Migration ที่ดีก่อนข้ามเวอร์ชันไหม ไม่ใช่อยากจะทำอะไรก็ทำ คิดแล้วก็โมโหขึ้นมา 55555
ตอบในแง่ SemVar โดยรวมๆ ผมมองว่าแนวทาง SemVar นี่หมดความหมายไปเยอะแล้วครับ trend การรักษาความเข้ากันได้ทุกๆ minor แล้วรอ major version ค่อยปล่อยอะไรที่ break backward compatibility นี่มันสร้างปัญหามาก ที่เห็นได้ชัดคือ Python 2 -> 3
ถ้าตามกระแสเราจะเห็นว่าทุกคน "ช่างแม่ง" กับ SemVar กันเยอะแล้ว ด้วยการปล่อยให้ทุก release เป็น major เช่น เลขเวอร์ชั่นเบราว์เซอร์ที่เป็นร้อยแล้ว หรือเวอร์ชั่น nodejs ก็วิ่งเร็วกันสนุกสนานทีเดียว ต่อท้ายด้วย Python ที่เริ่ม break backward ด้วยการถอด standard lib ทิ้ง แม้จะไม่เปลี่ยนเลข major (แต่เอาเข้าจริงมันก็กระทบน้อยมากๆ)
lewcpe.com , @wasonliw
ผมเห็นด้วยนะครับว่าเดี๋ยวนี้การทำ breaking changes ในฝั่ง libs ใน minor release แทบจะเป็นเรื่องปกติไปแล้ว โดยเฉพาะกับตัวที่มีคนใช้น้อยๆ (เพราะคนกลุ่มนี้ ไม่ตามกลับไปอัพเดตกันเท่าไหร่)
เหมือนกับทีมพัฒนา lib เลือกที่จะพัฒนาฟีเจอร์ใหม่ๆแล้วปล่อยเลย (บางทีก็เหมือนกับต้องพัฒนาแข่งกับ lib คู่แข่ง) แทนที่จะรอ major หน้าเพื่อคง backward compatible เอาไว้
ขณะเดียวกัน dev ฝั่ง app ก็เหมือนพยัคหน้ารู้กันแล้วว่าฝั่ง lib มันเปลี่ยนได้ตลอด ถ้าตัวไหนที่ต้องอัพเดทบ่อยๆ อาจจะต้อง design ให้รองรับการอัพเกรดบ่อยๆ
..: เรื่อยไป
ผมไม่แน่ใจว่า MongoDB ทำตาม semvar หรือไม่นะครับ เพราะว่าผมก็อัปข้าม version หลักจริง ๆ ซึ่งจะมี breaking change ผมก็ไม่ได้ตำหนิอะไร แต่พอใช้ไปหลาย ๆ ปีก็มันจะมีความจำเป็นลักษณะนี้ขึ้นมาครับ รวมถึงอัป PHP 5 ไป PHP 8 และอื่น ๆ มากมายครับ
ส่วน PostgreSQL ผมประทับใจเป็นพิเศษครับ ไม่เคยเจอว่าต้องมาแก้ query ส่วน extension จะแก้บ้างก็ไม่ว่ากัน
ที่ผมเจอคือ เวลาจะเพิ่ม/แก้ไข field ใน json schema มันจะต้อง run script/sql update ทุก rowยิ่งถ้า field ของ json มี relation นี้ยิ่งลำบาก
ถ้าใช้ table primitive data (int, string, date, decimal, ...) field ทั่วไปนี้ง่ายกว่า, เร็วกว่าเยอะ
เวลาผมออกแบบผมคำนึงถึงว่ามันต้องแก้ไขง่ายก่อนอันดับแรกบางที requirement จาก user ตอนแรก บอกไม่แก้ๆ สุดท้ายก็เปลี่ยนใจแก้อยู่ดี
ถ้าแบบนี้ แค่ฟังก็เหนื่อยจริง ซึ่งมันไม่ควรจะออกมาท่านี้มั้ยนะ ข้อมูลที่เก็บเป็น JSON ควรจะอัพเดทค่าแบบ 1:1 เท่านั้นนะผมว่า และควรเป็นข้อมูลสำหรับเอกสารนั้นๆ ไม่มีการแก้ไขค่าตามฟังก์ชั่นที่ควบคุมเอกสารหลายๆใบ ถ้าแบบว่าทำ process อะไรบางอย่าง แล้วอัพเดทหลายๆ rows ดูแล้วยังไง JSON ก็ไม่เหมาะ
..: เรื่อยไป
อันนี้สยองเลย o_O
บ่อยครับ ประชุมตูม... ฟันมาว่าไป NoSQL ซักตัว แต่ไม่รู้ว่าทำไม ? นี่แหละจุดเริ่มต้นแห่งความสนุกได้เริ่มต้นแล้ว
ที่เคยเห็นใช้แล้วจบนะครับ คือ ใช้เป็น บิล หรือ ticket ที่ต้อง insert วันละเยอะ ๆ สำคัญแค่ ช่วงเวลาหนึ่งหลังจากนั้นลง archive แล้ว data ใน rows จะไม่เปลี่ยนเลย ถ้าเปลี่ยนคือ cancel ใบเก่า สร้างใบใหม่
แก้โครงสร้าง JSON (ของทุก Rows)
...
...
อาจจะเป็นไปได้ว่า มี business key นะ แต่ดันอยู่ใน JSON
เจอแบบนี้ ตัวใครตัวมันนะครับ เหอะๆ
ticket ในกรณีข้างในเป็น tree ที่ reply กันไปมาด้วยหรือเปล่าครับ หรือว่าเป็น list ของ comment ต่อกันไปเรื่อย ?
<3
ผมเองชอบ PostgreSQL และพอจะเข้าใจว่าทำมันถึงได้รับความนิยม การผสมผสานระหว่างข้อมูลแบบมี schema กับ non-schema ได้ ช่วยลดงานในการอัพเดท data บางอย่างได้เยอะจริงๆ
แต่การออกแบบ Database ก็ยังคิดในรูปแบบที่ว่าข้อมูลหลักๆต้องพยายามให้เป็น SQL ปกติไว้ก่อน
..: เรื่อยไป