เหตุใดระบบควบคุมแหล่งข้อมูลจึงยังคงสำรองข้อมูลส่วนใหญ่อยู่

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

ดังนั้นทำไม SVN ฉันเชื่อว่า GIT, CVS และอื่น ๆ ยังคงใช้ระบบไฟล์เป็นฐานข้อมูลเป็นหลัก (ฉันถามคำถามนี้เพราะเรามีเซิร์ฟเวอร์ SVN ของเราเพียงเสียหายในช่วงคอมมิชชันปกติ) แทนที่จะใช้ซอฟต์แวร์ฐานข้อมูลจริง ( MSSQL, Oracle, Postgre, ฯลฯ )?

แก้ไข: ฉันคิดว่าอีกวิธีหนึ่งในการถามคำถามของฉันคือ "ทำไมนักพัฒนา VCS จึงหมุนระบบจัดเก็บข้อมูลของตนเองแทนที่จะใช้ระบบที่มีอยู่?"

TL; DR: ระบบควบคุมรุ่นไม่กี่ใช้ฐานข้อมูลเพราะมันไม่จำเป็น

เป็นคำถามสำหรับคำตอบคำถามทำไมพวกเขาจะไม่? ระบบฐานข้อมูล "ของจริง" มีประโยชน์อะไรบ้างที่นำเสนอผ่านระบบไฟล์ในบริบทนี้

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

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

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

ดูเหมือนว่าคุณจะมีสมมติฐานมากมายซึ่งอาจขึ้นอยู่กับประสบการณ์ของคุณกับ SVN และ CVS

Git และ Mercurial นั้นเหมือนกับ SVN และ CVS

การเปรียบเทียบ git และ CVS เปรียบเสมือนการเปรียบเทียบ iPad กับ Atari CVS ถูกสร้างขึ้นกลับเมื่อ dinoaurs ทั่วโลก การโค่นล้มนั้นเป็นรุ่นปรับปรุงของ CVS สมมติว่าระบบควบคุมเวอร์ชันที่ทันสมัยเช่น git และ Mercurial ทำงานเหมือนพวกมันมีเหตุผลน้อยมาก

ฐานข้อมูลเชิงสัมพันธ์มีประสิทธิภาพมากกว่าฐานข้อมูลแบบจุดประสงค์เดียว

ทำไม? ฐานข้อมูลเชิงสัมพันธ์จะจริงๆซับซ้อนและอาจจะไม่เป็นที่มีประสิทธิภาพฐานข้อมูลวัตถุประสงค์เดียว ความแตกต่างบางอย่างอยู่ด้านบนของหัวของฉัน:

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

ฐานข้อมูลเชิงสัมพันธ์ปลอดภัยยิ่งขึ้น

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

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

ฉันจะยืนยันว่าระบบควบคุมเวอร์ชันแบบกระจาย (เช่น git และ Mercurial) ดีกว่าสำหรับการปกป้องฐานข้อมูลของคุณมากกว่าการควบคุมเวอร์ชันรวมศูนย์เนื่องจากคุณสามารถกู้คืน repo ทั้งหมดจากโคลนใดก็ได้ ดังนั้นถ้าเซิร์ฟเวอร์กลางของคุณเป็นธรรมชาติ combusts พร้อมกับทั้งหมดของการสำรองข้อมูลของคุณคุณสามารถเรียกคืนได้โดยการทำงานgit initบนเซิร์ฟเวอร์ใหม่แล้วgit pushจากเครื่องของนักพัฒนาซอฟต์แวร์ใด ๆ

การประกอบล้อใหม่ไม่ดี

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

"ถ้าสิ่งที่คุณมีคือค้อนทุกสิ่งดูเหมือนเป็นเล็บ"

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

สำหรับเหตุผลที่เราจะไว้วางใจนักเขียนของระบบการควบคุมการแก้ไขที่จะรู้ว่าสิ่งที่พวกเขากำลังทำ .. ฉันไม่สามารถพูด VCS อื่น ๆ แต่ผมค่อนข้างมั่นใจว่าLinus Torvalds เข้าใจระบบไฟล์

