Düz dosyaları veritabanı / API'ye karşı bir ön uç ve arka uç arasında taşıma olarak kullanma

Birkaç geliştirici arasında oldukça sıcak bir tartışma yaratan bir uygulamam var.

Temel olarak, bir web katmanına ve bir arka uç katmanına ayrılır. Web katmanı, bilgileri basit bir web formuyla toplar, bu verileri bir JSON belgesi (kelimenin tam anlamıyla bir .json dosyası) olarak arka uç tarafından kullanılan bir izleme klasörüne saklar. Arka uç bu klasörü birkaç saniyede bir yoklar, dosyayı alır ve işlevlerini yerine getirir.

Dosyaların kendileri çok basittir (yani tüm dize verileri, yuvalama yok) ve en büyüklerinde yaklaşık 1-2k, sistem zamanının çoğunu boşta geçirir (ancak herhangi bir zamanda 100 mesaja kadar patlar). Arka uç işleme adımı mesaj başına yaklaşık 10 dakika sürer.

Argüman, bir geliştirici dosya sistemini mesajlaşma katmanı olarak kullanmanın kötü bir çözüm olduğunu öne sürdüğünde, ilişkisel veritabanı (MySQL), noSQL veritabanı (Redis) veya düz REST API çağrısı gibi bir şey kullanılması gerektiğinde ortaya çıkar.

Redis'in sıralı mesaj işleme için kuruluşun başka bir yerinde kullanıldığı unutulmamalıdır.

Duyduğum argümanlar aşağıdaki gibi çöktü

Düz dosyalar lehine:

• Düz dosyalar, diğer tüm çözümlerden daha güvenilirdir, çünkü dosya yalnızca "watch" klasöründen, alındıktan sonra "işleme" klasörüne ve son olarak da tamamlandığında "done" klasörüne taşınır. Zaten başka şeyleri kıracak çok düşük seviyeli hataların engellenmesi mesajlarının kaybolma riski yoktur.

• Düz dosyaları anlamak için daha az teknik karmaşıklık gerekir - sadece cat. Yazmak için sorgu yok, yanlışlıkla bir iletiyi kuyruktan atma ve sonsuza kadar gitme riski yok.

• Her dilin standart kitaplığının bir parçası olduğundan, dosya yönetimi kodu programlama açısından veritabanı API'lerinden daha basittir. Bu, kod tabanının genel karmaşıklığını ve getirilmesi gereken üçüncü taraf kod miktarını azaltır.

• YAGNI prensibi düz dosyalar şu anda sadece iyi çalıştığını devletler hiçbir böylece bırakın, daha karmaşık bir çözüme geçmeyi ihtiyacını orada gösterdi oluyor.

Bir veritabanı lehine:

• Veritabanını ölçeklemek, dosyalarla dolu bir dizinden daha kolaydır

• Düz dosyaların birisinin "tamamlandı" dosyasını tekrar "watch" dizinine kopyalaması riski vardır. Bu uygulamanın (sanal makine yönetimi) doğası gereği, bu felaket veri kaybına neden olabilir.

• T / S için daha fazla teknik karmaşıklık gerektiren uygulama, eğitimsiz personelin sadece şeylere atarak bir şeyi berbat etme olasılığının düşük olduğu anlamına gelir.

• DB bağlantı kodu, özellikle Redis gibi bir şey için, en azından standart kütüphane dosya yönetimi işlevleri kadar sağlamdır.

• DB bağlantı kodu, geliştiricinin bakış açısıyla gözle görülür şekilde (işlevsel değilse), dosya manipülasyonundan daha yüksek olduğundan.

Görebildiğim kadarıyla, her iki geliştiricinin de birçok geçerli puanı var.

Yani bu iki kişiden, dosya yanlısı ya da yan yana veritabanları yanlısı, hangisi yazılım mühendisliği en iyi uygulaması ile daha uyumludur ve neden?

Ewan tarafından belirtilen veritabanlarını veya kuyruk sistemlerini içeren bir çözüme geçmek

• hem arka uçta hem de ön uçta yeni, karmaşık bir sisteme bağımlılık yaratmak
• gereksiz karmaşıklık ve yeni başarısızlık noktaları
• maliyeti artır (sahip olma maliyeti dahil)

Dosyaları tek bir birimde taşımak / yeniden adlandırmak, dosya / kayıt kilitleme gibi şeylerle ilgili zorlukları ne olursa olsun, mevcut tüm işletim sistemlerinde atomik olacağı garanti edilir. İşletim sistemi düzeyinde hak yönetimi, yıkanmamışları kilitlemek ve yetkili operatörler (yöneticiler / geliştiriciler) tarafından düşüncesiz / kazara yanlış manipülasyonu önlemek için yeterli olmalıdır. Bu nedenle, mevcut çözümün performansı tıkalı olduğu sürece veritabanlarının sunacağı hiçbir şey yoktur.

