Soru Ölçeklenebilir (yarım milyon dosya) sürüm kontrol sistemi


Kaynak kodu revizyon kontrolümüz için SVN kullanıyoruz ve kaynak kodlu olmayan dosyalar için kullanmayı deniyoruz.

Düzenli olarak güncellenecek ve versiyon kontrolüne ihtiyaç duyan büyük set (300-500k) kısa (1-4kB) metin dosyaları ile çalışıyoruz. SVN'yi düz dosya modunda kullanmayı denedik ve ilk işi (kontrol edilen 500 bin dosya) yaklaşık 36 saat sürecek şekilde ele almaya çalışıyor.

Günlük olarak, taahhüt işlemi başına 10k değiştirilmiş dosyaları kısa sürede (<5 dk) idare edebilmek için sisteme ihtiyacımız var.

Sorularım:

  1. SVN, amacım için doğru çözümdür. İlk kullanım hızı pratik kullanım için çok yavaş görünüyor.
  2. Evet ise, hızlı bir özel svn sunucu uygulaması var mı? (Şu anda gnu / linux varsayılan svn sunucusu ve komut satırı istemcisini kullanıyoruz.)
  3. Hayır ise, en iyi f / oss / ticari alternatifler nelerdir?

Teşekkürler


1'i düzenle: Birden çok kişi aynı dosyaları değiştirecek ve programcıların kaynak kodunu düzenledikleri gibi manuel farklılıklar / birleştirme / çözme-çakışmalar yapacağı için sürüm kontrolüne ihtiyacım var. Böylece, insanların işlerini kontrol edebilecekleri ve başkalarının işe yaramadıklarını kontrol edebilecekleri merkezi bir depoya ihtiyacım var. İş akışı, kullanıcıların programcı olmadıkları ve dosya içeriğinin kaynak kod olmadığı durumlar dışında bir programlama iş akışına hemen hemen aynıdır.


1. Güncelleme: Birincil sorunun, bir SVN sorunundan ziyade bir dosya sistemi sorunu olduğunu ortaya çıkarır. SVN için yarım milyon ile tek bir dizin yeni dosyalar 24 saat sonra bile bitmedi. Klasör başına 1000 dosya içeren 1x5x10x10 ağacında düzenlenmiş 500 klasöre aynı şekilde bölünmesi, 70 dakikalık bir işlem süresiyle sonuçlandı. Commit hızı, çok sayıda dosya içeren tek klasör için zamanla önemli ölçüde düşer. Git çok daha hızlı görünüyor. Zamanları ile günceller.


18
2018-03-31 17:55


Menşei


Yaptığını düşündüğüm şeyi yapıyorsan, bir çeşit CMS'ye bakarım. - erikkallen
Diğerleri de belirttiği gibi: genel olarak çözmeyi denediğiniz şeyi bir sürüm kontrol sistemi olarak açıklamaya değer olabilir. belki Sorununuz için yanlış (en azından en verimli değil) çözüm. - paprika
Wikipedia'yi mi yansıtıyorsun? - hasen
Dosyalarınız nasıl yapılandırılıyor? Birçok dosya sistemi, çok sayıda dosya ile dizinleri ele alır - nos
Bu aklımı uçuruyor. İnsanlar her gün 10.000 dosyayı elle değiştirebilir mi? Her birinin elle çözülmesi ve birleştirilmesi gerekiyor? Her dosya 4 kB'a kadar çıkabilir mi? Vay. - Richard Morgan


Cevaplar:


SVN uygun mu? Deponun tamamını kontrol etmediğiniz veya güncellemediğiniz sürece, o zaman evet.

