ทำไมนักพัฒนาจึงควรใช้ฐานข้อมูลกราฟ

เมื่อยี่สิบปีก่อนทีมพัฒนาของฉันได้สร้างเครื่องมือประมวลผลภาษาธรรมชาติที่สแกนการจ้างงานรถยนต์และโฆษณาอสังหาริมทรัพย์สำหรับหมวดหมู่ที่ค้นหาได้ ฉันรู้ว่าเรามีความท้าทายในการจัดการข้อมูลที่ยากลำบาก ข้อมูลในโฆษณาบางประเภทนั้นค่อนข้างตรงไปตรงมาเช่นการระบุยี่ห้อและรุ่นของรถยนต์ แต่ประเภทอื่น ๆ ต้องการการอนุมานเพิ่มเติมเช่นการระบุหมวดหมู่งานตามรายการทักษะ

เราได้พัฒนาโมเดลข้อมูลเมตาที่รวบรวมคำที่ค้นหาได้ทั้งหมด แต่ระบบประมวลผลภาษาธรรมชาติต้องการให้โมเดลแสดงความสัมพันธ์ของข้อมูลเมตาที่สำคัญ เราทราบดีว่าการออกแบบโมเดลข้อมูลเมตาที่มีการเชื่อมต่อโดยพลการระหว่างจุดข้อมูลในฐานข้อมูลเชิงสัมพันธ์นั้นซับซ้อนดังนั้นเราจึงสำรวจโดยใช้ฐานข้อมูลออบเจ็กต์เพื่อจัดการโมเดล

สิ่งที่เราพยายามทำในตอนนั้นด้วยฐานข้อมูลออบเจ็กต์สามารถทำได้ดีขึ้นในปัจจุบันด้วยฐานข้อมูลกราฟ ฐานข้อมูลกราฟจัดเก็บข้อมูลเป็นโหนดและข้อมูลที่ระบุความสัมพันธ์กับโหนดอื่น เป็นสถาปัตยกรรมที่ได้รับการพิสูจน์แล้วสำหรับการจัดเก็บข้อมูลที่มีความสัมพันธ์ที่ซับซ้อน

การใช้ฐานข้อมูลกราฟเติบโตขึ้นอย่างแน่นอนในช่วงทศวรรษที่ผ่านมาเนื่องจาก บริษัท ต่างๆพิจารณา NoSQL และเทคโนโลยีข้อมูลขนาดใหญ่อื่น ๆ ตลาดฐานข้อมูลกราฟทั่วโลกอยู่ที่ประมาณ 651 ล้านดอลลาร์ในปี 2561 และคาดการณ์ว่าจะเติบโตเป็น 3.73 พันล้านดอลลาร์ภายในปี 2569 แต่เทคโนโลยีการจัดการข้อมูลขนาดใหญ่อื่น ๆ อีกมากมายรวมถึง Hadoop, Spark และอื่น ๆ ได้รับความนิยมเพิ่มขึ้นอย่างมากการยอมรับทักษะ และกรณีการใช้งานการผลิตเปรียบเทียบกับฐานข้อมูลกราฟ จากการเปรียบเทียบขนาดของตลาดเทคโนโลยีข้อมูลขนาดใหญ่อยู่ที่ประมาณ 36.8 พันล้านดอลลาร์ในปี 2561 และคาดว่าจะเติบโตเป็น 104.3 พันล้านดอลลาร์ภายในปี 2569

ฉันอยากจะเข้าใจว่าเหตุใดองค์กรต่างๆจึงไม่พิจารณาฐานข้อมูลกราฟ นักพัฒนาคิดในวัตถุและใช้การแสดงข้อมูลตามลำดับชั้นใน XML และ JSON เป็นประจำ นักเทคโนโลยีและผู้มีส่วนได้ส่วนเสียทางธุรกิจเข้าใจกราฟอย่างแท้จริงเนื่องจากอินเทอร์เน็ตเป็นกราฟที่เชื่อมต่อกันผ่านการเชื่อมโยงหลายมิติและแนวคิดเช่นเพื่อนและเพื่อนของเพื่อนจากเครือข่ายสังคม เหตุใดทีมพัฒนาจึงไม่ใช้ฐานข้อมูลกราฟในแอปพลิเคชันของตนมากขึ้น

การเรียนรู้ภาษาแบบสอบถามของฐานข้อมูลกราฟ

แม้ว่าการทำความเข้าใจการสร้างแบบจำลองของโหนดและความสัมพันธ์ที่ใช้ในฐานข้อมูลกราฟอาจเป็นเรื่องง่าย แต่การสอบถามข้อมูลเหล่านี้จำเป็นต้องเรียนรู้แนวทางปฏิบัติและทักษะใหม่ ๆ

