JSON is coming to town

ความหวังเล็กๆ ของผม มาจากข่าว Google BigQuery เพิ่มการสนับสนุนข้อมูลที่เป็น JSON ถึงแม้ว่าจะเป็นช่วงเริ่มต้นที่เปิดให้ทดสอบแต่ก็ทำให้คิดฝันไปไกล
 
สมัยที่ทำโปรแกรมบัญชีครั้งแรกใช้ Btrieve เป็น database ทำให้เป็นคนที่ข้ามยุคสมัยของ FoxBase, Acces และ SQL มาเฉยๆ เพราะเริ่มต้นออกแบบตั้งแต่ก่อนที่ SQL จะแพร่หลาย
 
ตอนนั้นผมเคยเขียนถึง database ในฝันที่อยากได้เอาไว้..
 
"..
 
แนวคิดในการออกแบบโครงสร้างของฐานข้อมูลแบบ Dynamic ช่วยแก้ปัญหาในการปรับปรุงรายละเอียดของ การเก็บข้อมูลในอนาคต โดยไม่จำเป็นต้องเปลี่ยนแปลงโครงสร้างของฐานข้อมูล ขณะเดียวกันก็เป็นแนวคิดที่สามารถใช้งานกับ ระบบฐานข้อมูล Generation เก่าๆ ที่ไม่มีคุณสมบัติถึงระดับ RDBMS ได้ เป็นการผสมผสานระหว่างส่วนที่เป็น Fix Format Data ซึ่งมีการออกแบบในลักษณะที่เป็น Field เหมือนกับการออกแบบฐานข้อมูลตามรูปแบบที่โปรแกรมเมอร์ ส่วนใหญ่คุ้นเคย ผนวกกับส่วนที่เป็นข้อมูลเพิ่มเติม ซึ่งมีลักษณะเป็นเหมือนกับ News Info หรือ Free Form Data ซึ่งในกรณีนี้ในแง่ของระบบฐานข้อมูลหรือมาตรฐานก็คือ Memo Field นั่นเอง แต่ข้อมูลที่อยู่ใน Memo Field นี้จะมี โครงสร้างหรือ Format ภายในที่โปรแกรมสามารถรับรู้ และมองเป็น Extend Data Field ได้
 
จากประสบการณ์ของผมในการพัฒนาโปรแกรม ประสบการณ์ที่เกิดขึ้นมากที่สุดคือ การออกแบบระบบฐานข้อมูล ภายในเงื่อนไขของรายละเอียดของระบบที่ยังไม่สามารถวิเคราะห์สมบูรณ์ได้ และในองค์กรบางแห่งการพัฒนาโปรแกรมจะต้องควบคู่ไปกับการปรับปรุงระบบงานภายใน องค์กรที่ประสบความสำเร็จ ไม่เคยอยู่นิ่ง จะต้องมีการปรับเปลี่ยนตลอดเวลา
 
ดังนั้น ผมจึงใช้วิธีคิดให้น้อยที่สุด พิจารณาเฉพาะแก่นของข้อมูล (Core) อะไรที่ไม่ชัดเจนไม่ควรกำหนดเพื่อหรือ เดาล่วงหน้า แนวทางการออกแบบโครงสร้างของข้อมูลแบบ Dynamics นี้สามารถแก้ปัญหาอาการบานปลายของโครงสร้าง ข้อมูล กลายเป็นว่า เราจะพิจารณา Minimum Fields ที่จะต้องระบุไว้ในส่วนของ Fix Format เฉพาะลักษณะของ Field ข้อมูลตามเงื่อนไขต่อไปนี้
  
1. ข้อมูล Field นี้เป็นข้อมูลที่จำเป็นจะต้องมีในทุก Record หรือไม่ (Require)
2. ข้อมูล Field นี้ใช้ในการค้นหาและเรียงลำดับ (Search and Index)
 
.."
 
จนกระทั่ง 15 ปีต่อมา เมื่อต้องออกแบบโปรแกรมบัญชีใหม่ จึงได้รู้จัก database ที่เก็บข้อมูลในรูปแบบ JSON
รู้สึกว่า MongoDB เป็นอะไรที่กล้ามาก มีแนวคิดที่สุดไปอีกด้านหนึ่งกับคำว่า NoSQL แต่ที่โดนใจจริงๆ ตรงที่ schema-less ดูเหมือนจะใกล้เคียงกับ database ที่เคยฝันเอาไว้
 
