บทความ IT เจ๋งๆ

เมื่อคุณจะเริ่ม Enterprise Database Project ใหม่ หนึ่งในขั้นตอนที่สำคัญที่สุด ก็คือ การเลือก Database ที่จะใช้สำหรับ Project นั้น ๆ ดังนั้นในบทความ เราจะมาดูกันว่า แนวทางการเลือก Database ให้เหมาะกับ Project ของคุณ มีอะไรบ้าง

ในช่วงไม่กี่ปีที่ผ่านมา ทุกคนคงได้ยินเรื่อง Big Data กันมาแล้ว ด้วยเหตุนี้จึงมีตัวเลือกมากมาย สำหรับความต้องการในการจัดการ Data ของคุณ แต่การเลือก Database ที่ถูกต้อง ควรทำความเข้าใจกับเรื่องต่อไปนี้ก่อน:

• ก่อนอื่นคุณต้องเข้าใจว่า Database ของคุณจะถูกใช้อย่างไรภายใต้ขอบเขตของ Requirements ของ Project ของคุณ
• ด้วย Database ประเภทหนึ่ง คุณจะตอบสนองความต้องการ Database ของคุณได้เพียงบางส่วนเท่านั้น
• Performance จะเกิดขึ้นหลังจากที่คุณได้จับคู่ Database ทั้งหมดของคุณกับประเภทของ Database ที่เหมาะสม
• มีการ Tradeoff ระหว่าง Consistency, Availability และ Partition Tolerance

1. ทำความเข้าใจกับ แนวคิดการ Tradeoff

เหตุผลที่เรามีตัวเลือก Database อยู่มากมายในปัจจุบัน ก็เนื่องจากแนวคิดเรื่อง CAP Theorem โดยที่ CAP ย่อมาจาก Consistency, Availability และ Partition Tolerance

• Consistency หมายความว่า ทุกครั้งที่มีการ Read ข้อมูลใด ๆ ระบบจะ Return ข้อมูลล่าสุดกลับมาให้เสมอ
• Availability หมายความว่า System จะสามารถให้บริการและตอบสนองการบริการอย่างถูกต้องภายในระยะเวลาที่สมเหตุสมผล
• Partition Tolerance หมายความว่า System จะยังคงทำงานต่อไปได้ถึงแม้ว่า Network หรือ Node ใด Node หนึ่งจะเสีย

“การจะทำให้ System มีคุณสมบัติพร้อมกันทั้ง 3 ข้อเป็นเรื่องยาก อย่างมากมักจะทำได้แค่ 2 ใน 3 ข้อ”

Relational Databases มีลักษณะโดดเด่นในเรื่อง Consistency ที่แข็งแกร่ง และมี Availability สูง แต่ก็ต้องแลกกับการมี Partition Tolerance ที่ด้อยลง พวกมันถูก Optimize เพื่อการ Write

ตัวอย่าง: SQL Server, MySQL, PostgresSQL, IBM DB2

Non-relational Databases ได้รับการพัฒนาเพื่อรองรับในเรื่อง “Availability และ Partition Tolerance” หรือ “Consistency และ Partition Tolerance” พวกมันถูก Optimize เพื่อการ Read

ตัวอย่าง: Memcached, Redis, Coherence, Hbase, BigTable, Accumulo, MongoDB, CouchDB

สำหรับ System ที่ซับซ้อนที่มีทั้งการ Read และการ Write เป็นจำนวนมาก มันอาจเป็นเรื่องสำคัญที่จะต้องมีการใช้ทั้ง Relational และ Non-Relational Databases ร่วมกัน เพื่อตัดแบ่ง Task ของการ Read และ Write เพื่อเป็นการ Optimize CAP นั่นเอง

2. คำถามสำคัญที่ต้องถามตัวเองก่อน

ขั้นตอนต่อไปในการเลือก Database คือการมีรายการคำถามที่ต้องถามเกี่ยวกับ Business Requirement ของคุณ และนี่คือคำถามบางส่วน:

• มีความสัมพันธ์มากน้อยแค่ไหนใน Data ของคุณ
• ความซับซ้อนของ Data อยู่ในระดับใด
• Data มีการเปลี่ยนแปลงบ่อยเพียงใด
• Application ของคุณมีการ Query Data บ่อยเพียงใด
• Application ของคุณมีการ query relationship ระหว่าง data ต่างๆ บ่อยแค่ไหน
• User ของคุณมีการ Update Data บ่อยเพียงใด
• User ของคุณมีการ Update Logic ใน Data บ่อยแค่ไหน
• Application ของคุณมีความสำคัญเพียงใดในสถานการณ์ที่เกิดความเสียหาย

3. ทำความเข้าใจกับ ข้อดี และข้อเสีย

Relational Databases ถูก Optimize สำหรับการ Write มันถูก Optimize สำหรับ Consistency และ Availability