SVN, çok fazla sayıda dosya (özellikle Windows'ta) işlemek oldukça kötüyse, tüm bu .svn dizinleri sistem üzerinde çalışırken bir kilidi güncellemek için yazılmıştır. Eğer az sayıda diziniz varsa, fark etmezsiniz, ancak alınan zaman katlanarak artar.

Ancak, bir kez işlendikten sonra (diziler, dizin dizini) belki de işler çok daha hızlı olur. Güncellemeler çok uzun sürmez ve depo bölümleri üzerinde çalışmak için seyrek ödeme özelliğini (çok tavsiye edilir) kullanabilirsiniz. Binlerce dosyayı değiştirmenize gerek olmadığını varsayarsak, oldukça iyi çalışır.

10.000 dosyayı birleştirmek - yine aynı anda, her şey hızlı olmayacak, ancak günde 1000 kez dosya sayısı çok daha kolay yönetilecek.

Oradaki tüm dosyaları bulduktan sonra nasıl çalıştığını görün ve nasıl çalıştığını görün. Tüm bunlar çalışma klasörü mekanizması .svn dizinlerini kaldırmak için değiştirildiğinden (bu sayede kilitlerin daha basit ve çok daha hızlı tutulması) 1.7'de çözülecektir.


6
2018-03-31 20:08



Gerçekten çok sayıda dosya değil, performansı en fazla etkileyen çok sayıda dizin var. - Sander Rijken
@gbjbaanb @Sander Tek bir klasörde çok fazla dosya sorun gibi görünüyor. Lütfen Güncelleme 1'e bakın. - hashable
.Svn dizinlerinden kaynaklanan @gbjbaanb tarafından açıklanan yavaşlamalara başvurmaktaydım. Bu yavaşlama, birçok dosyaya sahip olmakla değil, pek çok dizine sahip olmasından kaynaklanır. Çalışmadan önce çalışma kopyasının kilitlenmesi ve daha sonra dizinlerin açılması çok fazla zaman alır. - Sander Rijken
1 dizinde çok fazla dosya var ... virüs denetleyicisi kapalıyken zamanlamanızı deneyin. Dosya başına işlediğinizde bu .svn dizininin güncellenmesi gerekir. İyi değil. Ayrıca, zamanlamalarınızla birlikte svn dev e-posta listesine gönderin - orada biraz yardım alabilirsiniz ya da en azından neler olup bittiğini görmek için birinden yardım isteyebilirsiniz. - gbjbaanb


Temmuz 2008 itibariyle, Linux kernel git repo yaklaşık 260.000 dosya vardı. (2.6.26)

http://linuxator.wordpress.com/2008/07/22/5-things-you-didnt-know-about-linux-kernel-code-metrics/

Bu sayıda dosyada, çekirdek geliştiriciler hala git gerçekten hızlı olduğunu söylüyorlar. 500.000 dosyada neden daha yavaş olacağını anlamıyorum. Git, dosyaları değil dosyaları izler.


13
2018-03-31 18:07



Bunu tekrar teyit etmek için: Büyük bir deponun tüm içeriğini (26000 dosya, 5GB) yeniden yazmış olan bir işlemi test ettim. O kadar hızlı olmayan bir ağ montajı üzerinden çoğunlukla I / O-sınırlı olan yaklaşık 6 dakika sürdü. Kullanım durumunuzda, diffs daha 50MB gibi, bu yüzden daha hızlı işlem süreleri görmelisiniz. (İlk işleminiz bir süre alabilir - sisteminize bağlı olarak beş dakika ila bir saat arasında bir tahmin.) - Cascabel
Farkında olmak. Git, programcılar için dik bir öğrenme eğrisine sahiptir ve kodlayıcı olmayanlara karşı şaşırtıcı olabilir. Şimdi git'i her zaman kullanıyorum ve onsuz çalışamadım, ama rahat etmem birkaç ay sürdü. Gitmek istemiyorsanız, programcı olmayan meslektaşlarınızı eğitmek için birkaç saat batmaya hazır olduğunuzdan emin olun. - AndyL
@Andy Git'in öğrenme eğrisi hakkında bu değerli yorum için teşekkürler. - hashable
Linux-kernel-metrics-link'e baktığımda, sadece 26.000 dosya var (260,000 yerine). - Sonson


Böyle kısa dosyalar için bir dosya sistemi yerine bir veritabanı kullanmayı kontrol ettim.


5
2018-03-31 18:39





Git en iyi bahistir. Tüm bir işletim sisteminde (birkaç yüz bin dosyada iki gigabaytlık kod) kontrol edebilirsiniz ve ilk kontrolün yaklaşık 40 dakika gibi bir süre geçmesine rağmen kullanılabilir durumdadır.


3
2018-03-31 18:09



sadece 40 dakika mı? Vaov! - Lucas B
Sistemin hızlı diski var, evet. SSD'nin revizyon kontrol sistemlerinin en yüksek hızına çıkmanın yolu olacağını düşünüyorum. - Andrew McGregor
Bu bahşiş için teşekkürler. Evet. Bir SSD'yi SVN sunucusu olarak kullanmak HDD'yi hızlandıracaktır. - hashable
@hashable: Bunu araştırmak zorundasın. İstemcideki harddisk'in SVN kullanırken sunucudakilerden daha kritik olduğunu düşünüyorum. - Sander Rijken
İstemci de müşteri ile daha kritik olur. - Andrew McGregor


  1. FSFS anlamında svn "düz dosya modu" için:

    • En son svn'yi çalıştırdığınızdan emin olun. FSFS, 500k dosyalarında gece / gündüz farkı olacak şekilde ~ 1.5 IIRC'ye eklenmişti. Çalıştığınız belirli dosya sistemi de büyük bir etkiye sahip olacaktır. (Bunu NTFS'de bile düşünme.)
    • Pek çok dosya işlemiyle IO-bağlı olacaksın. SVN, gerçek dosyaların yanı sıra .svn dosyasındaki dosyaları kaydetmesiyle çok verimli değildir.
  2. git svn'den daha iyi bir performansa sahiptir ve en azından karşılaştırmak için kendinize borçlusunuz


3
2018-03-31 18:13



@Nathan Evet. SVN'nin 1.6.x versiyonunu kullandığımıza inanıyorum. - hashable
ve dosya sayısı ile, svn 1.7 çok sayıda dosya ile önemli bir etkiye sahip olan .svn dizinlerini kazıyarak çok daha iyi bir desteği olacaktır. Tabii ki, bu henüz yok. - gbjbaanb
Çok sayıda revizyonunuz olduğunda, parçalama size yardımcı olacaktır, dosya sayısı için herhangi bir şey geliştirmez. Depoda bulunan revizyonlar. - Sander Rijken
@Sander: Doğru, iyi nokta. Bireysel taahhütler olarak "düzenli olarak güncellenmeyi" hayal ediyordum sanırım, ama bu o kadar fazla dosya ile mümkün değil. Gerçek yavaşlama, istemci tarafıdır. - Nathan Kidd


Mercurial, hala kullanılabilirlik departmanında gitmesine yol açtığı için tavsiye ederim (git daha iyi oluyor, ama, eh).

bzr, kullanılabilirlikte de ileri sıçramalar yaptı.


3
2018-04-01 22:18





ZFS gibi ucuz enstantanelerle gerçekten bir dosya sistemine ihtiyacınız var mı? Dosya düzeyini her 5 dakikada bir kaydetmek için, birtakım değişiklik geçmişinden faydalanmak için bunu yapılandırabilirsiniz.


0
2018-03-31 18:21



Cevabınız bir soru gibi geliyor (yazım hatası). Her neyse, iyi işaretçi! - paprika
Sokratik yöntem denir ;-) ;-) - joeforker