ลองดูตัวอย่างการคำนวณรายชื่อเพื่อนและเพื่อนของเพื่อน เมื่อสิบห้าปีก่อนฉันได้ร่วมก่อตั้งเครือข่ายโซเชียลการเดินทางและตัดสินใจที่จะทำให้รูปแบบข้อมูลเป็นเรื่องง่ายโดยการจัดเก็บทุกอย่างใน MySQL ตารางที่จัดเก็บรายชื่อผู้ใช้มีการเข้าร่วมด้วยตนเองเพื่อเป็นตัวแทนของเพื่อนและเป็นแบบสอบถามที่ค่อนข้างตรงไปตรงมาในการดึงรายชื่อเพื่อน แต่การไปหาเพื่อนในรายชื่อเพื่อนนั้นจำเป็นต้องมีการสืบค้นที่ซับซ้อนอย่างมหันต์ซึ่งได้ผล แต่ทำงานได้ไม่ดีเมื่อผู้ใช้มีเครือข่ายขยาย

ฉันได้พูดคุยกับ Jim Webber หัวหน้านักวิทยาศาสตร์ของ Neo4j ซึ่งเป็นหนึ่งในฐานข้อมูลกราฟที่เป็นที่ยอมรับเกี่ยวกับวิธีสร้างข้อความค้นหาเพื่อนของเพื่อน นักพัฒนาสามารถสืบค้นฐานข้อมูลกราฟ Neo4j โดยใช้ RDF (Resource Description Framework) และ Gremlin แต่ Webber บอกฉันว่าลูกค้ามากกว่า 90 เปอร์เซ็นต์ใช้ Cypher นี่คือวิธีการค้นหาใน Cypher สำหรับการดึงเพื่อนและเพื่อนของเพื่อน:

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)

WHERE me f

RETURN f

วิธีทำความเข้าใจคำค้นหานี้มีดังนี้

  • หารูปแบบที่มีโหนดที่มีป้ายกำกับบุคคลและชื่อคุณสมบัติ: 'Rosa' และผูกเข้ากับตัวแปร "ฉัน" คำค้นหาระบุว่า“ ฉัน” มีความสัมพันธ์แบบ FRIEND ขาออกที่ระดับความลึก 1 หรือ 2 กับโหนดอื่น ๆ ที่มีป้ายกำกับบุคคลและผูกการจับคู่เหล่านั้นกับตัวแปร“ f”
  • ตรวจสอบให้แน่ใจว่า "ฉัน" ไม่เท่ากับ "f" เพราะฉันเป็นเพื่อนของเพื่อน!
  • คืนเพื่อนและเพื่อนของเพื่อนทั้งหมด

แบบสอบถามมีความสวยงามและมีประสิทธิภาพ แต่มีเส้นโค้งการเรียนรู้สำหรับผู้ที่ใช้ในการเขียนแบบสอบถาม SQL ในนั้นความท้าทายแรกสำหรับองค์กรที่มุ่งไปยังฐานข้อมูลกราฟ: SQL เป็นชุดทักษะที่แพร่หลายและ Cypher และภาษาแบบสอบถามกราฟอื่น ๆ เป็นทักษะใหม่ในการเรียนรู้

การออกแบบลำดับชั้นที่ยืดหยุ่นด้วยฐานข้อมูลกราฟ

แค็ตตาล็อกผลิตภัณฑ์ระบบจัดการเนื้อหาแอปพลิเคชันการจัดการโครงการ ERP และ CRM ทั้งหมดใช้ลำดับชั้นในการจัดหมวดหมู่และแท็กข้อมูล แน่นอนว่าปัญหาคือข้อมูลบางอย่างไม่ได้เป็นลำดับชั้นอย่างแท้จริงและเรื่องต่างๆต้องสร้างแนวทางที่สอดคล้องกันในการจัดโครงสร้างสถาปัตยกรรมข้อมูล นั่นอาจเป็นกระบวนการที่เจ็บปวดโดยเฉพาะอย่างยิ่งหากมีการถกเถียงกันภายในเกี่ยวกับการจัดโครงสร้างข้อมูลหรือเมื่อผู้ใช้แอปพลิเคชันไม่พบข้อมูลที่ต้องการเนื่องจากอยู่ในส่วนอื่นของลำดับชั้น

ฐานข้อมูลกราฟไม่เพียง แต่เปิดใช้ลำดับชั้นตามอำเภอใจเท่านั้น แต่ยังช่วยให้นักพัฒนาสามารถสร้างมุมมองที่แตกต่างกันของลำดับชั้นสำหรับความต้องการที่แตกต่างกัน ตัวอย่างเช่นบทความเกี่ยวกับฐานข้อมูลกราฟนี้อาจแสดงภายใต้ลำดับชั้นในระบบการจัดการเนื้อหาสำหรับการจัดการข้อมูลเทคโนโลยีที่เกิดขึ้นใหม่อุตสาหกรรมที่มีแนวโน้มที่จะใช้ฐานข้อมูลกราฟกรณีการใช้ฐานข้อมูลกราฟทั่วไปหรือตามบทบาทของเทคโนโลยี เครื่องมือแนะนำจะมีชุดข้อมูลที่สมบูรณ์ยิ่งขึ้นเพื่อจับคู่เนื้อหากับความสนใจของผู้ใช้