• ข้อดี ของ Relational Databases ประกอบด้วย Simplicity, ความสะดวกในเรื่องการ Retrieve Data, Data Integrity และ Flexibility
• ข้อเสีย ของ Relational Databases ประกอบด้วย:

Costly — มีค่าใช้จ่ายสูงในการ Set up และ Maintain Database

Structured Limits — Relational Databases มีข้อจำกัดในเรื่องความยาวของ Field สิ่งนี้อาจเป็นเรื่องยุ่งยากสำหรับการจัดเก็บ Information จำนวนมากใน Field เดียว

Isolation — การมี Relational Databases ที่หลากหลาย สามารถกลายเป็น “Islands of Information” (การกระจายข้อมูลออกไปตามที่ต่าง ๆ) ได้ มันอาจเป็นเรื่องยากในการ Connect Database ที่พวกมันจะสื่อสารระหว่างกันได้

Non-Relational Databases ถูก Optimize สำหรับการ Read

พวกมันรองรับความต้องการทางด้าน “Availability และ Partition Tolerance” หรือ “Consistency และ Partition Tolerance”

• ข้อดี ของ Non-Relational Databases ประกอบด้วย:

Flexibility — การจัดเก็บ Structured, Semi-Structured และ Unstructured Data ที่มีปริมาณมาก ๆ

Agile Programming — สามารถรองรับให้เข้ากับการ Iterations ของ Sprints และ Code Pushes

Inexpensive Scalability — สามารถขยายสถาปัตยกรรมได้อย่างมีประสิทธิภาพโดยไม่ต้องใช้ค่าใช้จ่ายที่สูง ๆ

• ข้อเสีย ของ Non-Relational Database ประกอบด้วย:

Data Consistency — Non-Relational Database จะไม่มีการทำ ACID Transactions แต่จะใช้ “Eventual Consistency” แทน ซึ่งเพื่อให้ได้ Performance ที่ดีกว่า โดยยอมเสียเรื่อง Data Consistency ไปแทน

Standardization — ไม่มีมาตรฐานกลางของ API/Query Language สำหรับต Non-Relational Database ทุกตัว โดยแต่ละ Non-Relational Database จะมี API/Query language ของตัวเอง

Scalability — ไม่ใช่ Non-Relational Database ทุกตัว ที่จะมีระบบที่ดีในการกระจาย Data เท่า ๆ กันไปยังทุก Node ที่อยู่ใน Cluster เดียวกัน ซึ่งทำให้มีข้อจำกัด หรือ ยากในการ Scale up/down ตามความต้องการที่เปลี่ยนแปลงไป

4. ทำความเข้าใจประเภทต่าง ๆ ของ Non-Relational Database

ปัจจุบันนี้มี Non-Relational Database อยู่หลายประเภท พวกมันถูกจัดให้อยู่ในกลุ่มเฉพาะทาง โดยแต่ละกลุ่มของ Non-Relational Database ก็จะถูกใช้ตามวัตถุประสงค์ที่แตกต่างกันไป

Key-value — Database กลุ่มนี้ทำงานได้เป็นอย่างดีกับ Database Schema ทั่ว ๆ ไป มันเหมาะกับการ Read และ Write เป็นหลัก และมีการ Update ที่ไม่มากนัก พวกมันสามารถทำงานได้ดีมากเมื่อไม่มี Query หรือ Business Logic ที่ซับซ้อน

ตัวอย่าง: Redis, Dynamo DB และ Cosmos DB

Document — Database กลุ่มนี้ทำงานได้ดีมากหากคุณต้องการ Schema ที่มีความยืดหยุ่น Data จะถูกเก็บใน Format ของ XML หรือ JSON มันมีประสิทธิภาพที่สูงมากในการ Read และสามารถ Balance ประสิทธิภาพของการ Read กับ ประสิทธิภาพของการ Write ได้ คุณสามารถใช้ Index เพื่อเพิ่มประสิทธิภาพของคุณด้วย Database เหล่านี้

ตัวอย่าง: MongoDB, DynamoDB และ Couchbase

Graph — Database กลุ่มนี้เหมาะสมมากในกรณีที่คุณมี Database Schema ที่ซับซ้อน คุณต้องแสดง Business Logic บ่อยครั้งระหว่าง Node ต่าง ๆ ซึ่ง Graph Database จะช่วยให้คุณหาเส้นทางระหว่าง Node ได้

ตัวอย่าง: Neo4j, Cosmos Db และ Amazon Neptune

เมื่อคุณมีความเข้าใจถึงสิ่งที่จำเป็นที่ใช้ในการเลือก Database สำหรับ Enterprise Database Project ถัดไปของคุณ คุณสามารถเลือกสักหนึ่ง หรือ 2-3 Database ที่สามารถรองรับความต้องการของ Application ที่คุณมีได้อย่างครบถ้วน การเลือกของคุณจะเป็นการบ่งบอกว่าคุณคำนึงถึงความต้องการต่าง ๆ ของ Business มากน้อยแค่ไหน

ที่มา:  https://towardsdatascience.com/