İşlem başına 10k değiştirilmiş dosya işlemek için herhangi bir sebep var mı? Her kullanıcı kendi dosyasında hemen kontrol ederse, Subversion daha iyi ölçeklenebilirdi. Ardından, dosyaları bir günde "yayınlamanız" gerekir; bunları çok hızlı bir şekilde etiketleyebilir ve yayınlanan sürümü yayından çalıştırabilirsiniz.


0
2018-04-01 18:09



@Sander 10k üst sınırdır. Bir dosya arası bağımlılıklar nedeniyle bir kullanıcı sadece bir dosyada check-in yapamaz. - hashable
Bu işi el ile yaparak, tek bir işlem olması gereken 10k'a kadar dosya üretiyor mu demek istiyorsunuz? Dosyalar üretilmedikçe bu oldukça imkansızdır, bu durumda kaynak dosyaları kaynak kontrolde saklamak genellikle daha iyidir. - Sander Rijken
Manuel çalışma, dosya düzeyinde yapılmaz. Küçük düzenlemeler (toplu olarak tüm dosyalarda temsil edilen bilgiler için) birkaç dosyanın değiştirilmesine neden olabilir. Evet. 10000 dosya değişikliklerinin üst sınır durumu için, değişikliklerin programatik dosya değişikliği nedeniyle olması muhtemeldir. (Dosyaların hem insan hem de otomatik olarak düzenlenmesi vardır.) - hashable