Menyimpan sejumlah besar data dari array sensor

Saya telah ditugaskan untuk mengimplementasikan solusi (aplikasi dan db) untuk menyimpan sampel data dari array sensor yang sangat besar. Array saat ini terdiri dari sekitar 20.000 sensor, tetapi itu akan segera tumbuh, hingga 100.000 sensor. Setiap sensor mengirimkan sampel data setiap 10 detik dan setiap sampel berukuran 28 byte.

Dengan demikian, jumlah yang terjadi mengarah ke:

• 8640 sampel per sensor per hari
• 242kB data per sensor per hari
• 864 juta sampel per hari

Sekarang saya bertanya-tanya apa cara terbaik untuk menyimpan / mengambil data? Saya "bergabung" dengan proyek ini setelah perangkat lunak telah ditentukan, sehingga perlu diimplementasikan pada Platform Windows menggunakan SQL Server.

Solusi saat ini di kepala saya adalah membuat DB dengan dua tabel untuk menyimpan sampel data. Yang pertama berfungsi sebagai semacam indeks ke dalam indeks kedua yang menyimpan sampel yang dikumpulkan dalam bidang biner per hari per basis sensor:

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 

Pada dasarnya saya akan menulis sampel dari semua sensor menjadi file sementara (1 per sensor). Pada akhir setiap hari saya kemudian akan membuat entri di Tabel 1, menggunakan RecordID yang dihasilkan dan membuang file ke bidang Data di Tabel 2.

Dengan cara ini saya berakhir dengan hanya 100.000 entri ke dalam tabel per hari, bukan 864 juta entri. Data tersebut harus tersedia pada LAN atau WAN Kecepatan Tinggi, sehingga pengambilan data sensor setiap hari akan dapat diterima.

Meskipun semua data harus disimpan, sebagian besar mungkin tidak akan pernah dibaca. Jadi jumlah bacaan di atas meja tidak akan lebih banyak dari pada yang ditulis.

Saya tahu bahwa saya bisa mengimplementasikan sesuatu menggunakan sistem file dengan hanya menyimpan path ke file data, tetapi saya membaca bahwa SQL Server mengungguli NTFS sementara bidang biner Anda kurang berterima 256kB. (Area abu-abu ada antara 256kB dan 1MB, sementara NTFS jauh mengungguli SQL Server untuk ukuran biner> 1 MB).

Saya juga sedikit waspada menyimpan data dari 100.000 sensor ke dalam file mereka sendiri tanpa menyebabkan masalah dalam sistem file dengan baik memiliki sejumlah besar file dalam folder, atau dengan memiliki struktur pohon yang kompleks dengan beberapa file di setiap folder, sementara tidak bahkan memperhitungkan fragmentasi file.

1. Adakah yang bisa memberi saya saran / komentar praktis di atas?

2. Apakah ada jebakan jelas yang akan saya hadapi?

3. Data sampel melakukan kompres dengan cukup baik. File 242 kB memampatkan menjadi sekitar 85kB. Namun, bisakah saya menerapkan beberapa jenis kompresi pada tingkat basis data sehingga data sampel (kolom) dikompresi secara otomatis?

4. Apakah SQL Server merupakan pilihan yang jelas salah untuk proyek ini?

5. Apakah desain saya dari dua tabel bijaksana, atau bisakah saya menggabungkannya menjadi satu tabel yang masih akan sama "performan" dengan dua tabel?

Ya, ada jebakan yang cukup besar yang akan Anda temui dengan cukup cepat, dan itu adalah dengan ukuran dan pemeliharaan tabel. Anda agak berada di jalur yang benar dengan mengatakan bahwa Anda ingin meletakkan data Anda ke tabel sementara setiap hari, dan kemudian memindahkannya ke tabel permanen Anda, tetapi Anda akan segera mengalami masalah dengan skema ini.

