Neden kuyruk gibi veritabanı bu kadar kötü? [kapalı]


33

Bu yazıyı okudum ve kafam karıştı.

Her ikisi de aynı veritabanını paylaşan 1 webapp ve "işçi" olarak çalışan 1 farklı uygulama düşünelim .

Oh, "paylaşım" dedim .. ama makale ne hakkında uyarıyor? :

Dördüncü olarak, uygulamalar (veya hizmetler) arasında veri tabanı paylaşmak kötü bir şeydir. Amorf bir paylaşılan durumu oraya koymak çok cazip ve bilmeden önce çok büyük bir canavara sahip olacaksınız.

=> katılmıyorum. Farklı uygulamaların hala aynı birimin bir parçası olduğu bazı durumlar vardır ve bu nedenle “eşleştirme konusu” kavramı bu durumda bir anlam ifade etmemektedir.

Devam edelim: webapp, istemci HTTP isteklerini yerine getirir ve herhangi bir zamanda, bazı etki alanlarını (DDD terimi) güncelleyerek ilgili etki alanı olaylarını oluşturabilir.
İşçinin amacı, gerekli işleri işleyerek bu etki alanı olaylarını ele almaktır.

Önemli olan:

Olay verileri işçiye nasıl iletilmelidir?

Okunan makalenin teşvik ettiği ilk çözüm, RabbitMQ'yu kullanmak, mesajlara yönelik harika bir yazılım aracı kullanmak olacak.

İş akışı basit olurdu:

Ne zaman web dyno bir etkinlik yaratırsa, çalışanı besleyen RabbitMQ aracılığıyla yayınlar.
Dezavantajı, hiçbir şeyin toplam güncelleme taahhüdü ile olayın yayınlanması arasındaki olası tutarlı gönderim hataları veya donanım sorunları ile uğraşmadan gerçekleşen tutarlılığı garanti edemeyeceği ; bu başka bir ana konudur.

Örnek: Toplu güncellemenin başarısı olmadan bir etkinliğin yayınlanması ... alan modelinin yanlış temsilini temsil eden bir olayla sonuçlanabilir.
Küresel XA'nın (iki aşamalı taahhüt) var olduğunu iddia edebilirsiniz, ancak bu tüm veritabanlarına veya orta ölçekli araçlara uygun bir çözüm değildir.

Öyleyse bu acil tutarlılığı sağlamak için iyi bir çözüm ne olabilir? :
Etkinliği, veritabanında, toplam güncelleştirme ile aynı yerel işlemde depolayan IMO.
Basit bir asenkronize zamanlayıcı oluşturulacak ve mevcut yayınlanmamış olayların veritabanından sorgulanmasından sorumlu olacak ve bunları çalışanı dolduracak olan RabbitMQ'ya gönderecekti.

Fakat neden webapp tarafında ve bu arada fazladan bir programlayıcıya ihtiyaç duyuyor: neden bu durumda RabbitMQ'a ihtiyaç duyuyor?

Bu çözümle, mantıksal olarak görünür ki, RabbitMQ, özellikle veritabanı paylaşıldığı için gereksiz olabilir.
Aslında, durum ne olursa olsun, derhal tutarlılığın veritabanından yapılan bir oylamayı içerdiğini gördük .
Öyleyse, neden bu anketten doğrudan işçi sorumlu olmayacak?

Bu nedenle, neden web'deki bu kadar çok makalenin, mesaj odaklı katman yazılımını tanıtırken veritabanı sıralamasını zor eleştirdiğini merak ediyorum.

Makalenin alıntı:

Basit, iş için doğru aracı kullanın: bu senaryo bir mesajlaşma sistemi için ağlıyor. Yukarıda açıklanan tüm sorunları çözer; daha fazla yoklama, verimli mesaj teslimi, tamamlanmış mesajları kuyruklardan silmeye gerek yok ve paylaşılan durum yok.

Ve derhal tutarlılık yoksayıldı mı?

Özetlemek gerekirse, durum ne olursa olsun, paylaşılan veya paylaşılmayan veritabanı anlamında, veritabanında oylamaya ihtiyacımız var gibi görünüyor .

Bazı kritik kavramları özledim mi?

Teşekkürler


2
Yoklama bir çeşit kırmızı ringa balığıdır, çünkü büyük veritabanlarının neredeyse hepsinin, bazı işleri tablodan çıkarmak için zamanı geldiğini diğer bazı işlemleri asenkronize olarak bildirmek için bazı mekanizmaları vardır.
Blrfl

Yanıtlar:


28

