Get.php ve / veya `core / file_storage_database` neden oluşturuldu?

Sürüm 1.5 veya 1.6'dan beri, Magento'nun kök klasöründe bir dosya vardı get.php. core/file_storage_dataModeli kullanan bu dosya, Magento sistem sahiplerinin ürün medya dosyalarını , dosya sisteminde bir görüntü dosyası olmadan doğrudan veritabanındaki blob sütunlarından sunmalarına izin verir . PHP dosya gönderme kolları

#File: get.php
function sendFile($file)
{
    if (file_exists($file) || is_readable($file)) {
        $transfer = new Varien_File_Transfer_Adapter_Http();
        $transfer->send($file);
        exit;
    }
}

Bu Magento tarih alanına giriyor, ancak bu özellik neden geliştirildi? Görünüşe göre - biraz deli. PHP bir dosyaya hizmet etmenin en etkili yolu değildir, MySQL'in blob depolama alanı kararsız olma geçmişine sahiptir ve kararlı bir veritabanı blob uygulaması bile çalışmak için arka planda bir acıdır ve görebildiğim kadarıyla Varien_File_Transfer_Adapter_Httpeklemez herhangi bir önbellek başlığı bu dosyalara.

Magento'nun neden bu özelliği geliştirdiğini bilen var mı? Aslında çözmek için ortaya koyduğu hedefi / problemi gerçekleştiriyor mu? Kullanan var mı?

Aslında bu özellik için orijinal SRS'yi buldum ve tarihi amaçlar için burada paylaşabilirim:

Şu anda medyayı depolamak için başka bir seçenek yok, ancak web sunucusunun dosya sisteminde. Bu yaklaşım, sistemin çalışan yalnızca bir örneği olduğunda ve veritabanı sistem örneğiyle aynı sunucuda bulunduğunda yeterince iyidir.

Ancak, sistem dağıtımının en olası yolu aynı değildir. Müşteriler, senkronizasyon gerektiren farklı sunuculara dağıtılmış birden fazla sistem örneğine sahiptir. Bu nedenle, görüntüleri depolamak için iki farklı seçenek seçenek olarak geliştirilmelidir: Veritabanı ve CDN (İçerik Dağıtım Ağı).

Alternatif medya depolaması olarak CDN, sistemde belirli bir CDN (ler) ile tam entegrasyon olarak değil, yalnızca bir destek seçeneği olarak uygulanacaktır. Yönetici, CDN'nin kendisini seçmeli ve yapılandırmalı, ayrıca sistem yapılandırmasında küçük değişiklikler yapmalıdır.

Kullanım durumlarını yapıştırmayacağım ama CDN için sadece görüntüler / kaplamalar için Temel URL'leri CDN URL'sine değiştirmekten bahsediyor (PULL CDN gerektirdiğini varsayıyorum)

Onu kapsamlı bir şekilde test etmedim, üretimde kullanmadım, ancak Elastik Beanstalk + Magento kılavuzum için kullandım. Avantaj, paylaşımsız bir web düğümü kümesi içindir - görüntü dosyaları yönetici aracılığıyla yüklendiğinde DB arka ucunda saklanır ve daha sonra başlangıçta oradan (ve ideal olarak bundan sonra CDN'den) sunulur. Medya paylaşmak için NFS'den kaçınabileceğiniz anlamına gelir.

Sanırım burada kümelenme ortamları için tasarlanmış. 1 db düğümü olan çoklu web düğümleri. Oturumlar / önbellek de db (veya başka bir düğüm) içindeyse, web düğümünüz salt okunur olur ve yeni bir web düğümünü her açışınızda medyayı eşitlemeniz gerekmez.

Genel olarak, çözülmesi gereken bir sorun arayan mühendislik çözümüne benzediğini kabul ediyorum.

Bunu kişisel olarak Magento'da görmekten çok memnun kaldım, çünkü (diğerlerinin de belirttiği gibi), birden fazla web düğümü olan yığınların, NFS bağlarıyla uğraşmak zorunda kalmadan görüntülerin tek bir yetkili kaynağına sahip olmalarını sağlar.

Benim gibiyseniz ve yük dengeleyicisinin içine ve dışına web düğümlerini değiştirerek dağıtımları çalıştırırsanız (AWS Başlatma Yapılandırmaları / Otomatik Ölçeklendirme Grupları kullanmak gibi), bu oldukça aklı başındadır.

Genellikle görüntüleri çeşitli nedenlerle DB'ye koymaktan kaçınmak istersiniz, ancak bu işlemin (temelde) çalışma şekli, görüntünün DB'den yerel dosya sistemine çekilmesi ve daha sonra gelen istekler için oradan sunulmasıdır. .

Bir adım daha ileri gidebilirseniz (bu yüzden görüntüleri aşağı çekmek / dosya sisteminden referans almak için daha az istek vardır) CDN kullanmanızı ve web sitenizi başlangıç ​​noktası olarak ayarlamanızı ve medya URL'sini başkaları tarafından açıklandığı gibi değiştirmenizi tavsiye ederim.

Yan notta, çoğu MySQL yapılandırması DB'nize izin verilen veri aktarımının boyutunu sınırlayan çok düşük bir "max_allowed_packet" değerine sahip olacaktır. Görüntüleri DB'de saklamayı planlıyorsanız, kendinizi kontrol etmek için bunu kontrol etmek isteyebilirsiniz.