เหตุใดระบบควบคุมเวอร์ชันเชิงพาณิชย์บางรุ่นจึงใช้ฐานข้อมูลเชิงสัมพันธ์

มีโอกาสมากที่สุดที่จะรวมกันดังต่อไปนี้:

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

svnใช้จริงเพื่อใช้ BDB สำหรับที่เก็บ ในที่สุดนี่ก็ถูกกำจัดเพราะมันมีแนวโน้มที่จะแตก

VCS ว่าขณะนี้ใช้ฐานข้อมูลอื่น (SQLite) fossilเป็น นอกจากนี้ยังรวมการติดตามบั๊ก

ฉันเดาเหตุผลที่แท้จริงคือ VCSes ทำงานกับไฟล์จำนวนมาก ระบบไฟล์เป็นเพียงฐานข้อมูลประเภทอื่น (ลำดับชั้นโดยเน้นที่ประสิทธิภาพการจัดเก็บ CLOB / BLOB) ฐานข้อมูลปกติจัดการไม่ดีเพราะไม่มีเหตุผล - ระบบไฟล์มีอยู่แล้ว

1. ระบบไฟล์เป็นฐานข้อมูล ไม่ใช่ฐานข้อมูลเชิงสัมพันธ์ แต่ส่วนใหญ่เป็นร้านค้าคีย์ / ค่าที่มีประสิทธิภาพมาก และหากรูปแบบการเข้าถึงของคุณได้รับการออกแบบมาอย่างดีสำหรับที่เก็บคีย์ - ค่า (เช่นรูปแบบที่เก็บ git) ดังนั้นการใช้ฐานข้อมูลอาจไม่ได้มีข้อได้เปรียบที่สำคัญมากกว่าการใช้ระบบไฟล์ (อันที่จริงแล้วมันเป็นเพียงอีกชั้นหนึ่งของสิ่งที่เป็นนามธรรมที่จะเข้ามาขวางทาง)

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

3. ความต้องการข้ามแพลตฟอร์มทำให้การใช้ฐานข้อมูลมีความท้าทายมากขึ้น

   เครื่องมือควบคุมเวอร์ชันส่วนใหญ่สร้างขึ้นเพื่อใช้งานบนหลายแพลตฟอร์ม สำหรับเครื่องมือควบคุมรุ่นที่รวมศูนย์สิ่งนี้มีผลกับส่วนประกอบของเซิร์ฟเวอร์เท่านั้น แต่ก็ยังยากที่จะใช้เซิร์ฟเวอร์ฐานข้อมูลเดียวเนื่องจากผู้ใช้ Unix ไม่สามารถติดตั้ง Microsoft SQL Server และผู้ใช้ Windows อาจไม่เต็มใจที่จะติดตั้ง PostgreSQL หรือ MySQL ระบบไฟล์เป็นตัวหารร่วมน้อยที่สุด แต่มีเครื่องมือหลายอย่างที่เซิร์ฟเวอร์จะต้องติดตั้งบนเครื่อง Windows และทำให้ต้องใช้ SQL Server เช่น SourceGear Vaultและ Microsoft Server มูลฐานทีม

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

   1. จำกัด เฉพาะชุดย่อยของแพลตฟอร์มที่มีฐานข้อมูลเฉพาะอยู่
   2. กำหนดเป้าหมายแบ็กเอนด์ฐานข้อมูลเดียวที่เป็นข้ามแพลตฟอร์ม (เช่น SQLite)
   3. กำหนดเป้าหมายแบ็กเอนด์หน่วยเก็บข้อมูลแบบเสียบได้เพื่อให้สามารถใช้ฐานข้อมูลใดก็ได้ที่พวกเขาต้องการ (อาจรวมถึงระบบไฟล์)

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

เท่าที่ฉันเห็นในข้อเสนอหลาย ๆ อย่างดูเหมือนว่าไฟล์นั้น "ดีพอ" สำหรับงานบางอย่างที่เหมาะสมโดยคำนึงถึงว่าในตอนท้ายของวันที่เอาต์พุตของ VCSes ก็เป็นไฟล์เช่นกัน