การอธิบายแนวคิด database ใหม่ไม่ใช่เรื่องง่าย เพื่อให้นักพัฒนาที่คุ้นชินกับ SQL หรือ RDBMS ทำความเข้าใจได้ จึงต้องนำเสนอว่า collection เทียบเท่ากับ table และ document ที่เป็น JSON เทียบเท่ากับ row ทั้งๆ ที่ความจริงแล้ว JSON เป็นได้มากกว่านั้น เทียบเท่ากับ row + relational rows หากเข้าใจศักยภาพตรงนี้ สามารถลดงานและตัดทิ้งขั้นตอนที่ยุ่งยากของการเริ่มต้นออกแบบใน SQL ที่ต้องกำหนด schema แยกออกเป็น table ย่อยๆ และทำผังความสัมพันธ์ระหว่างกัน

ผมจะลองเล่าประสบการณ์การใช้งาน database ของโปรแกรมบัญชีใหม่ มาให้พิจารณากัน
ข้อมูลทางบัญชีทั้งหมดออกแบบให้เก็บอยู่ใน collection "docs" ที่เดียว (บ้าไหม)
 
โครงสร้างข้อมูลภายใน "docs" มีอยู่เพียง 5 ฟิลด์ เท่านั้น
 
1. "_type" เก็บประเภทเอกสาร ซื้อ, ขาย, จ่าย, รับ ฯลฯ
2. "_name" เก็บเลขที่เอกสาร
3. "_sys" ภายในเป็นฟิลด์ย่อย เก็บข้อมูลที่โปรแกรมสร้างหรือคำนวณเพื่อใช้งานภายใน
4. "info" ภายในเป็นฟิลด์ย่อย เก็บข้อมูลหัวบิล เช่น วันที่, ผู้เกี่ยวข้อง, ที่อยู่ ฯลฯ อาจมีรายละเอียดแตกต่างกันตามประเภทเอกสาร
5. "meta" ภายในเป็นฟิลด์ย่อย เก็บข้อมูลบรรทัดรายการในบิล ซึ่งแตกต่างกันตามประเภทเอกสาร
 
การทำงานของทีมพัฒนา ที่ต้องวางระบบและออกแบบรายงาน จึงใช้เวลาน้อยมากในการทำความเข้าใจและเรียนรู้โครงสร้างข้อมูล ด้วยความที่เป็น JSON เมื่อดูชื่อฟิลด์ที่อยู่ภายใน พร้อมกับตัวอย่างข้อมูลประกอบกัน ก็สามารถทำความเข้าใจโดยไม่ต้องมี schema เช่น "info.date", "info.address"
อยากทำรายงานยอดขายของเดือนนี้ ก็แค่ใช้คำสั่งกรองข้อมูล "@_type=ขาย && @info.date=$date เดือนนี้" ซึ่งจะแปลงเป็น query อ่านข้อมูลจาก database
 
การวางระบบที่ใช้งานแตกต่างกันสำหรับแต่ละกิจการ ผู้วางระบบสามารถปรับการป้อนข้อมูล เพิ่มฟิลด์พิเศษได้เอง มีเงื่อนไขสำคัญคือ ต้องเป็นฟิลด์ย่อยภายใต้ info หรือ meta เท่านั้น หลายครั้งที่ผมกลับมาทบทวนตัวเอง ถึงการเลือกเลี้ยวออกนอกทางที่คนส่วนใหญ่เขาทำกัน แล้วมาได้ไกลจนถึงทุกวันนี้ คิดว่า โชคและความบังเอิญ น่าจะเป็นปัจจัยหนึ่งที่สำคัญด้วย
 
