Architecture and Data Topologies (สถาปัตยกรรมกับ Data Topology)

จุดตัดระหว่างสถาปัตยกรรมกับ data topology มักถูกมองข้าม การเลือกประเภทหรือ topology ของ database ผิดพลาดสามารถทำร้ายสถาปัตยกรรมและหักล้าง architectural characteristics ที่ดีที่สุดของมันได้ ตัวอย่างเช่น monolithic database แม้จะให้ data consistency และ transactional support ที่ดี แต่ก็สามารถลด scalability และ fault tolerance ได้ ในทำนองเดียวกัน distributed database topology แม้จะดีในด้าน scalability และการควบคุมการเปลี่ยนแปลง แต่ก็อาจลด data integrity, data consistency และ performance ของระบบได้

ส่วนถัดไปจะอธิบายจุดตัดระหว่างสถาปัตยกรรมกับ data topology

Database Topology (Database Topology)

topology ของ database ตามที่เราได้กล่าวถึงใน Chapter 15 หมายถึงวิธีที่ database ทางกายภาพถูกจัดวางไว้ภายในสถาปัตยกรรม topology พื้นฐานสามแบบ ได้แก่ monolithic database, distributed domain-based database หรือ distributed database-per-service topology Figure 26-4 แสดง database topology พื้นฐานเหล่านี้

Figure 26-4. ประเภททั่วไปของ database topology

database topology ต้องสอดคล้องกับสถาปัตยกรรมเพื่อให้ทำงานได้อย่างถูกต้อง ตัวอย่างเช่น microservices architecture มักใช้ pattern database-per-service เพื่อรักษา bounded context ที่เข้มงวด หากขาดความสอดคล้องที่เหมาะสมนี้ สถาปนิกจะควบคุมการเปลี่ยนแปลงได้ยากมาก และ operational characteristics ของระบบ เช่น fault tolerance, scalability, elasticity, maintainability, testability และ deployability จะได้รับผลกระทบทั้งหมด อย่างไรก็ตาม บาง style เช่น service-based architecture (ดู Chapter 14 ) มีความยืดหยุ่นมากกว่าในเรื่อง database topology ทางกายภาพ

Architectural Characteristics (Architectural Characteristics)

ใน Part II ของหนังสือเล่มนี้ เราแสดงให้เห็นว่า architectural style แต่ละแบบมี superpower ของตัวเอง (ให้คะแนน 4 ถึง 5 ดาว) และมีจุดอ่อน (1 ถึง 2 ดาว) ประเภทของ database ก็เช่นกัน และการทำให้ superpower ทางสถาปัตยกรรมของระบบสอดคล้องกับ superpower ที่ตรงกันของประเภท database นั้นสำคัญมาก ในหนังสือของเรา Software Architecture: The Hard Parts ผู้เขียนได้ให้คะแนน characteristics ของ database หกประเภท ได้แก่ relational, key-value, document, columnar, graph และ NoSQL คุณอาจจำได้ว่า scalability และ elasticity เป็น superpower ของ microservices, event-driven และ space-based architecture นอกจากนี้ยังเป็น superpower ของ key-value และ columnar database ด้วย ซึ่งหมายความว่า database ประเภทเหล่านี้เป็นตัวเลือกที่ดีในการขยาย characteristics ทางสถาปัตยกรรมเหล่านั้น

Data Structure (โครงสร้างข้อมูล)

โครงสร้างของข้อมูลที่ถูกจัดเก็บและเข้าถึงก็เป็นปัจจัยหนึ่งในจุดตัดนี้เช่นกัน หาก data structure เป็นแบบ relational นั่นคือสร้างขึ้นจากลำดับชั้นของความสัมพันธ์ที่พึ่งพากัน relational database ก็จะสอดคล้องได้ดี อย่างไรก็ตาม การเก็บ key-value pair ไว้ใน relational database เป็นความไม่สอดคล้องที่อาจนำไปสู่ความไม่มีประสิทธิภาพทั้งใน database และในสถาปัตยกรรม ไม่ใช่ข้อมูลทุกชนิดจะมีโครงสร้างเดียวกัน ดังนั้นต้องคอยสังเกตเรื่องนี้ ข้อมูลบางส่วนอาจเป็น relational ข้อมูลบางส่วนอาจเป็น document-based (โดยเฉพาะเมื่อจัดเก็บ payload ของ event หรือ request ที่เป็น JSON) และข้อมูลบางส่วนอาจเป็นแบบ key-value เมื่อพิจารณาถึงความหลากหลายของโครงสร้างข้อมูลที่อาจเกิดขึ้นได้ในสถาปัตยกรรมใดๆ เราแนะนำให้ใช้ polyglot database เมื่อทำได้

Read/Write Priority (ลำดับความสำคัญของ Read/Write)

หากปัญหาทางธุรกิจเกี่ยวข้องกับปริมาณ read หรือ write ที่สูง นั่นเป็นข้อมูลสำคัญสำหรับการทำให้ database topology สอดคล้องกับสถาปัตยกรรม ตัวอย่างเช่น หากสถาปัตยกรรมต้องการปริมาณ write สูงเป็นลำดับความสำคัญเหนือการ read ที่ไม่บ่อยนัก columnar database ก็จะเหมาะสม แต่หากตรงกันข้าม คือปริมาณ read สูงเป็นลำดับความสำคัญ key-value database, document database หรือ graph database ก็จะเหมาะสมกว่า หากระบบให้ความสำคัญกับ read และ write ในระดับที่ใกล้เคียงกัน relational database และ NewSQL database ก็จะเป็นตัวเลือกที่ดี การไม่สอดคล้องกันในปัจจัยนี้อาจนำไปสู่ระบบที่ทำงานได้ไม่ดี