Trafik yoğunluğu olan basit bir uygulama oluşturuyorsanız, başka bir bileşeni sisteminizden uzak tutmanın söylenmesi gereken bir şey var. Bir mesaj veri yolu kullanmamak sizin için doğru cevap olabilir. Ancak, sisteminizi bir veritabanı çözümü için veritabanı tabanlı kuyruk sistemini değiştirebilecek şekilde kurmanızı öneririm. Makaleye katılıyorum. Bir veritabanı sıra tabanlı sistem için doğru araç değildir, ancak sizin için yeterli olabilir.

RabbitMq gibi Sıra tabanlı sistem, orta dereceli donanımda büyük ölçekli etrafında inşa edilmiştir. Mimarileri, ACID uyumlu veritabanı sistemini yapıları gereği yavaşlatan işlemlerden kaçınarak bunu başarabilir . Bir mesaj veriyolunun sadece bir mesajın saklanmasını ve başarılı bir şekilde işlenmesini sağlaması gerektiğinden, işlem kayıtlarının kilitlenmesi ve yazılması ile uğraşması gerekmez. Bu kavramların her ikisi de bir ACID sistemi için kesinlikle gereklidir, ancak çoğu zaman çekişme nedenidir.

Performans açısından aşağı gelir: bir SQL tablonuz var. Bir sürü okur ve bir sürü yazar. Her ikisi de satırları, sayfaları ve dizinleri güncellemek için bir çeşit kilitleme gerektirir. Yoklama mekanizmanız, üzerinde arama yapmak için sürekli olarak bir dizini kilitliyor. Bu, yazmaların gerçekleşmesini önler; en iyi durumda sıraya alınmışlardır. İşlemi yapan kod da, kuyruktaki durumu tamamladıklarında veya başarısız olduklarında güncellemek için kilitlenir. Evet, bunun işe yaraması için optimizasyondan sonra sorgu optimizasyonu yapabilir veya özellikle sorduğunuz iş yükü için tasarlanmış bir sistem kullanabilirsiniz. Bir RabbitMq, bu tür bir iş yükünü bile terletmeden yiyor; Bunun da ötesinde, veritabanınızı iş yükünden kurtarıp başka şeyleri yapmak için daha fazla yer açabilirsiniz.

Dikkate alınması gereken başka bir şey, çoğu kuyruk sisteminin tipik olarak bir sorgulama tekniği kullanmamasıdır (bazıları HTTP için izin verir, ancak alıcı taraf için kullanmaktan kaçının). RabbitMQ özellikle gibi mesaj otobüsler için tasarlanmış ağ protokolleri kullanan AMPQ .

Düzenleme: Kullanım durumu ekleme.

Rabbit'i kullanmamın yolu, yoğun bir şekilde kullanılan bir veritabanı tablosu gerektiren bir değişikliği kabul eden bir API uç noktaya sahip olmamdır. Bu tablo sürekli olarak tartışmalıdır ve zaman zaman API'den zamanında bir değişiklik yapamaz. Bunun yerine, değişiklik isteğini bir kuyruğa yazıp ardından bu mesajları mümkün olduğu kadar işleyen bir hizmetim var. Veritabanı çekişmesi olursa, sıra basit bir şekilde büyür ve mesaj işleme gecikir. Tipik olarak işleme süresi 14ms aralığındadır, ancak yüksek çekişme sürelerinde 2-3 saniyeye ulaşırız.


Bu durumda aciliyeti nasıl kaldırabilirsin? Yayınlama ancak hemen sonra yapılırsa, etki alanı modeli geri alma işlemlerini güncellemekten sorumlu olan işlem ... Orta katman yazılımı tamamen habersiz olur ve etkinliği işlerdi.
Mik378

Sen yazdın: "kilitleme ile uğraşmasına gerek yok". Ancak, yönlendirilmiş olayların (işçiye yönelik) artan zamandaki sırasını (işçiye doğru) sağlamak için kesinlikle bir tür kilitleme vardır, değil mi?
Mik378

Mik378 @ bu makaleye göz atın mesajı Idempotency . Evet, teknik olarak bazı tutarlılık vaatlerini yitirirsiniz, ancak bahse girerim uygulamanın çalışma süresi güvenilirliği açısından ne kazandığınızı bulacaksınız ve performans buna değer. Ayrıca, kayıpları oldukça acısız hale getirmek için mesajları işleme biçiminizi değiştirmek de oldukça kolaydır.
brianfeucht

2
Evet, siparişinizi garantilemek için kilitlemeye ihtiyacınız olacak. Bazı kuyruk sistemleri bunu performans fiyatına sağlayabilir. İşlemlerin bazen sıra dışı olacağı gerçeğini kabul edebilir ve işlemciyi işlemcide kullanmanın bir yolunu bulabilirseniz, katlanarak bir performans açısından bakabilirsiniz.
brianfeucht

1
@ Mik378 - Cevabımı bir kullanım davası ekledi. Umut ediyorum bu yardım eder!
brianfeucht
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.