Senaryom için en iyi veri deposu hangisidir?

Ben veritabanında güncelleme / seçme sorguları çok yüksek yürütme içeren bir uygulama üzerinde çalışıyorum.

Bir varlık için bir gün için yaklaşık 500 kayıtları olacak bir temel tablo (A) var. Ve sistemdeki her kullanıcı için, kullanıcının bazı tercihlerine göre bu varlığın bir varyasyonu oluşturulur ve bunlar başka bir tabloda (B) saklanır. Bu, her gün gece yarısı çalışan bir cron işi tarafından yapılır.

Dolayısıyla A tablosunda 10.000 kullanıcı ve 500 kayıt varsa, o gün için B tablosunda 5M kayıtları olacaktır. Bu tablolarda her zaman bir gün için veri saklıyorum ve gece yarısı HBase'ye geçmiş verilerini arşivliyorum. Bu kurulum iyi çalışıyor ve şu ana kadar performans sorunlarım yok.

Son zamanlarda iş gereksinimlerinde bazı değişiklikler oldu ve şimdi temel tablo A'daki bazı özellikler (15-20 kayıt için) her 20 saniyede bir değişecek ve buna bağlı olarak tablo B'deki tüm bu varyasyon kayıtları için bazı değerleri yeniden hesaplamam gerekiyor. tüm kullanıcılar. Sadece 20 ana kayıt değişse de, yeniden hesaplama yapmam ve 20 saniyeden uzun süren 200.000 kullanıcı kaydını güncellemem gerekiyor ve bir sonraki güncelleme sonunda tüm Seçme sorgularının sıraya girmesine neden oluyor. Çevrimiçi kullanıcılardan yaklaşık 3 alma isteği / 5 saniye alıyorum. Bir API isteğine yanıt vermek için her zaman tablo B'deki alanları kullanırım.

Daha fazla işlem gücü satın alabilir ve bu durumu çözebilirim, ancak bir milyon kullanıcıyı bile işleyebilecek doğru ölçeklendirilmiş bir sisteme sahip olmakla ilgileniyorum.

Buradaki herhangi biri daha iyi bir alternatif önerebilir mi? Nosql + ilişkisel veritabanı bana burada yardımcı oluyor mu? Verileri kilitlemeden sık sık güncellememe ve aynı zamanda bir varlıktaki çeşitli alanlarda seçili sorgular yürütme esnekliği sağlayan platformlar / veri depoları var mı?

Tablo Bbir tür önbellek gibi görünüyor . Ancak verimliliği düşüren bu tür bir önbellek.

Saniyede 25 sorgunuz olsa bile , tablonun kullanımını reddedebilirB ve her istek için cevabı hesaplayabilirsiniz.

Her neyse , 20 kaydı güncellemede 30 saniyelik gecikme varsa - bir yazılım mimarisinde başarısızlıktır (DB'niz her kayıt için ilk 10 ^ 100 PI belirtisini hesaplarsa yanılıyorum).

Bildiğim gibi, çirkin SQL sorguları, dizinler ve 1000 000'den az kayıt ile ilişkisel DB neredeyse tüm sorgular için mükemmel çalışacaktır.

Tablo kullanımını reddetmeye çalışın ve tablonuza Buygun dizinler ekleyin A(çoğu modern veritabanında yardımcı bir araç vardır). Daha sonra: Ahesaplamayı hızlandırmak için veri yapısını (tablo ) ve bir sorguyu (sorgu analizörü kullanarak veya SQL uzmanlarıyla) optimize etmeye çalışın . Eğer olacaksa güncelleme sadece 20 kayıtları - endeksler varlığı üretkenliğini zarar vermeyecek güncelleme işleminin, ancak önemli ölçüde artırır seçme hız.

Asıl soru, sistemin B'ye eklemek için kaydı ne kadar hesapladığı ve B verilerinin boyutu.

Herhangi bir veritabanı (örn. MSSQL), nesnenin çok büyük olmadığı varsayılarak, sorundan bahsettiğiniz eklerin hacmini işleyebilmelidir.

Güncellemeler daha zor bir sorun olabilir, ancak doğru indeksleme ve kilitleme ile tekrar büyük bir sorun olmamalıdır.

Böyle bir sorun gördüğümde% 99'u, B kaydının depolanmış bir proc tarafından hesaplanması nedeniyle. Bu, tüm yükü db sunucusuna koyar

Bu durumda çözüm, bu kodu kuyruk sistemi aracılığıyla çağrılabilen bir çevrimdışı hizmete taşımaktır.

Bu nedenle güncellemeniz Bir mesaj, kullanıcılar arasında döngü oluşturacak ve her kullanıcı için bir güncelleme B mesajı oluşturacak bir çalışan işlemi tetikler

İkinci bir alt işlem B, güncelleştirme X kullanıcısını veriyle toplar. Bir olay B kaydını oluşturur ve DB'yi günceller

Bu, kuyruk çalışanları ile daha fazla kutu ekleyerek ölçeklenebilir, böylece hesaplama arkasında daha fazla işlem gücüne sahip olursunuz, db'nizi güncellemeler ve seçimlere konsantre olmak için serbest bırakırsınız.

seçimleri güncelleme / eklerden ayırarak daha da optimize edebilirsiniz. tüm güncelleştirmeleri çoğaltma köle olarak alır yeni bir DB var tüm güncelleştirmeleri alır eski DB.

Amazon'da koşuyorsanız DynamoDB'yi düşünürdüm. Flash bellek tabanlı. İşte bir bağlantı: https://aws.amazon.com/dynamodb/ .

Ne tür RDBMS kullanıyorsunuz? Bir görünümde bir UDF veya hesaplanmış bir alan kullanarak performansı artırabilirsiniz. Hesaplamayı tek bir güncelleştirme sorgusu aracılığıyla veritabanında mı çalıştırıyorsunuz, yoksa verileri veritabanından mı seçiyorsunuz, hesaplamaları başka bir işlemde mi çalıştırıyorsunuz ve geri yüklüyor musunuz?

Oracle varsayılan olarak anlık görüntü modu yürütme kullanacak şekilde yapılandırılmıştır, yani güncelleme sırasında satırlar kilitlenmez ve eşzamanlı seçimler orijinal değeri alır. SQL Server varsayılan olarak kötümser eşzamanlılık ile yapılandırıldığından, eşzamanlı seçimler güncelleme tamamlanana kadar engellenir. SQL Server'ın bazı sürümleri anlık görüntü moduna alınabilir, ancak geçici tablodaki stresi büyük ölçüde artırır.

Ne tür bir ortamda koşuyorsunuz? Amazon'daki bir EC2 örneğindeki RDBMS ise, DB veri dosyalarını yerel flash diske yerleştirmeyi deneyin. Dosyaları yerel diske EBS'den taşımada bir büyüklük farkı sırası gördüm.