เผยแพร่ครั้งแรกเมื่อวันที่ 30 เมษายน 2561 ที่ ObjectRocket.com/blog
Polyglot persistence หมายถึงการใช้เทคโนโลยีจัดเก็บข้อมูลที่แตกต่างกันเพื่อจัดการความต้องการจัดเก็บข้อมูลที่หลากหลาย มันเป็นสาขาของ polyglot programming—การใช้ภาษาโปรแกรมมิ่งที่แตกต่างกันเพื่อสร้างแอปพลิเคชัน อย่างง่ายๆ คือแอปพลิเคชันที่ใช้เทคโนโลยีฐานข้อมูลหลักมากกว่าหนึ่งตัว
การใช้เครื่องมือที่เหมาะสมสำหรับงานเป็นสิ่งสำคัญ และการใช้ฐานข้อมูลที่เหมาะสมสำหรับงานก็สำคัญเท่าเทียม แต่ละฐานข้อมูลมีจุดแข็ง จุดอ่อน และลักษณะเฉพาะ มีฐานข้อมูลร้อยๆ อยู่แล้ว ทำให้ยากที่จะติดตาม
จัดการความต้องการจัดเก็บข้อมูลของคุณ
Monoglot® ดี (และยังคงดี) สำหรับแอปพลิเคชันง่ายๆ ที่ใช้ workload ประเภทเดียว อย่างไรก็ตาม แอปพลิเคชันกลายเป็นซับซ้อนอย่างรวดเร็ว
แพลตฟอร์ม E-commerce เรียบง่ายใช้เครื่องมือต่อไปนี้:
- Session data เพื่อเพิ่มสินค้าในตะกร้า
- Search engine เพื่อค้นหาผลิตภัณฑ์
- Recommendation engine, การซื้อในอนาคตที่เป็นไปได้จากบันทึกการซื้อ
- Payment platform สำหรับบริการ geolocation
การนำ polyglot persistence ไปใช้ช่วยให้คุณขับเคลื่อนแอปพลิเคชันด้วยข้อมูลจากประเภทการจัดเก็บที่แตกต่างกัน คุณสามารถดึง financial transactions ที่เสร็จสิ้นจาก Oracle® ในขณะที่ติดตามข้อมูลผู้ใช้ใน MongoDB® และให้ Redis® จัดการ cache
นำ polyglot persistence ไปใช้และพิจารณาตัวเลือก
คำร้องเรียนหลายอย่างที่อ้างถึงความซับซ้อนของการสร้าง polyglot persistence มาจากการพยายามบังคับให้ storage solutions เข้าโปรเจกต์ที่ไม่เหมาะสม นั่นนำไปสู่การสร้าง support processes จำนวนมากและสถาปัตยกรรมมอนสเตอร์ที่เติบโตไม่รู้จบ
การวางแผนอย่างรอบคอบกำจัด 90% ของปัญหาที่เป็นไปได้ พิจารณาเป้าหมายของคุณ คุณต้องการ integral business function? คุณต้องการเริ่ม transition ส่วนใหญ่ของการดำเนินงานของบริษัทไปสู่โมเดลนี้?
ใช้เทคโนโลยีจัดเก็บข้อมูลที่เหมาะสม
ทีมของคุณเคยสร้าง polyglot persistence architecture มาก่อนไหม? มันท้าทายที่จะใช้ data solutions ที่เหมาะสมอย่างถูกต้องโดยไม่มีประสบการณ์ออกแบบโมเดลประเภทนี้ คุณรู้ได้อย่างไรว่าคุณเริ่มกับโปรเจกต์ที่ถูกต้อง?
ประเภทการจัดเก็บข้อมูล
องค์กรมักสุดท้ายแล้วใช้แหล่งข้อมูลหลายแหล่งเพื่อขับเคลื่อนแอปพลิเคชันของพวกเขา มาทบทวนตัวเลือกการจัดเก็บทั่วไปบางอย่าง:
Transactional databases หรือที่รู้จักว่า Relational Database Management Systems (RDBMS) ให้ความสมบูรณ์ของข้อมูลโดยจัดระเบียบข้อมูลเป็นตารางแถวและคอลัมน์ คุณเรียกข้อมูลโดยใช้ syntax statements ที่เรียกว่า queries องค์กรขนาดใหญ่หลายแห่งใช้ตัวเลือกยอดนิยมอย่าง Microsoft® SQL Server® และ Oracle® ข้อเสียหนึ่งของ transactional databases คือพวกมันอาจยากที่จะ scale เมื่อความต้องการจัดเก็บเพิ่มขึ้น นอกจากนี้ การค้นหาช้าลงเมื่อข้อมูลหนาแน่นและซับซ้อนมากขึ้นในการเข้าถึง
Non-transactional databases เปลี่ยนจากการใช้ RDBMS แบบตาราง ทำให้ scalability เพิ่มขึ้นและการค้นหาเร็วขึ้น พวกมันคู่กับ search และ analytic engines เช่น Elasticsearch ได้ดี มักใช้คำว่า NoSQL เพื่ออธิบายฐานข้อมูลเหล่านี้
Non-transactional storage types:
Non-transactional storage types รวมตัวเลือกต่อไปนี้:
- Key-value: ฐานข้อมูลเหล่านี้ใช้ key ที่ชี้ไปยังตำแหน่งจัดเก็บของชิ้นข้อมูล บางตัวใช้ hash-tables ในขณะที่อื่นๆ เช่น Redis เก็บคู่ในหน่วยความจำเพื่อการเข้าถึงเร็ว
- Document: ประกอบด้วย key-value pairs ที่บีบอัดอยู่ในเอกสารที่อนุญาตโครงสร้างโดยใช้ encoding เช่น JSON หรือ XML เวอร์ชันโอเพนซอร์สยอดนิยมรวม MongoDB และ CouchDB®
- Column: คุณวางข้อมูลลงในคอลัมน์ที่จัดกลุ่มแทนแถวเหมือนโครงสร้าง RDBMS Apache® Cassandra และ HBase® ใช้โมเดลนี้
- Graph: ใช้โครงสร้างกราฟ nodes, edges และ properties เพื่อจัดระเบียบและเรียกข้อมูล Neo4j® เป็นตัวอย่างที่กำลังเพิ่มความนิยม
การทำ polyglot persistence ให้ถูกต้องหมายถึงการรู้ว่าตัวเลือกข้อมูลไหนทำงานได้ดีที่สุดสำหรับความต้องการแอปพลิเคชันของคุณ
คำถามที่ควรถาม
คำถามโครงสร้างข้อมูล
- ข้อมูลของคุณมีโครงสร้างตามธรรมชาติไหม? เป็น unstructured ไหม?
- มันเชื่อมต่อกับข้อมูลอื่นอย่างไร?
- มันกระจายอย่างไร?
- คุณจัดการกับข้อมูลเท่าไหร่?
คำถามรูปแบบการเข้าถึง
- อัตราส่วน read/write ของคุณคือเท่าไหร่?
- มัน uniform หรือ random?
- การอ่านหรือการเขียนไหนสำคัญกว่าสำหรับแอปพลิเคชันของคุณ?
คำถามความต้องการองค์กร
- เราต้องการ authentication ไหม? ประเภทไหน?
- เราต้องการ encryption ไหม?
- เราต้องการ backups ไหม?
- เราต้องการ disaster site ไหม?
- เราต้องการ plugins ไหม?
- ระดับ monitoring ที่ต้องการคือเท่าไหร่?
- Drivers ไหนที่จำเป็น?
- ภาษาไหนที่ควรใช้?
- ควรใช้ third-party tools ไหม?
นำความช่วยเหลือที่เหมาะสมเข้ามา
บริษัทหลายแห่งจะได้ประโยชน์จากการนำผู้เชี่ยวชาญด้าน polyglot architecture มาช่วยตัดสินใจเหล่านี้ เพื่อให้คุณหลีกเลี่ยงการสิ้นสุดลงกับ maintenance loads เพิ่มเติมจากสถาปัตยกรรมที่ซับซ้อนเกินไป บางผู้ขายฐานข้อมูลโอเพนซอร์สยอดนิยมเสนอบริการจัดการ แต่พวกเขาจะบอกคุณไหมถ้า data source ของพวกเขาเองไม่เหมาะกับความต้องการของคุณ?
ดีที่สุดคือติดต่อบริษัทที่เข้าใจจุดแข็งและจุดอ่อนของตัวเลือกข้อมูลต่างๆ เพื่อเริ่มต้น polyglot persistence Rackspace ObjectRocket ให้มุมมอง 360 องศาของตัวเลือกฐานข้อมูลหลากหลายที่ใช้ได้กับความต้องการทางธุรกิจของคุณ เรานำ DBA และวิศวกรที่เหมาะสมที่สุดมาช่วยนำ big data solutions ของคุณไปสู่ระดับถัดไป
เรียนรู้เพิ่มเติมเกี่ยวกับบริการ DBA ของ Rackspace
ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม คุณยังสามารถคลิก Sales Chat เพื่อแชททันทีและเริ่มสนทนาได้
View the Rackspace Cloud Terms of Service