Misalnya, katakanlah Anda ingin "meluncurkan" data bulan tertua setelah dua tahun. Dalam desain Anda, Anda harus mengeluarkan pernyataan DELETE terhadap meja besar Anda. Ini kemungkinan akan agak lambat, tergantung pada jumlah indeks yang Anda miliki. Juga, ini akan menyebabkan indeks fragmentasi, dan satu-satunya cara untuk memperbaikinya adalah dengan membangun kembali atau mengatur ulang indeks pada tabel yang sangat besar ini yang juga akan menyebabkan masalah kinerja. Ada banyak masalah lainnya dengan desain tipe tabel tunggal yang besar juga. Misalnya, dengan satu tabel besar, Anda tidak dapat melakukan backup berbasis FILEGROUP , yang berarti bahwa jika Anda ingin memiliki cadangan penuh dari database Anda, itu akan menjadi BESAR, dan itu akan membutuhkan waktu yang lama untuk menyelesaikannya.

Apa solusinya? Partisi tabel. Baca tentang ini secara mendalam, di sebanyak mungkin tempat. Pada dasarnya, mempartisi memungkinkan Anda untuk membagi data Anda menjadi "tabel di dalam tabel" - setiap partisi berbagi skema yang sama, dan diakses melalui objek tabel, tetapi dapat diindeks dan dikelola secara berbeda. Partisi pada dasarnya adalah tabel, dipotong oleh beberapa kunci yang berguna. Dalam kasus Anda, kemungkinan tanggal. Mereka dapat dijatuhkan seperti (dan secepat) tabel, yang berarti bahwa jika Anda mempartisi tabel data besar Anda berdasarkan tanggal, Anda dapat langsung menjatuhkan partisi lama secara instan, tanpa efek buruk pada indeks di salah satu partisi lainnya. Anda dapat menempatkan partisi pada grup-grup fileg yang berbeda, yang berarti bahwa partisi-partisi lama dapat digulirkan, atau digulirkan ke penyimpanan komoditas yang lebih murah jika tidak umum digunakan. Last but not least, di SQL 2012 Andapada partisi Anda yang lebih lama, hanya-baca , sambil memiliki skema pengindeksan yang lebih, lebih berorientasi memasukkan pada partisi aktif tempat Anda memasukkan semua data sensor Anda.

Semoga ini membantu. Anda memiliki banyak penelitian yang harus dilakukan mengenai skema partisi dan partisi, tetapi semoga sekarang Anda tahu arah yang perlu Anda perhatikan.

PS: Oh, dan saya lupa daftar pertanyaan Anda ... Jawab 1, 2, dan 5. Lihat di atas. Jawaban 3: Di SQL Server, Anda dapat mengompres berdasarkan partisi demi partisi, jadi kompres partisi lama Anda secara agresif menggunakan kompresi PAGE. Tapi saya percaya tipe data besar Anda yang tidak di-baris tidak akan dikompresi jika Anda melakukan ini - sekali lagi, Anda mungkin ingin mengatasi masalah ini dengan menormalkan nilai sensor Anda. Jawaban 4: Sama sekali tidak, tetapi jika semua yang Anda ingin lakukan adalah menyimpan data statis per hari dan tidak pernah mencarinya dengan cara lain, file datar terkompresi mungkin merupakan cara yang lebih mudah untuk dilakukan.

PPS: Oh, dan satu hal lagi. Anda tidak perlu solusi dua meja untuk membuat ini semua berfungsi. Data sensor biner besar harus bertipe VARBINARY (MAX) karena nilainya dapat disimpan "di luar baris " tetapi masih berupa kolom dalam satu tabel (lihat dokumentasi opsi sp_table ). Anda mungkin ingin mempertimbangkan untuk menormalkan beberapa data sensor Anda dari data biner yang Anda miliki dalam tabel, meskipun, karena database Anda tidak akan baik untuk banyak hal selain mengambil potongan data sensor dengan waktu jika Anda tidak.

Pertimbangkan solusi Hadoop. 2 Tb / hari bertambah dengan cepat. Juga pertimbangkan untuk mencatat hanya catatan delta, yaitu nilai awal, dan kemudian hanya ketika perubahan terjadi.