Yüksek Eşzamanlı Depolama Sistemi


12

İhtiyacınızın, her birinde 30 milyar satır (toplam 4 TB) boyutu olan 3 büyük tablonuzun (yapılandırılmış veriler) olduğunu ve eşzamanlı kullanıcılarınızın (uzak LAN makinelerinde paralel işletim sistemi iş parçacıkları olan) bir kısmının okunması gerekeceğini düşünün SELELCT WHERE GROUPBY sorguları ve son derece eşzamanlı veriler sayesinde, aynı anda 10.000 eşzamanlı okuma okuyor ve ayrıca kullanıcıların bu tablolara 2000 eşzamanlı yazar gibi çok eşzamanlı veri eklemesi (güncelleme yok) gerekiyor (tüm veri merkezi LAN ağı üzerinden) . Kullanıcılar, her okuma ve yazma işleminin gerçekleşeceği bu depolama biriminden mümkün olduğunca hızlı bir şekilde okumak ve eklemek isteyeceklerdir, ms ila 1 saniye aralığındadır.

Bu gereksinimi karşılamak için hangi teknolojileri öneriyorsunuz? Bunu yapabilen herhangi bir veri depolama veya anahtar / değer deposu var mı? Bulut bir seçenek DEĞİLDİR.

Bazı Açıklamalar:

Kullanıcıların verileri hemen görmesi GEREKMEZ ve nihai tutarlılık kabul edilebilir. Verilere, depolama biriminin sağlayabileceği sürücü aracılığıyla erişilir ve kullanıcılar yine yalnızca veri merkezinin uzak makinelerinde çalışan iş parçacıklarıdır. Sorgular çoğunlukla SELECT WHERE GROUPBY gibidir.

Veriler tablo biçimindedir ve her satır yaklaşık 60 bayttır.

DynamoDB veya benzeri çözümleri kullanamayacağım bulut seçeneği yok. Dahili olarak veri merkezinde barındırabilmeliyim.

Tabloların tüm verileri her zaman okunabilir ve kullanım şekli tahmin edilemez. Birleştirme veya süper uzun sorgu yok. DR gerekmez, ancak makul bir HA gereklidir, ancak fantezi olması gerekmez. Her okuyucu, kendi cümlesi ve satırlarının gerçekten ilişkili olmadığı yere göre bir dizi satır alır. Muhtemelen her satır için sabit bir uzunluğa sahip olabiliriz ama depolama katmanının bu konuda endişeleneceğini umuyorum.

Ayrıca, en büyük endişem, eşzamanlı okumalarla gerçekleşen tüm eşzamanlı yazmalardır.

Bu konudaki görüşleriniz büyük beğeni topluyor.

Dahası, bu tablolardan üçü var ve her 30 milyar satır farklı nesne türlerini tutuyor


bulutu tanımlayın, çünkü çoğu insanın söylediği gibi, genel nüfusun% 99'u ve pazarlama insanların% 100'ü bulut dediği, sadece başka birinin koruduğu bir kümedir .

DynamoDB'yi veya sadece amazon veya masmavi gibi genel bir bulutta bulunan bazı teknolojileri kullanamıyorum.
iCode

Yanıtlar:


6

Nihai tutarlılık kabul edilebilirse ve tüm sorgularınız birleştirilmişse, düşük gecikmeli bir OLAP sistemi sizin için işe yarayabilir. İhtiyacınız biraz algoritmik bir ticaret platformu gibi geliyor. Bu tür mimari genellikle güncel veriler üzerinde toplu istatistiksel analiz hesaplamaları yapma gereksinimi olan ticaret kat sistemlerinde kullanılır.

Verilerinizi tarihe göre bölümlere ayırabiliyorsanız ve eski satırlar güncellenmiyorsa, sıradan bir RDBMS platformu tarafından desteklenen Microsoft Analysis hizmetleri gibi geleneksel bir OLAP sunucusu kullanarak karma bir OLAP sistemi oluşturabilirsiniz. ~ 4 TB veri ile bu başa çıkmak mümkün olmalı ve hem SQL Server hem de SSAS paylaşılan disk kümeleri yapacak. Benzer OLAP sistemleri (ör. Oracle / Hyperion Essbase) diğer satıcılardan edinilebilir.

OLAP sunucuları, kümelerle birlikte yerel bir mağazadaki verileri devam ettirerek çalışır. Çoğu bölümlenmiş verileri destekleyecektir. Buna ek olarak, çoğu temel veritabanında sorgulama yaptıkları ROLAP modunda da çalışacaktır. Dikkat edilmesi gereken önemli nokta, depolama stratejisinin bölüm başına yönetilebileceği ve bir bölümü birinden diğerine programlı olarak değiştirebileceğiniz,

Bu modelde, geçmiş veriler MOLAP bölümlerinde saklanır ve verinin toplamları devam eder. Bir sorgu kümelerden tatmin edilebilirse, sunucu bunları kullanır. Toplamalar sorgulara uyacak şekilde ayarlanabilir ve doğru toplamalar sorguyu çözmek için gereken hesaplama miktarını önemli ölçüde azaltır. Bu tür sistemle çok hızlı yanıt veren toplu sorgular mümkündür.

Gerçek zamanlı veriler, gerekirse mevcut ay, gün veya hatta saat için küçük bir önde gelen bölüm tutularak uygulanabilir. OLAP sunucusu veritabanına sorgu gönderir; bu bölüm yeterince küçükse, DBMS hızlı bir şekilde yanıt verebilir. Düzenli bir süreç yeni öncü bölümler oluşturur ve kapalı tarihsel dönemleri MOLAP'a dönüştürür. Daha eski bölümler birleştirilerek, geçmiş veriler istenen herhangi bir tahılda yönetilebilir.

Veritabanına yazma istemcileri doğrudan temel RDBMS yazmak. Geçmiş veriler sabit kalırsa, yalnızca önde gelen bölüme yazılır. 4 TB, ekstra DBMS performansına ihtiyacınız varsa SSD'leri kullanmak için pratik bir birimdir. Ana akım satıcılar bile daha hızlı SLC üniteleri olan bir seçenek olarak SSD tabanlı tekliflere sahiptir.


Cevabınız için teşekkürler. Haklısın. Benim sorunum algoritmik ticaret platformuna benziyor ama farklı. RDBMS yolunu denedik ve ölçeklenemedi. Verilerimizin boyutu sadece büyüdüğü ve üç masada daha fazla TB'ye ulaştığımız için ölçeklenebilen ve OLAP sistemlerinin karmaşıklığına sahip olmayan bir depolamaya ihtiyacım var, RDBMS sadece çok sayıda kilitleme ve benzer sorun yaratacak. Bir nosql seçeneğinin bu gereksinimleri karşılayabileceğini umuyorum. Bunun hakkında bir fikrin var mı?
iCode

@MDotnet 12k eşzamanlı kullanıcı için 4TB boyutlu bir sorun için basit bir çözüm beklentiniz / gereksiniminiz gerçekçi olmayabilir. RDBMS yaklaşımlarına baktığınızdan ve ölçeklenmediğinden bahsediyorsunuz; 1) bunun ayrıntılarını Q'nuza ekleyebilir misiniz? 2) Bu cevap, saf ilişkisel bir veritabanı değil, karma bir ROLAP / MOLAP yaklaşımını savunmaktadır.
Mark Storey-Smith

Ben bir DBA değilim ve "upvotes tarafından sürücü" özel sitelerin çoğu için kötü olduğunu düşünüyorum, ama umurumda değil, bu cevap sadece bir upvote için çok iyi. +1
psr
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.