Şirketimizde onlarca yıldır benzer dosya tabanlı arayüzleri büyük bir başarı ile kullandık. Birçok başka şey geldi ve gitti, ancak bu arayüzler tamamen basitliği, güvenilirliği ve minimum bağlanma / bağımlılıkları nedeniyle kaldı.

Her iki çözümün de kalıtsal olarak kötü bir uygulama olduğunu düşünmüyorum, bu yüzden en iyi uygulamanın cevaplanması zor olabilir.

Ölçekle uğraşıyorsanız YAGNI müdürünün burada geçerli olduğuna inanmıyorum. "Çalışma" görecelidir, eğer felaket veri kaybı için güçlü bir potansiyeliniz varsa ve ölçeklendirme yeteneğiniz azsa, bu çalışmayı gerçekten düşünmezdim. Bahsettiğiniz ölçeğin tam olarak emin değilim, ancak bu girişlerin büyük bir miktarına sahipseniz, yeni bir sisteme geçmek her biriyle zorlaşıyor. Bu durumda, bir veritabanının en iyi yöntem olduğunu söyleyebilirim.

MongoDB veya redis (redis ile ilgili hiçbir deneyimim yok, sadece iyi şeyleri okuyun) verilerinizin zaten iyi bir şekilde uyması gerektiği için iyi yapmalıdır (json belgeleri genellikle önemsiz bir şekilde MongoDB için BSON belgelerine değiştirilir). Diske sürekli olarak sık sık okuma / yazma yapmak yerine çok fazla veriyi bellekte tutmanın ek bir avantajı vardır. Aynı zamanda eşzamanlı okuma / yazma işlemlerinin bozulmaya veya engellenmeye yol açmamasını sağlar.

YAGNI müdürü burada geçerliyse ve dosyalar bir darboğaz değilse, kapsam içinde ölçeklenirler ve felaketle ilgili sorunlar olmazsa, dosyalara yapışmanın "en iyi uygulama" olduğunu söyleyebilirim. Sorun yoksa hiçbir şeyi değiştirmek için hiçbir neden yoktur, belki bazı testler yazın, vurgulayın ve sınırlarınızın ve darboğazlarınızın nerede olduğunu görün.

Bir veritabanı zaten bu bağlamda çözüm olup olmadığından emin değilim. Aynı sunucudaki şeylerle iletişim kuruyorsanız, bir tür IPC yapılabilir, değil mi?

Iyi 'ol bir dosyayı kaydetmek ve bitmiş bir dir kopyalamak iken birçok iletişim katmanları esp bir elyaf olduğunu. eski ana çerçeve sistemleri ve benzerleri ile. 'Karşıt' adamların bir anlamı var; birçok problemi ve uç vakası var. % 100 güvenilirliğe ihtiyacınız varsa uğraşmak zordur ve dosyaların sıklığını ve hacmini artırdığınızda daha sık görülür.

İşlemin her iki tarafını da kontrol ederseniz, mevcut birçok basit kuyruk sisteminden bazılarına bakmanızı öneririm. Veritabanı yerine ZeroMQ, RabbitMQ, MSMQ vb. Ama dediğin gibi, eğer kırılmazsa ...

Veritabanı çözümü doğru çözümdür. Belirli bir ana bilgisayara veya sınır koşullarına çok fazla bağımlılık çözer.

Veritabanının belirli bir ana bilgisayarda barındırılmaması dışında her ikisi de benzer çözümlerdir. Bu, unix sistemindeki güvenlik duvarı / erişim sorunlarından kurtulur. Dosya sistemlerinde "yanlışlıkla" silme vakalarımız oldu ve kimseyi suçlayamadık.

Veritabanı ile aynı sorunu yaşayabilirsiniz, ancak silmeden kurtulmak için denetim koyabilir veya yalnızca mantık ekleyebilirsiniz.

Ayrıca dosya sisteminde, örneğin OASIS dosya adına uygulama koymanız gerekiyorsa, OASIS.john_doe.system1.20160202 dosyaları oluşturmanız gerekir. Bu sıkıcı hale gelir ve veritabanında daha kolay temsil edilebilir. Buna dayanarak veritabanında ve mantıkta null alanlarınız bile olabilir

Ayrıca, tablolarda yapmak isteyebileceğiniz herhangi bir düzeltme eki veya düzeltme olması durumunda veritabanlarının tamamını bir dosya dizini olarak güncellemek de kolaydır. Tabii ki dosya sisteminde yapabilirsiniz, ancak veritabanı güncellemesi daha sezgiseldir.

Örneğin, tekrar çalıştırmak istiyorsunuz, ancak OASIS'ten farklı bir sistemle DESERT ve john_doe diyelim ki doe_smith ve 20160101'den 2015'e tarih

DESERT / doe_smith / 20151231 için kabuk kümesiyle bu dosyayı oluşturmak yerine orijinal kümeden satır oluşturmak kolaydır.

Dolayısıyla okunabilirlik açısından, uzantı bakış açısı veritabanı çözümü daha iyidir.