Apa cara yang baik untuk menyimpan sejumlah besar kolom?

Saya memiliki masalah dalam memutuskan bagaimana menyimpan data ini di basis data saya. Adakah saran tentang cara terbaik untuk melakukannya? Saya tidak tahu banyak tentang database, saya bisa menambahkan.

Saya memiliki data yang diformat seperti itu, tetapi alih-alih 4, jumlah kolom kira-kira 240, sehingga setiap tanggal memiliki 240 nilai unik yang terkait dengannya:

Date/Time 200,00 202,50 205,00  
2010.11.12  13:34:00  45,8214 43,8512  41,5369   
2010.11.12  13:35:00  461,9364  454,2612  435,5222 

Juga, baris dikaitkan dengan DataSites.

Pikiran pertama saya adalah memiliki tabel seperti ini: DataID (pk), DataSiteID, ParameterID, Tanggal, Nilai, dengan indeks pada DataSite, Parameter dan Tanggal. ParameterID merujuk ke tabel lain yang menyimpan header kolom input (200,00 202,50 205,00 ...).

Pikiran kedua saya hanyalah memiliki tabel dengan semua kolom 240-aneh. Saya telah menemukan beberapa cara lain, tetapi mereka juga tidak memuaskan.

Masalah yang saya miliki dengan solusi pertama saya (bukan masalah besar, tapi saya tidak suka itu), adalah bahwa Date dan DataSiteID akan diulang untuk semua 240 nilai dalam baris input itu, sehingga menggunakan sedikit ruang ekstra.

Akan ada sekitar 40gb data setahun yang akan datang (dalam format teks di atas), dan data akan dicari oleh DataSite, Parameter dan Tanggal. Jumlah data yang masuk kemungkinan besar akan empat kali lipat dalam setahun atau lebih.

Ada ide bagus? Terima kasih, James

sunting: Ini adalah data deret waktu, dengan kolom yang diukur pada panjang gelombang berbeda. Data akan ingin dianalisis dalam rentang panjang gelombang yang relatif sempit. Mungkin ada tambahan panjang gelombang tambahan di beberapa titik di masa depan.

sunting: Terima kasih atas jawabannya kawan, saya sangat menghargainya :) Saya pikir saya mungkin dapat menemukan waktu untuk menjalankan beberapa percobaan dengan 500 GB atau lebih data uji. Saya akan mengirim kembali dengan kesimpulan apa pun;)

Anda dapat membuat case dengan cara apa pun, tetapi jika data akan digunakan untuk analisis dan Anda sering ingin melihat beberapa kolom dari data itu pada saat yang bersamaan, gunakan tabel lebar. Pastikan Anda tahu jumlah kolom database Anda dan batas ukuran baris. Pastikan Anda mendapatkan tipe data yang benar. Jika banyak kolom adalah nol, SQL Server memungkinkan Anda untuk mengoptimalkan tabel untuk itu. Anda juga dapat mempertimbangkan menggunakan solusi NOSQL (Not Only SQL) untuk analisis tipe data ini.

Jika data ini akan kurang untuk analisis, Anda mungkin ingin menormalkannya seperti yang dinyatakan dalam pertanyaan Anda.

Saya memiliki situasi yang sangat mirip dengan Anda, 257 bidang dengan 30-50 GB per tahun masuk. Saya akhirnya tetap sederhana, satu meja panjang besar di SQL Server. Data saya ditanyai sedikit adil tetapi terutama pada tanggal dan itu bekerja dengan baik.

Saya bisa saja memecah data menjadi chuck logis yang lebih kecil (kelompok sekitar 50 atau lebih), tetapi dalam kasus ini benar-benar tidak banyak keuntungan untuk itu, jadi saya menyelamatkan diri saya dari gangguan.

Jika saya merasa senang sekarang saya mungkin mempertimbangkan opsi NoSQL yang lebih cocok secara teori, tetapi dengan data misi kritis mencoba hal-hal baru tidak selalu bagus untuk saraf.

Jadi, untuk segera menjawab pertanyaan saya sendiri (proyek tidak pernah berjalan pada akhirnya), ketika saya berhasil mendapatkan waktu luang saya mengisi tabel uji dengan 500gb data dengan tabel diatur sedemikian rupa:

Pikiran pertama saya adalah memiliki tabel seperti ini: DataID (pk), DataSiteID, ParameterID, Tanggal, Nilai, dengan indeks pada DataSite, Parameter dan Tanggal. ParameterID merujuk ke tabel lain yang menyimpan header kolom input (200,00 202,50 205,00 ...).

Pengaturan database adalah instalasi PostgreSQL standar pada mesin dual core lama dengan ram 3gb. Saya menjalankan sekitar selusin pertanyaan yang berbeda hanya dengan memilih data berdasarkan DataSite Date dan ParameterID, rata-rata data selama periode 1 jam, periode 1 hari, dan memasukkan potongan data baru. Dari memori, semua kueri membutuhkan waktu kurang dari satu detik untuk dieksekusi. Itu tentu saja jauh lebih cepat dari yang saya harapkan dan cukup bisa digunakan. Satu hal yang saya tidak pikirkan adalah bahwa dengan tabel yang diindeks dengan cara ini, file indeks juga hampir 500gb, sehingga memiliki tabel selebar 240 kolom tentunya akan menghemat banyak ruang disk.

Dalam Postgres saya akan menyelesaikan masalah ini dengan elegan dengan tipe array atau varray di Oracle.

Saya tidak tahu apakah ini berguna untuk masalah Anda, tetapi untuk kolom saya tidak perlu melakukan permintaan langsung (cols yang saya tidak pernah masukkan dalam kondisi WHERE saya), dan yang hanya informatif ketika saya ingin semua info tentang beberapa baris tertentu, saya menggabungkan mereka dalam bidang blog JSON diformat.

Saya mungkin akan membuat keputusan akhir dari desain tergantung dari distribusi parameter_ids yang diminta. Yaitu, jika ada beberapa parameter_ids yang ditanyai hampir secara eksklusif, saya akan meletakkan nilainya ke dalam tabel panas dan nilai yang tersisa ke tabel dingin lainnya .

Otoh, jika distribusi kueri mereka lebih atau kurang merata, saya akan memuat set sampel yang bernilai beberapa hari ke dalam tabel di mana satu catatan menyimpan semua nilai untuk melihat apa perbandingan antara record / db-blok (atau jika bahkan ada masalah rantai baris , yang kemungkinan). Bergantung pada itu saya kemudian akan membuat keputusan desain lebih lanjut.

Nah, setelah membacanya, saya mungkin akan melakukan kedua pendekatan tersebut untuk tujuan secara paralel.

Saya membaca kembali pertanyaan - jika saya memiliki ini benar, maka dalam setiap catatan yang Anda dapatkan sebagai input, ada nilai yang berbeda yang dilacak (berdasarkan ParameterID):

ParameterID merujuk ke tabel lain yang menyimpan header kolom input (200,00 202,50 205,00 ...).

... Saya tidak cukup tahu tentang bagaimana Anda berinteraksi dengan data, tetapi saya akan cenderung untuk pergi dengan opsi lain - memiliki tabel terpisah untuk setiap parameter ID, dan kemudian jika perlu memiliki pandangan yang akan gabungkan berbagai parameter berbeda berdasarkan tanggal dan lokasi ke dalam tabel yang lebih luas (240 kolom); jika penting untuk menjaga agar DataID dapat diakses dalam tampilan, maka Anda bisa menggunakan yang UNIONbukan JOIN, tetapi kolom akan jarang diisi.