บังเอิญที่ตอนออกแบบคิดคนเดียว ไม่ต้องเสียเวลาอธิบายคนอื่น บังเอิญที่มีทีมวางระบบที่ยอดเยี่ยม จึงกล้าออกแบบโปรแกรมที่มีแต่โครงพื้นฐานทำให้ดูแลง่าย แล้วผลักความซับซ้อนนั้นไปให้ทีมวางระบบต่อเติมแทน ถ้าตอนนั้นมีทีมโปรแกรมเมอร์หลายคนแบ่งงานกันทำก็จะต้องเลือกอีกทาง กว่าจะทำให้ทีมเข้าใจ MongoDB อาจเสียเวลามากกว่าใช้ SQL และหากไม่มีทีมพัฒนาที่สามารถพลิกแพลงวางระบบออกแบบรายงานได้หลากหลาย ก็ต้องออกแบบโปรแกรมที่ตรงไปตรงมาให้เอาไปใช้โดยไม่ต้องวางระบบ ถ้าถามว่า แลกกับอะไรมาบ้าง ราคาที่ต้องจ่ายเมื่อเลือกใช้ database ที่ไม่เป็น SQL คืออะไร ?
 

เรื่องที่สำคัญที่สุดคือรายงาน ไม่สามารถใช้โปรแกรมเก่งๆ ทั้งหลายในโลกทำรายงาน กราฟ หรือชาร์ตสวยๆ รวมถึง Excel และ Sheets ก็ไม่สามารถต่อตรงกับ database ทำให้ต้องสร้างโปรแกรมสำหรับออกรายงานที่อ่านและเข้าใจข้อมูล JSON ขึ้นมาใช้เอง ผลพลอยได้คืออ่านข้อมูล JSON จาก API ภายนอกต่างๆ มาสร้างเป็นรายงานได้ด้วย นอกจากนี้ยังต้อง export รายงานนั้นออกไปให้ Excel และ Google Sheets ก็เลยได้เครื่องมือใช้แปลง JSON เป็นสเปรดชีต นั่นคือส่วนที่ต้องลงทุนหรือออกแรงเยอะที่สุด เพื่อทำให้การใช้งานโปรแกรมบัญชีครบถ้วนอย่างที่ควรจะเป็น
 
อีกเรื่องหนึ่งคือ Business Intelligence (BI) ที่ใช้วิเคราะห์ทางธุรกิจ โดยทั่วไปจะเริ่มมีความต้องการเมื่อสะสมข้อมูลได้นานระยะหนึ่ง ยังไม่ใช่ทุกกิจการต้องการ BI
โปรแกรม BI ทั้งหลายรองรับเฉพาะโมเดลข้อมูลที่เป็นตาราง ไม่สามารถเข้าใจ JSON นี่ยังเป็นข้อจำกัดสำคัญ จะต้องติดตั้ง connector หรือออกแบบ data pipeline เพื่อสร้าง analytical database สำหรับงาน BI

สำหรับวิธีแรกการใช้ connector ไม่ควรต่อตรงกับ database ที่ใช้ทำงาน อาจมีผลกระทบจากการอ่านข้อมูลปริมาณมากโดยตัว BI ควรใช้เฉพาะทดสอบเท่านั้น หากใช้งานจริงจังควร clone database ออกมาต่างหาก แต่ก็จะทำให้มีข้อจำกัดทำงานกับข้อมูลถึง ณ เวลาที่ clone มาได้
 
ส่วนวิธีที่สอง data pipeline มีความซับซ้อน เป็นการถ่ายข้อมูลไปอีก database หนึ่งแบบอัตโนมัติ ทำให้มีข้อมูลล่าสุดใช้วิเคราะห์ตลอดเวลา
 
Google BigQuery เป็น database ที่ใช้งานคู่กับ Data Studio ที่เป็นเครื่องมือ BI ตัวหนึ่ง เมื่อสามารถเก็บข้อมูล JSON ได้ ทำให้ผมคิดฝันไปไกล มีความหวังว่าในอนาคตหาก Data Studio ปรับปรุงตามมาทันกัน ใช้ JSON ได้ด้วย ก็จะทำให้สามารถส่งข้อมูล JSON จาก MongoDB ไปเข้า BigQuery แล้วทำ BI ได้โดยไม่ต้องออกแรงมาก
 

อ่านเพิ่มเติม
 
Google BigQuery, Working with JSON data in Standard SQL https://cloud.google.com/bigquery/docs/reference/standard-sql/json-data/
MongoDB Connector for BI https://www.mongodb.com/docs/bi-connector/current/what-is-the-bi-connector/
 


 
June 2022 / Sathit J.