อะไรคือกรณีการใช้งานของฐานข้อมูลแบบกราฟ (http://neo4j.org/)? [ปิด]

ฉันใช้ Relational DB เป็นจำนวนมากและตัดสินใจที่จะลงทุนในประเภทอื่น ๆ ที่มีอยู่

ผลิตภัณฑ์นี้ดูดีและมีแนวโน้ม: http://neo4j.org/

มีใครใช้ฐานข้อมูลแบบกราฟ ข้อดีข้อเสียจากแง่มุมการใช้งานคืออะไร?

คุณเคยใช้สิ่งเหล่านี้ในสภาพแวดล้อมการผลิตหรือไม่? อะไรคือข้อกำหนดที่แจ้งให้คุณใช้

ฉันใช้ฐานข้อมูลกราฟในงานก่อนหน้านี้ เราไม่ได้ใช้ neo4j มันเป็นของภายในที่สร้างขึ้นบน Berkeley DB แต่มันก็คล้าย ๆ กัน มันถูกใช้ในการผลิต (ยังคงเป็น)

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

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

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

ข้อเสียเปรียบหลักคือเราไม่ได้ใช้เทคโนโลยีฐานข้อมูลเชิงสัมพันธ์มาตรฐานซึ่งอาจเป็นปัญหาเมื่อลูกค้าของคุณเป็นองค์กร ลูกค้าของเราจะถามว่าทำไมเราไม่สามารถโฮสต์ข้อมูลของเราบนคลัสเตอร์ Oracle ขนาดใหญ่ได้ (ลูกค้าของเรามักจะมีศูนย์ข้อมูลขนาดใหญ่) หนึ่งในทีมเขียนเลเยอร์ฐานข้อมูลใหม่เพื่อใช้ Oracle (หรือ PostgreSQL หรือ MySQL) แต่ช้ากว่าเดิมเล็กน้อย องค์กรขนาดใหญ่อย่างน้อยหนึ่งแห่งมีนโยบายเฉพาะ Oracle แต่โชคดีที่ Oracle ซื้อ Berkeley DB เราต้องเขียนเครื่องมือพิเศษมากมายเช่นเราไม่สามารถใช้ Crystal Reports ได้

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

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

หากแอปพลิเคชันของคุณไม่จำเป็นต้องเข้ากับสถาปัตยกรรม blub ในปัจจุบันให้ใช้ฐานข้อมูลกราฟหรือ CouchDB หรือ BigTable หรืออะไรก็ตามที่เหมาะกับแอปของคุณและคุณคิดว่าเจ๋ง อาจทำให้คุณได้เปรียบและสนุกกับการลองสิ่งใหม่ ๆ

ไม่ว่าคุณจะเลือกอะไรก็ตามพยายามอย่าสร้างเครื่องมือฐานข้อมูลด้วยตัวเองเว้นแต่คุณจะชอบสร้างเอ็นจิ้นฐานข้อมูลจริงๆ

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

หากคุณทำงานใน Java อยู่แล้วฉันคิดว่าการสร้างแบบจำลองโดยใช้ Neo4j นั้นตรงไปตรงมามากและมีประสิทธิภาพที่ราบเรียบ / เร็วที่สุดสำหรับ R / W ของโซลูชันอื่น ๆ ที่เราพยายาม

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

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

โชคดี.

สองจุด:

อันดับแรกเกี่ยวกับข้อมูลที่ฉันทำงานร่วมกับ 5 ปีที่ผ่านมาใน SQL Server ฉันเพิ่งเข้าสู่กำแพงความสามารถในการปรับขนาดด้วย SQL สำหรับประเภทของแบบสอบถามที่เราต้องเรียกใช้ (ความสัมพันธ์ที่ซ้อนกัน ... คุณก็รู้ ... กราฟ ) ฉันเล่นกับ neo4j มาตลอดและเวลาในการค้นหาของฉันก็มีลำดับความสำคัญเร็วขึ้นหลายเท่าเมื่อฉันต้องการการค้นหาแบบนี้

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

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

ในการหยอดเหรียญวลีไม่มี Silver Bullet สายตาสั้นมากที่จะบอกว่าโมเดลฐานข้อมูลกราฟล้าสมัยและการใช้แบบจำลองนี้ทำให้ความคืบหน้า 40 ปี นั่นเหมือนกับการบอกว่าการใช้ C เป็นการละทิ้งความก้าวหน้าทางเทคโนโลยีทั้งหมดที่เราเคยผ่านมาเพื่อให้ได้สิ่งต่างๆเช่น Java และ C # นั่นไม่เป็นความจริงเลย C เป็นเครื่องมือที่จำเป็นสำหรับงานบางอย่าง และ Java เป็นเครื่องมือสำหรับงานอื่น ๆ

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

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

และเนื่องจากโมเดลออบเจ็กต์ในโค้ดมักเป็นโครงสร้างกราฟการแมปจากฐานข้อมูลจึงง่ายกว่าด้วยโค้ดน้อยลงและส่งผลให้บั๊กน้อยลง

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

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

ฉันกำลังสร้างอินทราเน็ตที่ บริษัท ของฉัน

ฉันสนใจที่จะเข้าใจวิธีโหลดข้อมูลที่จัดเก็บในตาราง (Oracle, MySQL, SQL Server, Excel, Access, รายการสุ่มต่างๆ) และโหลดลงใน Neo4J หรือฐานข้อมูลกราฟอื่น ๆ โดยเฉพาะจะเกิดอะไรขึ้นเมื่อข้อมูลทั่วไปซ้อนทับข้อมูลที่มีอยู่แล้วในระบบ

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

ตัวอย่างเช่นฉันทำงานในสภาพแวดล้อมการผลิต มีโครงการสำคัญที่เรากำลังดำเนินการอยู่และเนื่องจากความซับซ้อนแต่ละแผนกจึงได้สร้างสเปรดชีต Excel แยกต่างหากที่มีลำดับชั้นBOM (Bill Of Materials)ในคอลัมน์ทางด้านซ้ายจากนั้นบันทึกย่อและการตรวจสอบหลายคอลัมน์โดยบุคคล ใครเป็นคนทำแผ่นงานเหล่านี้

ดังนั้นปัญหาอย่างหนึ่งคือการรวมบันทึกเหล่านี้ทั้งหมดเข้าด้วยกันเป็น "มุมมอง" เดียวเพื่อให้ผู้อื่นสามารถมองเห็นปัญหาทั้งหมดที่ต้องได้รับการแก้ไขในส่วนใดส่วนหนึ่ง

ปัญหาที่สองคือสเปรดชีต Excel ดูดในการแสดง BOM แบบลำดับชั้นเมื่อมีการใช้ส่วนประกอบทั่วไปในชุดประกอบย่อยมากกว่าหนึ่งชุด หมายความว่าหากมีคนเขียนบันทึกเกี่ยวกับรีเลย์ P34 ในชุดประกอบย่อยของระบบจุดระเบิดความคิดเห็นเดียวกันควรเชื่อมโยงกับรีเลย์ P34 ที่ใช้ในชุดประกอบย่อยของไดรเวอร์มอเตอร์ สิ่งนี้จะไม่เกิดขึ้นในสเปรดชีต excel

สำหรับอินทราเน็ตของ บริษัท ฉันต้องการให้สามารถค้นหาอะไรก็ได้อย่างง่ายดาย เช่นข้อมูลที่เกี่ยวข้องกับหมายเลขชิ้นส่วนโครงสร้าง BOM หมายเลขโทรศัพท์ที่อยู่อีเมลนโยบาย บริษัท หรือขั้นตอน ฉันต้องการขยายส่วนนี้เพื่อจัดการสินทรัพย์ฮาร์ดแวร์คอมพิวเตอร์และซอฟต์แวร์ที่ติดตั้ง

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

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

นี่คือบทความดีๆที่พูดถึงความต้องการที่ฐานข้อมูลที่ไม่ใช่เชิงสัมพันธ์เติมเต็ม: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

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

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

_{หมายเหตุ: ฉันเป็นส่วนหนึ่งของทีม Neo4j}