Bir sensör dizisinden büyük miktarlarda veri saklama

Büyük bir sensör dizisinden veri örnekleri depolamak için bir çözüm (app ve db) uygulamak için görev. Dizi şu anda yaklaşık 20.000 sensörden oluşuyor, ancak yakında 100.000 sensöre kadar büyüyecek. Her sensör her 10 saniyede bir veri örneği gönderir ve her örnek 28 bayt boyutundadır.

Böylece toplamların yapılması aşağıdakilere yol açar:

• Sensör başına günde 8640 numune
• Günde sensör başına 242kB veri
• Günde 864 milyon örnek

Şimdi veri depolamak / almak için en iyi yol ne olacağını merak ediyordum? Yazılım zaten belirtildikten sonra bu projeye "katıldım", bu yüzden SQL Server kullanarak bir Windows Platformunda uygulanması gerekiyor.

Kafamdaki mevcut çözüm, veri örneklerini saklamak için iki tablo içeren bir DB oluşturmaktır. Birincisi, harmanlanmış örnekleri sensör başına günlük olarak ikili bir alanda saklayan ikinciye bir tür dizin görevi görür:

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

Temel olarak tüm sensörlerden gelen örnekleri geçici dosyalara yazacağım (sensör başına 1). Her günün sonunda Tablo 1'de bir girdi oluşturacağım, oluşturulan RecordID'yi kullanacağım ve dosyayı Tablo 2'deki Veri alanına dökeceğim.

Bu şekilde, tabloya günde 864 milyon giriş yerine yalnızca 100.000 giriş ekledim. Veriler LAN veya Yüksek Hızlı WAN üzerinde mevcut olmalıdır, bu nedenle sensör verilerinin tüm gün bazında alınması kabul edilebilir.

Tüm verilerin saklanması gerekmesine rağmen, büyük olasılıkla hiçbir zaman okunmayacaktır. Bu nedenle, tablo (lar) daki okuma miktarı, yazımlardan çok fazla olmayacaktır.

