CMS vs Dosyasistemi depolama id ölçeklenebilirlik

3 Cevap php

Aşağıdaki dikkate alınız:

Ben 40 KB boyutunda 120 KB arasında değişen yaklaşık 1,2 Milyon TIF dosyalarını depolamak.

Bu belgeler NTFS dosya sistemine sahip bir windows sunucu üzerinde saklanır.

Belgeler aşağıdaki değişkenleri kullanarak saklanır:

  • client
  • document type
  • image folder
  • actual image

Aşağıya bakın:

C:\<client_id>\<doc_type_id>\image001\1.TIF

Example

C:\1\3\image001\1.TiF

Bu bir PHP barındırılan sistemidir.

Performans Bu aşamada kabul edilebilir. Ben iyi strateji ileriye neler olduğunu bilmek istiyorum. Müşteriler ve belge tutarları önemli ölçüde artırmak için gidiyoruz düşünüyor.

I Jackrabbit CMS ile komple depolama yerine bakıyorum.

Bu şekilde olacaktır? Veya

Gibi bir formatta belgeleri saklamak mı:

  • Customer
  • Document type
  • Julian date day of the year document imported.
  • Current User
  • 6 digit unique code

Example

C:\1\1\167\2\453257\image001\image.TIF

gibi verimli olacak?

Resmin Dosya sistemi vs CMS tüm diğer hususlar alınız. örneğin sürüm, veri yedekleme.

Teşekkürler.

3 Cevap

İşletme soru this one çok benzer. Yükleme öncelikle görüntüleri okuma veya yazma mı? Ihtiyacınız ölçeklenebilirlik okumak eğer, sonrası muhtemelen ihtiyacınız olan memcached açıklar. jackrabbit yükler daha fazla özellik var, ama hiyerarşik bir metin depolama için daha fazladır. Bu görüntülerde bilge daha iyi bir performans yapacak emin değil. Eğer Jackrabbit tercih yaparsanız Ayrıca, içerik hiyerarşi verimli kalmak jackrabbit için yeterince derin olduğundan emin olun. 10.000 ya da daha fazla çocuğu olan herhangi bir ebeveyn alt-par performansı sahip oluyor.

Gerçekten mi? Eğer belirli bir boyutu elde edene kadar ben (ve ben yapamam bana hayatı, remember o boyut için ...) o matters sanmıyorum. Şey bir yöntem bulmak ve daha sonra sopa ile, umarım siz tekrar dokunmaya gerek asla böyle bir şekilde olacak olmaktır. Benim kendi tavsiyem, bunu desteklemek için delil olarak inandırıcı bir şey olmadan, kendi öneri benzer bir şeydir:

c:\<customer_id>\<document_year>\<document_month>\<document_day>\actual_file.tif

Ben de sunucu kurulumu bağlı olarak, (veri veya hesap türü miktarına bağlı olarak) kendi sürücü / bölüm her müşteri vererek değer olabilir, bu öneriyi yükseltmek istiyorum.

Unutmayın ki, (zaten bu bilmiyordum sanki özür dilerim, biliyorum ...) kullanıcı-kontrol veya izinleri sistemi çeşit olmadan, bu dosya yolları tahmin edilebileceği tahmin ve göz olabilir. Eğer 'altı haneli benzersiz kod' bir kurşun noktasını yükseltti gerçeği yaygın formatında bir yol gerekmez, ama sonunda ortak bir format (of {[) (0]} formatı öneririm düşündürmektedir kadar) seçerek daha iyi bir fikir olacaktır.

Geri ben dosyanın birincil ilişki etrafında kendi dizinleri kriteri benim Windows gün, bu (c:\documents and settings\university\year1\module21\assignment1.doc, örneğin) günümüzde bir 'etiketi' olarak kabul ediyorum, bu daha kolay, daha sonra bir şeyler bulmak için yaptı. Müşterilerinizin dizin yapısı zorla-by var görünüyor size ama sadece date çapraz varsa onlar geçen hafta yaptığı şeyler bulma geçen hafta bir şey koymak nerede almak zaman hatırlayarak, daha kolay Altı haneli benzersiz numara adında klasörler, iyi, zor olacak. En iyi.

Farklı makineler (SAN / NAS) için içerik taşımak niyetinde eğer önerilen depolama stratejisi ele alınması gerekir. Bunu yapmak için, yolundaki tüm müşteri verilerini şerit gerekiyor ve sadece o zaman erişen dosyaya bağlanmak için veritabanına kaydetmek bir karma yaratacak. Eğer böyle bir klasör yapısı bir şey kalır Bu şekilde:

NAS1/00/01/86/63/54/89/image01/image.tiff
NAS2/00/02/46/62/22/11/image02/image.tiff
...

Ben de size MogileFS bir göz atmak öneriyoruz. Bunu hızlandırmak için yapmanız gereken onun önünde bir vekil çeşit eklemek için ve tüm iyi olması gerektiğidir.

Ve Dave belirtildiği gibi, tek bir klasörde çok sayıda çocuk yok emin olun. Yapılacak 10,000 çevresinde oldukça halsiz almak eğilimindedir.

etiketler