มีหลาย บริษัท ที่เสนอ RDBMS แบ็คเอนด์ด้วยอินเตอร์เฟส svn / git / etc ดังนั้นสิ่งที่คุณต้องการโดยทั่วไปก็มีอยู่แล้ว

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

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

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

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

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

• การกู้คืนความเสียหายที่ดีกว่า (สถานการณ์กรณีที่เลวร้ายที่สุด: เราจะแยกวิเคราะห์ด้วยตาเหมือนในอดีต)

• การติดตามและแก้ไขข้อบกพร่องดังกล่าวอาจเกิดจากความผิดพลาดในระบบ VCS ได้ง่ายขึ้น

• ลดจำนวนการอ้างอิง (ให้ไม่ลืมหนึ่งในระบบที่มีการจัดการเคอร์เนลและอื่น ๆ ที่ควรจะ)

• เครื่องมือแก้ไขข้อความพร้อมใช้งานเสมอ (ใบอนุญาต MS SQL Server ... ไม่มาก)

ฟอสซิลเป็นระบบควบคุมเวอร์ชันแจกจ่ายที่ยอดเยี่ยม (DVCS) และใช้ SQLite สำหรับการจัดเก็บไม่มีไฟล์ข้อความธรรมดา

ฉันชอบที่มันรวมเข้าด้วยกัน: การติดตามบั๊กวิกิและการกระจายตัวจริงๆ ฉันหมายความว่าคุณสามารถทำงานออฟไลน์และแก้ไขข้อบกพร่องได้

Fossil ใช้ Sqlite เป็นรูปแบบไฟล์แอปพลิเคชัน ในคำปราศรัยที่ PgConดร. Richard Hipp อธิบายถึงข้อดีของการใช้ sqlite เป็น Application File System และสร้างข้อโต้แย้งที่น่าเชื่อถือเกี่ยวกับประโยชน์ของการใช้ฐานข้อมูลเป็นระบบไฟล์

หัวข้อหลักที่สองคือ SQLite ควรถูกมองว่าเป็นรูปแบบไฟล์แอปพลิเคชัน - ทางเลือกในการประดิษฐ์รูปแบบไฟล์ของตัวเองหรือใช้ ZIPped XML คำสั่ง“ SQLite ไม่ใช่การแทนที่ PostgreSQL SQLite นั้นใช้แทน fopen ()” nails ที่ (slide 21) ในที่สุดริชาร์ดให้ความสำคัญอย่างมากกับความจริงที่ว่า SQLite จะดูแลข้อมูลของคุณ (ปลอดภัยแฮ็ค , กรด) ใช้งาน-index.com

ตอนนี้Dr. Hippได้แก้ไขข้อกังวลเกี่ยวกับการบันทึกรหัสบนฐานข้อมูล

• ทำไมฟอสซิลอ้างอิงจาก SQLite แทนที่จะเป็นฐานข้อมูล NoSQL แบบกระจาย?

ฟอสซิลไม่ได้ขึ้นอยู่กับ SQLite การใช้งานปัจจุบันของ Fossil ใช้ SQLite เป็นร้านค้าในพื้นที่สำหรับเนื้อหาของฐานข้อมูลแบบกระจายและเป็นแคชสำหรับ meta-information เกี่ยวกับฐานข้อมูลแบบกระจายที่มีการคำนวณล่วงหน้าเพื่อการนำเสนอที่รวดเร็วและง่ายดาย แต่การใช้ SQLite ในบทบาทนี้เป็นรายละเอียดการนำไปใช้และไม่ได้เป็นพื้นฐานของการออกแบบ Fossil รุ่นอนาคตบางเวอร์ชั่นอาจใช้ SQLite แทนและแทนที่กองไฟล์หรือฐานข้อมูลคีย์ / ค่าแทนที่ SQLite (ที่จริงแล้วมันไม่น่าเป็นไปได้มากที่จะเกิดขึ้นเนื่องจาก SQLite ทำงานได้ดีในบทบาทปัจจุบัน แต่ประเด็นก็คือการละเว้น SQLite จากฟอสซิลเป็นความเป็นไปได้ทางทฤษฎี)