Ben sadece veri dosyalarının yolunu depolayarak dosya sistemini kullanarak bir şey uygulamak biliyorum, ama ikili alanları daha az 256kB ise SQL Server NTFS daha iyi olduğunu okudum. (256 KB ve 1 MB arasında gri bir alan bulunurken NTFS,> 1 MB ikili boyutlar için SQL Server'dan daha iyi performans gösterir).

Ayrıca 100.000 sensörden gelen verileri kendi dosyalarına, bir klasörde çok miktarda dosyaya sahip olarak veya her klasörde birkaç dosya içeren karmaşık bir ağaç yapısına sahip olarak dosya sisteminde sorunlara neden olmadan saklamaktan biraz sakınıyorum. dosya parçalanmasını bile hesaba katar.

1. Yukarıdakiler hakkında bana pratik tavsiyeler / yorumlar sunabilir mi?

2. Düşeceğim bariz tuzaklar var mı?

3. Örnek veriler oldukça iyi sıkıştırılır. 242 kB'lik bir dosya yaklaşık 85kB'a kadar sıkıştırır. Ancak, örnek verilerin (sütun) otomatik olarak sıkıştırılması için veritabanı düzeyinde bir tür sıkıştırma uygulayabilir miyim?

4. SQL Server bu proje için açıkça yanlış bir seçim mi?

5. İki tablonun tasarımım akıllıca mı, yoksa iki tablonun hala "performans" olacağı tek bir tabloda birleştirebilir miyim?

Evet, oldukça hızlı bir şekilde karşılaşacağınız oldukça büyük bir tuzak var ve bu da masaların büyüklüğü ve bakımı ile. Verilerinizi günlük olarak geçici bir tabloya koymak ve ardından daimi tablonuza taşımak istediğinizi söyleyerek biraz doğru yoldasınız, ancak yakında bu şema ile sorun yaşarsınız.

Örneğin, iki yıl sonra en eski ayın verilerini "kapatmak" istediğinizi varsayalım. Tasarımınızda, büyük, büyük masanıza karşı bir DELETE ifadesi yayınlamanız gerekir. Sahip olduğunuz dizin sayısına bağlı olarak bu muhtemelen biraz yavaş olacaktır. Ayrıca, dizin parçalanmasına neden olacak ve bunu düzeltmenin tek yolu, bu çok büyük tabloda dizinleri yeniden oluşturmak veya yeniden düzenlemek olacaktır. Bu da performans sorunlarına neden olacaktır. Büyük tek bir masa tipi tasarımı ile de bir dizi başka sorun var. Örneğin, büyük, tek bir tabloyla, FILEGROUP tabanlı yedeklemeler yapamazsınız , yani veritabanınızın tam bir yedeğini almak istiyorsanız, BÜYÜK olacak ve tamamlanması UZUN zaman alacaktır.

Çözüm nedir? Tablo bölümleme. Bunun hakkında olabildiğince çok yerde derinlemesine okuyun. Temel olarak bölümleme, verilerinizi "tablolar içindeki tablolara" ayırmanıza olanak tanır - her bölüm aynı şemayı paylaşır ve tablo nesnesi üzerinden erişilir, ancak farklı şekilde dizine eklenebilir ve korunabilir. Bölümler temel olarak bazı yararlı anahtarlarla kesilmiş tablolardır. Senin durumunda muhtemelen tarih olacak. Tablolar gibi (ve aynı hızda) bırakılabilirler, yani büyük veri tablolarınızı tarihe göre bölümlere ayırırsanız, eski bölümleri anında bırakabilirsiniz, diğer bölümlerin hiçbirindeki dizinlere olumsuz bir etkisi yoktur. Bölümleri farklı dosya gruplarına koyabilirsiniz, bu da daha eski bölümlerin yaygın olarak kullanılmadığı takdirde daha ucuz emtia depolama alanına yuvarlanabileceği veya yuvarlanabileceği anlamına gelir. Son fakat en az değil, SQL 2012'de 'eski, salt okunur bölümlerinizde , tüm sensör verilerinizi eklediğiniz etkin bölümde farklı, daha ek odaklı bir dizin oluşturma şemasına sahip olursunuz.

Bu yardımcı olur umarım. Bölümleme ve bölümleme şemaları ile ilgili yapmanız gereken iyi bir araştırmanız var, ancak umarım şimdi bakmanız gereken yönü biliyorsunuzdur.

Not: Ah, ve madde işaretli soru listenizi unuttum ... Cevap 1, 2 ve 5. Yukarıya bakınız. Cevap 3: SQL Server'da bölüm bazında bölüm bazında sıkıştırabilirsiniz, bu nedenle eski bölümlerinizi PAGE sıkıştırmasını kullanarak agresif bir şekilde sıkıştırın. Ancak, bunu yaparsanız sıra dışı büyük veri türlerinizin sıkıştırılmayacağına inanıyorum - yine, sensör değerlerinizi normalleştirerek bu sorunu hafifletmek isteyebilirsiniz. Cevap 4: Kesinlikle hayır, ama tek yapmanız gereken statik verileri güne kadar saklamak ve asla başka bir şekilde arama yapmaksa, sıkıştırılmış düz dosyalar gitmek için çok daha kolay bir yol olabilir.

PPS: Oh, ve başka bir şey. Tüm bunların çalışması için iki tablolu çözümünüze ihtiyacınız yoktur. Büyük ikili sensör verileri VARBINARY (MAX) türünde olmalıdır, çünkü değerleri " satır dışında " saklanabilir , ancak yine de tek bir tabloda sütun olabilir (bkz. Sp_tableoption belgeleri). Yine de, sensör verilerinizden bazılarını tablodaki ikili verilerden normalleştirmeyi düşünebilirsiniz, çünkü veritabanınız sensör verilerinin parçalarını zamanla almanın ötesinde çok iyi olmayacaktır.

Bir Hadoop çözümünü düşünün. 2 TB / gün hızla eklenir. Ayrıca, yalnızca delta kayıtlarını, yani başlangıç ​​değerini ve daha sonra yalnızca bir değişiklik olduğunda günlüğe kaydetmeyi düşünün.