การเลือกฐานข้อมูลที่ผิดสำหรับแอปพลิเคชันที่ต้องใช้ข้อมูลจำนวนมาก เป็นเหมือนการเปิดประตูสู่ความท้าทายและความซับซ้อนให้เป็นทวีคูณทั้ง ๆ ที่ไม่จำเป็น เชื่อเถอะว่าเลือกฐานข้อมูลให้ถูกแล้วชีวิตจะง่ายขึ้น ( เลือกฐานข้อมูล อย่างไรให้เหมาะสม )
ฐานข้อมูลที่คุณเลือกในวันนี้จะส่งผลต่อแอปพลิเคชันและความพยายามในการพัฒนาของคุณในอนาคต ทว่าการเลือกฐานข้อมูลของนักพัฒนามักเป็นการตัดสินใจทางด้านอารมณ์ และนักพัฒนามักเลือกฐานข้อมูลโดยพิจารณาจากสิ่งที่แอปพลิเคชันของตนต้องการในตอนเริ่มต้นเท่านั้น
ส่วนใหญ่นักพัฒนาอาจจะใช้กึ๋นของตัวเองตัดสินใจ เพราะพวกเขาละเลยการวิเคราะห์ว่าฐานข้อมูลจะทำงานดีกับแอปพลิเคชันของพวกเขาในวันนี้และในอนาคตหรือไม่
นักพัฒนาอาจรู้สึกหนักใจที่ต้องเลือกว่าจะใช้ฐานข้อมูลตัวไหน เพราะมันมีอยู่มากมายซึ่งมันจะสร้างความชะงักงัน ตามด้วยวิธีเลือกฐานข้อมูลที่ต้องสอดคล้องว่าแอปพลิเคชันเริ่มต้นขึ้นอย่างไร แต่คุณไม่เคยรู้หรอกว่าแอปจะมีเคสการใช้งานทั้งหมดเป็นอย่างไร และความจริงก็คือการใช้งานในแอปพลิเคชันมักจะเริ่มต้นจากง่าย ๆ ก่อนจะซับซ้อนขึ้นเมื่อเวลาผ่านไป
โดยทั่วไปนักพัฒนาอาจเริ่มต้นด้วย PostgreSQL จากนั้นจึงเพิ่ม MongoDB เนื่องจากพวกเขาต้องการทำงานกับข้อมูลกึ่งมีโครงสร้างหรือไม่มี เลยต้องการอะไรที่ยืดหยุ่นขึ้น อย่าง ProstgreSQL ก็จะเก็บข้อมูลที่อยู่ในรูปแบบเป็นตารางเหมือน Excel ซึ่งเคสนี้ถือว่าเป็นข้อมูลที่มีโครงสร้างชัดเจนแต่โลกสมัยใหม่ มันมีข้อมูลที่เริ่มไม่เป็นโครงสร้างเยอะขึ้นเลยต้องมาใช้ MongoDB ซึ่งเหมาะกับข้อมูลที่โครงสร้างไม่ตายตัวกว่าแทน
จากนั้นนักพัฒนาจึงเพิ่ม Elasticsearch ซึ่งก็คือการสร้าง Search Engine เหมือนเช่น Google ในแอปเราเอง เพื่อค้นหาพวก Log ที่ข้อมูลที่บันทึกประวัติ กิจกรรมต่าง ๆ ที่เกิดขึ้นบนแอป หรือ Faceted Search ค้นหาแบบสร้างหมวดหมู่ให้ก่อน (เช่นแอปเราขายเสื้อผ้าเราน่าจะเดาได้ว่าลูกค้าน่าจะค้นหาด้วยไซส์ ด้วยสี) และเมื่อเหล่านักพัฒนาพบว่าระบบทำงานช้า เขาก็จะเอา Redis ซึ่งเป็นเทคโนโลยีเรื่อง Cache (คือเทคโนโลยีที่ทำให้อะไรที่เราเคยค้นหามาแล้ว พอมาหาใหม่อีกทีมันจะเร็วขึ้น) มาช่วยในส่วนนี้ หรือถ้าพวกเขาต้องการทำการวิเคราะห์ นักพัฒนาก็จะสร้างคลังข้อมูล เช่น Snowflake มาอีก
ผลจากการมีข้อมูลเยอะจนต้องขยายฐานข้อมูล รวมถึงการใช้ ETL (Extract, Transform, and Load คือบางทีข้อมูลที่เราได้มาต้องมีการดึง =Extract เอามาแปลรูปเช่นเปลี่ยน ค.ศ. เป็น พ.ศ. =Transform และเอาไปใส่ที่ระบบอื่น=Load) ที่มีค่าใช้จ่ายสูง ทำให้นักพัฒนาเกิดความกังวลและสับสนเวลาย้ายข้อมูลระหว่างฐานข้อมูล แต่มันก็ไม่จำเป็นต้องทำเป็นนี้เสมอไป เราขอเสนอวิธีการเลือกฐานข้อมูลที่ต่างออกไปเพื่อตอบสนองทุกความต้องการของนักพัฒนาอย่างคุณ
1.มองไปให้ไกลกว่าอนาคตอันใกล้
การโยกย้ายฐานข้อมูลและการปรับแพลตฟอร์มใหม่ไม่ใช่เรื่องแปลก ตอนเลือกฐานข้อมูล นักพัฒนาควรคำนึงไว้ว่าคุณกำลังเลือกสิ่งที่ยากต่อการปรับเปลี่ยนและทำให้คุณต้องติดกับการเก็บข้อมูลรูปแบบนั้น ๆ
ลองนึกดูว่าฐานข้อมูลที่คุณเลือกมีคุณสมบัติตรงตามข้อความต้องการปัจจุบันของคุณและสามารถช่วยให้คุณดำเนินการต่อในอนาคตได้หรือไม่ ถามตัวเองด้วยคำถามเหล่านี้:
- คุณต้องการอะไรจากฐานข้อมูลของคุณหากแอปพลิเคชันของคุณเกิดปังขึ้นมา?
- ฐานข้อมูลที่คุณเลือก สามารถเพิ่มฟังก์ชัน ลูกเล่นใหม่ ๆ ที่น่าสนใจในภายหลังได้หรือไม่?
- คุณกำลังเลือกฐานข้อมูลโดยพิจารณาแค่สิ่งที่จะทำให้คุณสาธิตตอนนี้หรือไม่?
คุณอาจจะเอนเอียงไปที่ MongoDB แล้วปล่อยผ่านให้มันเป็นแบบนั้น แต่จำไว้ว่าการตัดสินใจอย่างฉับพลันในวันนี้อาจทำให้คุณเสียใจในภายหลัง
2. หลีกเลี่ยงความสับสนเมื่อคุณขยายระบบ
ฐานข้อมูลแบบเดิมจะใช้สถาปัตยกรรมแบบ Scale-up โดยมีหลักการคือเวลาระบบขยาย ต้องปรับให้ทรัพยากรภายใต้การออกแบบเดิมสามารถทำงานให้เยอะขึ้น เก่งขึ้น ซึ่งหมายความว่าหากคุณต้องการทำงานให้เร็วขึ้น คุณต้องเปลี่ยนไปใช้ฮาร์ดแวร์ที่ใหญ่ขึ้น ซึ่งเป็นการเพิ่มค่าใช้จ่ายจำนวนมาก แต่โดยทั่วไป ฐานข้อมูลสมัยใหม่จะอิงตามสถาปัตยกรรมแบบ Scale-out โดยมีหลักการคือไปเพิ่มคนมาช่วยทำแทน แน่นอนคุณยังต้องเพิ่มฮาร์ดแวร์แต่ราคามันจะเป็นสัดส่วนกับมูลค่าที่คุณต้องเพิ่ม ดังนั้นมันอาจจะเป็นทางเลือกที่ดีกว่า
ฐานข้อมูลแบบเก่าอย่าง MySQL และ PostgreSQL ได้มีการแก้ไขในความสามารถในการขยายขนาด โดยวิธีการทั่วไปที่ใช้ก็มักจะเกี่ยวข้องกับการแบ่งส่วนข้อมูลหรือแบ่งฐานข้อมูลออกเป็นส่วน ๆ (Sharding) ผลลัพธ์ที่ได้คือ แทนที่จะมีฐานข้อมูล MySQL ขนาดใหญ่เพียงก้อนเดียว คุณอาจมี MySQL เล็ก ๆ กว่า 10 ก้อน แต่สิ่งที่คุณต้องควรระวังคือหากคุณเลือกผู้ที่จะใช้วิธีนี้ในการขยายระบบ และต้องการเรียกค้นข้อมูลที่ต้องการแชร์ข้อมูลระหว่างชาร์ดต่าง ๆ คุณอาจประสบปัญหา อย่างเช่น หากเราผู้จะหาว่าใครใช้งานแอปมากที่สุดในเขต หรือภูมิภาคนี้ ข้อมูลการใช้งานที่ถูกกระจายเรียกใช้ระหว่างฐานข้อมูลยิบย่อยหลายก้อนย่อมถูกนำมาคำนวณเปรียบเทียบร่วมกันได้ลำบาก
3. ทำงานได้ทั้งแนวตั้งและแนวนอน
การเก็บข้อมูลเชิงคอลัมน์ Column Stores เหมาะมากสำหรับการวิเคราะห์เพราะช่วยให้คุณสแกนข้อมูลจำนวนมากได้อย่างรวดเร็ว ในขณะที่ถ้าเก็บแบบเชิงแถว Row Stores จะเหมาะกับงานที่สนใจข้อมูลของทั้งรายการมากกว่า ซึ่งสมัยก่อนในการเลือกระบบฐานข้อมูลคุณต้องเลือกระหว่างพื้นที่เก็บข้อมูลเชิงคอลัมน์และหน่วยเก็บเชิงแถว แต่ตอนนี้คุณไม่จำเป็นต้องเลือกแบบใดแบบหนึ่งอีกต่อไป เพราะฐานข้อมูลสมัยใหม่เป็นแบบรวมหน่วยแบบเก็บเชิงแถวและคอลัมน์ไว้ในตารางเดียวกันแล้ว
ในกรณีนี้ ข้อมูลจะถูกเขียนลงในที่จัดเก็บแถวในหน่วยความจำเพื่อให้สามารถทำธุรกรรมและค้นหาได้รวดเร็วมาก ๆ ในขณะที่เทคโนโลยี Data Quiesces จะทำให้ข้อมูลที่ไม่ได้เอามาใช้วิเคราะห์จะถูกเขียนกลับไปที่ที่เก็บคอลัมน์ ซึ่งช่วยให้คุณวิเคราะห์ข้อมูลได้อย่างมีประสิทธิภาพเช่นกัน
4. ทำให้เร็วขึ้น แต่ไม่ใช่ที่กายภาพ
ฐานข้อมูลแบบดั้งเดิมได้รับการออกแบบโดยใช้ดิสก์แม่เหล็กซึ่งเป็นปัจจัยหลักของเวลาแฝงที่ใช้ค้นหา ในขณะที่ผู้จำหน่ายฐานข้อมูลได้ออกแบบ Algorithm เพื่อลดเวลาแฝงนั้นให้เหลือน้อยที่สุด แต่ก็มีการจำกัดทางกายภาพสำหรับระยะเวลาที่ใช้ในการหมุนดิสก์และหัวดิสก์เพื่อให้ได้ตำแหน่งอยู่ดี
คุณลดความล่าช้าที่เกี่ยวข้องกับการอินพุต/เอาต์พุตได้ผ่านการใช้อุปกรณ์เก็บข้อมูลชนิดใหม่ที่ไม่มีชิ้นส่วนเคลื่อนไหวอย่าง Solid State Drive (SSD) ซึ่งจัดการข้อมูลได้เร็วกว่าดิสก์ที่หมุนได้ถึง 200 เท่า หากเป็นการเขียนข้อมูลเพิ่มลงในฐานข้อมูลที่ออกแบบไว้ คุณเพียงแค่ต้องต่อท้ายเข้าไป แต่หากคุณแค่อ่านหรือค้นหาข้อมูล คุณแทบจะไม่จำเป็นต้องยุ่งกับดิสก์เลย
5. เข้าใจให้น้อยลงแต่ได้ประสิทธิภาพมากขึ้น
ฐานข้อมูลในอดีตขาดความเร็ว ความยืดหยุ่น และความสามารถในการรองรับแอปพลิเคชันทั้งหมดของคุณ ด้วยเหตุนี้ ธุรกิจจำนวนมากที่มีการดำเนินการมายาวนานจึงได้รวบรวมฐานข้อมูลที่แตกต่างกันจำนวนมากเมื่อเวลาผ่านไป
แอปพลิเคชันสมัยใหม่ที่มีการใช้ข้อมูลจำนวนมากย่อมต้องการเทคโนโลยีฐานข้อมูลรูปแบบใหม่ ฐานข้อมูลที่เลือกใช้จำเป็นต้องเอื้อให้มีการขยายขนาดได้อย่างมีประสิทธิภาพและเอื้อต่อความเรียบง่ายในเชิงสถาปัตยกรรมไปพร้อมกัน การออกแบบฐานข้อมูลควรรองรับการใช้งานทั้งในเชิงธุรกรรม (เพิ่ม แก้ไข ลบ ข้อมูลในทะเบียน) และในเชิงการวิเคราะห์ รองรับการสืบค้นบนคลังข้อมูลขนาดใหญ่เพื่อการวิเคราะห์ได้อย่างรวดเร็วและพร้อมกันจากหลากหลายการเรียกใช้ รวมไปถึงครอบคลุมข้อมูลที่หลากหลายประเภทตามการใช้งาน
บทความโดย Jordan Tigani
เนื้อหาจากบทความของ InfoWorld
แปลและเรียบเรียงโดย วิน เวธิต
ตรวจทานและปรับปรุงโดย พีรดล สามะศิริ
Senior Project Manager & Data Scientist
at Big Data Institute (Public Organization), BDI