ฉันได้พูดคุยกับ Mark Klusza ผู้ร่วมก่อตั้ง Construxiv ซึ่งเป็น บริษัท ที่ขายเทคโนโลยีให้กับอุตสาหกรรมการก่อสร้างรวมถึง Grit ซึ่งเป็นแพลตฟอร์มการจัดตารางการก่อสร้าง หากคุณดูกำหนดการของโครงการก่อสร้างเชิงพาณิชย์คุณจะเห็นข้อมูลอ้างอิงเกี่ยวกับการซื้อขายอุปกรณ์ชิ้นส่วนและแบบจำลองหลายรายการ แพ็กเกจงานเดียวสามารถมีงานหลายร้อยงานที่มีการอ้างอิงในแผนโครงการได้อย่างง่ายดาย แผนเหล่านี้ต้องรวมข้อมูลจาก ERPs, Building Information Modeling และแผนโครงการอื่น ๆ และนำเสนอมุมมองต่อผู้กำหนดตารางเวลาผู้จัดการโครงการและผู้รับเหมาช่วง Klusza อธิบายว่า“ ด้วยการใช้ฐานข้อมูลกราฟใน Grit เราสร้างความสัมพันธ์ที่สมบูรณ์ยิ่งขึ้นว่าใครกำลังทำอะไรเมื่อไหร่ที่ไหนกับอุปกรณ์อะไรและกับวัสดุใด ซึ่งช่วยให้เราปรับเปลี่ยนมุมมองในแบบของคุณและคาดการณ์ความขัดแย้งในการจัดตารางงานได้ดีขึ้น”

เพื่อใช้ประโยชน์จากลำดับชั้นที่ยืดหยุ่นจะช่วยในการออกแบบแอปพลิเคชันตั้งแต่ต้นด้วยฐานข้อมูลกราฟ จากนั้นแอปพลิเคชันทั้งหมดได้รับการออกแบบโดยอาศัยการสืบค้นกราฟและใช้ประโยชน์จากโหนดความสัมพันธ์ป้ายกำกับและคุณสมบัติของกราฟ

ตัวเลือกการปรับใช้ระบบคลาวด์ช่วยลดความซับซ้อนในการดำเนินงาน

การปรับใช้โซลูชันการจัดการข้อมูลลงในศูนย์ข้อมูลไม่ใช่เรื่องสำคัญ โครงสร้างพื้นฐานและการดำเนินงานต้องพิจารณาข้อกำหนดด้านความปลอดภัย ตรวจสอบข้อพิจารณาด้านประสิทธิภาพเพื่อเพิ่มขนาดเซิร์ฟเวอร์พื้นที่จัดเก็บข้อมูลและเครือข่าย และยังดำเนินการระบบจำลองสำหรับการกู้คืนระบบ

ปัจจุบันองค์กรที่ทดลองใช้ฐานข้อมูลกราฟมีตัวเลือกระบบคลาวด์หลายแบบ วิศวกรสามารถปรับใช้ Neo4j กับ GCP, AWS, Azure หรือใช้ประโยชน์จาก Aura ของ Neo4j ซึ่งเป็นฐานข้อมูลเป็นบริการ TigerGraph มีข้อเสนอบนคลาวด์และชุดเริ่มต้นสำหรับกรณีการใช้งานเช่นลูกค้า 360 การตรวจจับการฉ้อโกงเครื่องมือแนะนำการวิเคราะห์เครือข่ายสังคมและการวิเคราะห์ห่วงโซ่อุปทาน นอกจากนี้ผู้ให้บริการคลาวด์สาธารณะยังมีความสามารถในฐานข้อมูลกราฟซึ่งรวมถึง AWS Neptune, Gremlin API ใน CosmoDB ของ Azure, JanusGraph แบบโอเพนซอร์สบน GCP หรือคุณสมบัติกราฟในบริการฐานข้อมูลบนคลาวด์ของ Oracle

ฉันกลับไปที่คำถามเดิมของฉัน ด้วยกรณีการใช้งานที่น่าสนใจทั้งหมดมีแพลตฟอร์มฐานข้อมูลกราฟสำหรับผู้ใหญ่โอกาสในการเรียนรู้การพัฒนาฐานข้อมูลกราฟและตัวเลือกการปรับใช้ระบบคลาวด์เหตุใดองค์กรเทคโนโลยีจึงไม่ใช้ฐานข้อมูลกราฟ