Yaklaşık 3,5 TB veri depolamak ve yaklaşık 1K / sn 7 gün 24 saat eklemek ve ayrıca belirtilmemiş bir hızda sorgulama yapmak SQL Server ile mümkündür, ancak daha fazla soru vardır:
- bunun için hangi kullanılabilirlik gereksiniminiz var? % 99,999 çalışma süresi mi yoksa% 95 yeterli mi?
- hangi güvenilirlik gereksiniminiz var? Bir eki kaçırmak size 1 milyon dolara mal oluyor mu?
- ne tür bir kurtarılabilirlik gereksiniminiz var? Bir günlük veriyi kaybederseniz, fark eder mi?
- hangi tutarlılık gereksiniminiz var? Bir yazının bir sonraki okumada görünür olması garanti edilmeli mi?
Vurguladığım tüm bu gereksinimlere ihtiyacınız varsa, önerdiğiniz yük, hangi hileleri denerseniz deneyin (parçalama, bölümleme vb.) İlişkisel bir sistemde, herhangi bir sistemde milyonlarca donanıma ve lisanslamaya mal olacak. Bir nosql sistemi, kendi tanımı gereği, tüm bu gereksinimleri karşılamayacaktır.
Açıkçası, bu gereksinimlerin bazılarını zaten gevşetmişsiniz. NoSQL Systems Visual Guide to NoSQL Systems'daki '3'ün 2'sini seç' paradigmasına dayanan nosql tekliflerini karşılaştıran güzel bir görsel kılavuz var :
OP yorum güncellemesinden sonra
SQL Server ile bu, basit bir uygulama olacaktır:
- tek bir tablo kümelenmiş (GUID, zaman) anahtarı. Evet, parçalanacak , ancak parçalanma önden okumaları etkiliyor mu ve önden okuma yalnızca önemli aralık taramaları için gerekli. Yalnızca belirli bir GUID ve tarih aralığı için sorguladığınızdan, parçalanmanın pek önemi olmayacaktır. Evet, geniş bir anahtardır, bu nedenle yaprak olmayan sayfaların anahtar yoğunluğu zayıf olacaktır. Evet, zayıf doldurma faktörüne yol açacaktır. Ve evet, sayfa bölünmeleri olabilir. Bu sorunlara rağmen, gereksinimler göz önüne alındığında, hala en iyi kümelenmiş anahtar seçimdir.
- Tabloyu zamana göre bölümlere ayırın, böylece süresi dolan kayıtları otomatik bir kayan pencere aracılığıyla verimli bir şekilde silebilirsiniz . GUID kümelemesinin getirdiği zayıf doldurma faktörünü ve parçalanmayı ortadan kaldırmak için geçen ayın çevrimiçi dizin bölümü yeniden yapılandırmasıyla bunu artırın.
- sayfa sıkıştırmayı etkinleştirin. Öncelikle GUID'e göre kümelenmiş anahtar grupları olduğundan, bir GUID'nin tüm kayıtları yan yana olacak ve bu da sayfa sıkıştırmaya sözlük sıkıştırmasını dağıtmak için iyi bir şans verecektir .
- günlük dosyası için hızlı bir GÇ yoluna ihtiyacınız olacaktır. Bir günlüğün saniyede 1K ekleme hızına ayak uydurması için düşük gecikmeyle değil, yüksek verimlilikle ilgileniyorsunuz, bu nedenle ayırma bir zorunluluktur.
Bölümleme ve sayfa sıkıştırmanın her biri bir Enterprise Edition SQL Server gerektirir, Standard Edition üzerinde çalışmazlar ve her ikisi de gereksinimleri karşılamak için oldukça önemlidir.
Bir yan not olarak, kayıtlar bir ön uç Web sunucuları çiftliğinden geliyorsa, her web sunucusuna Express'i koyardım ve arka uca INSERT yerine, SEND
yerel bir bağlantı / işlem kullanarak bilgiyi arka uca yazardım. Web sunucusuyla aynı yerde bulunan Express'te. Bu, çözüme çok daha iyi bir kullanılabilirlik hikayesi verir.
İşte SQL Server'da bunu böyle yapardım. İyi haber, karşılaşacağınız sorunların iyi anlaşılması ve çözümlerinin bilinmesidir. bu, bunun Cassandra, BigTable veya Dynamo ile elde edebileceğinizden daha iyi olduğu anlamına gelmez. Sql-ish olmayan şeylerde daha bilgili birine davasını tartışmasına izin vereceğim.
Programlama modelinden, .Net desteğinden ve benzerlerinden hiç bahsetmediğimi unutmayın. Dürüst olmak gerekirse, büyük dağıtımlarda önemsiz olduklarını düşünüyorum. Geliştirme sürecinde büyük bir fark yaratırlar, ancak bir kez konuşlandırıldıktan sonra, ORM ek yükü performansı düşürürse, geliştirmenin ne kadar hızlı olduğu önemli değildir :)