Saya membuat sistem yang mengumpulkan data untuk perangkat pada berbagai metrik seperti pemanfaatan CPU, pemanfaatan disk, suhu, dll. Pada interval (mungkin) 5 menit menggunakan SNMP. Tujuan utamanya adalah untuk memberikan visualisasi kepada pengguna sistem dalam bentuk grafik deret waktu.

Saya telah melihat menggunakan RRDTool di masa lalu, tetapi menolaknya karena menyimpan data yang diambil itu penting untuk proyek saya, dan saya ingin tingkat yang lebih tinggi dan akses yang lebih fleksibel ke data yang diambil. Jadi pertanyaan saya benar-benar:

Apa yang lebih baik, database relasional (seperti MySQL atau PostgreSQL) atau database non-relasional atau NoSQL (seperti MongoDB atau Redis) berkenaan dengan kinerja ketika meminta data untuk membuat grafik.

Relasional

Diberikan database relasional, saya akan menggunakan data_instancestabel, di mana akan disimpan setiap contoh data yang diambil untuk setiap metrik yang diukur untuk semua perangkat, dengan bidang-bidang berikut:

Bidang: id fk_to_device fk_to_metric metric_value timestamp

Ketika saya ingin menggambar grafik untuk metrik tertentu pada perangkat tertentu, saya harus meminta tabel tunggal ini memfilter perangkat lain, dan metrik lainnya sedang dianalisis untuk perangkat ini:

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

Jumlah baris dalam tabel ini adalah:

d * m_d * f * t

di mana djumlah perangkat , m_dadalah jumlah akumulatif dari metrik yang direkam untuk semua perangkat, fadalah frekuensi di mana data disurvei dan tadalah jumlah total waktu sistem telah mengumpulkan data.

Untuk pengguna yang merekam 10 metrik untuk 3 perangkat setiap 5 menit selama setahun, kami hanya memiliki di bawah 5 juta catatan.

Indeks

Tanpa indeks fk_to_devicedan fk_to_metricpemindaian tabel yang terus berkembang ini akan memakan waktu terlalu banyak. Jadi pengindeksan bidang tersebut dan juga timestamp(untuk membuat grafik dengan periode lokal) adalah persyaratan.

Non-Relasional (NoSQL)

MongoDB memiliki konsep koleksi , tidak seperti tabel ini dapat dibuat secara pemrograman tanpa setup. Dengan ini saya bisa mempartisi penyimpanan data untuk setiap perangkat, atau bahkan setiap metrik yang direkam untuk setiap perangkat.

Saya tidak punya pengalaman dengan NoSQL dan tidak tahu apakah mereka menyediakan fitur peningkatan kinerja kueri seperti pengindeksan, namun paragraf sebelumnya mengusulkan melakukan sebagian besar pekerjaan kueri relasional tradisional dalam struktur di mana data disimpan di bawah NoSQL.

Bimbang

Apakah solusi relasional dengan pengindeksan yang benar akan berkurang menjadi perayapan dalam tahun ini? Atau apakah struktur pengumpulan berdasarkan pendekatan NoSQL (yang cocok dengan model mental saya dari data yang disimpan) memberikan manfaat yang nyata?

Pasti Relasional. Fleksibilitas dan ekspansi tanpa batas.

Dua koreksi, baik dalam konsep dan aplikasi, diikuti oleh elevasi.

Koreksi

1. Itu bukan "memfilter data yang tidak dibutuhkan"; itu hanya memilih data yang dibutuhkan. Ya, tentu saja, jika Anda memiliki Indeks untuk mendukung kolom yang diidentifikasi dalam klausa WHERE, itu sangat cepat, dan kueri tidak bergantung pada ukuran tabel (mengambil 1.000 baris dari tabel 16 miliar baris secara instan) .

2. Meja Anda memiliki satu kendala serius. Dengan uraian Anda, PK yang sebenarnya adalah (Perangkat, Metrik, DateTime). (Tolong jangan menyebutnya TimeStamp, itu berarti sesuatu yang lain, tetapi itu adalah masalah kecil.) Keunikan baris diidentifikasi oleh:

      (Device, Metric, DateTime)
   

   • The Idkolom tidak apa-apa, itu benar-benar dan benar-benar berlebihan.

     • Sebuah Idkolom tidak pernah Key (duplikasi baris, yang dilarang dalam database relasional, harus dicegah dengan cara lain).

     • The Idkolom membutuhkan Indeks tambahan, yang jelas menghambat kecepatan INSERT/DELETE, dan menambah ruang disk yang digunakan.

     • Anda bisa menyingkirkannya. Silahkan.

Ketinggian

1. Sekarang setelah Anda menghilangkan rintangan, Anda mungkin tidak mengenalinya, tetapi tabel Anda berada di Form Normal Keenam. Kecepatan sangat tinggi, dengan hanya satu Indeks pada PK. Untuk memahami, bacalah jawaban ini dari Apa itu Bentuk Normal Keenam? menuju ke depan.

   • (Saya punya satu indeks saja, bukan tiga; pada Non-SQL Anda mungkin perlu tiga indeks).

   • Saya memiliki tabel yang sama persis (tanpa Id"kunci", tentu saja). Saya memiliki kolom tambahan Server. Saya mendukung banyak pelanggan dari jarak jauh.

     (Server, Device, Metric, DateTime)

   Tabel dapat digunakan untuk Pivot data (mis. DevicesMelintasi bagian atas dan Metricsbawah sisi, atau diputar) menggunakan kode SQL yang persis sama (ya, alihkan sel). Saya menggunakan tabel ini untuk membuat berbagai grafik dan bagan yang tidak terbatas agar pelanggan mendapatkan kinerja server mereka.

   • Monitor Model Data Statistik .
     (Terlalu besar untuk inline; beberapa browser tidak dapat memuat inline; klik tautan. Juga itu adalah versi demo yang usang, untuk alasan yang jelas, saya tidak dapat menunjukkan kepada Anda DM produk komersial.)

   • Ini memungkinkan saya untuk menghasilkan Grafik Seperti Ini , enam kali penekanan tombol setelah menerima file statistik pemantauan mentah dari pelanggan, menggunakan perintah SELECT tunggal . Perhatikan campuran-dan-cocokkan; OS dan server pada grafik yang sama; berbagai Pivot. Tentu saja, tidak ada batasan jumlah matriks statistik, dan dengan demikian grafik. (Digunakan dengan izin baik dari pelanggan.)

   • Pembaca yang tidak terbiasa dengan Standar untuk Pemodelan Basis Data Relasional dapat menemukan Notasi IDEF1X bermanfaat.

Satu hal lagi

Terakhir, SQL adalah Standar IEC / ISO / ANSI. Freeware sebenarnya adalah Non-SQL; adalah penipuan untuk menggunakan istilah SQL jika mereka tidak memberikan Standar. Mereka mungkin menyediakan "ekstra", tetapi mereka tidak ada dasar-dasarnya.

Ditemukan sangat menarik jawaban di atas. Mencoba menambahkan beberapa pertimbangan lagi di sini.

1) Penuaan data

Manajemen time-series biasanya perlu membuat kebijakan penuaan. Skenario khas (mis. Pemantauan server CPU) perlu disimpan:

• Sampel mentah 1 detik untuk periode singkat (mis. Selama 24 jam)

• Sampel agregat detail 5 menit untuk periode menengah (mis. 1 minggu)

• Detail 1 jam lebih dari itu (misalnya hingga 1 tahun)

Meskipun model relasional memungkinkan untuk memastikannya (perusahaan saya menerapkan basis data terpusat yang besar untuk beberapa pelanggan besar dengan puluhan ribu seri data) untuk mengelolanya dengan tepat, generasi baru toko data menambah fungsionalitas menarik untuk dieksplorasi seperti:

• pembersihan data otomatis (lihat perintah EXPIRE Redis)

• agregasi multidimensi (mis. pekerjaan pengurangan peta a-la-Splunk)

2) Koleksi waktu nyata

Yang lebih penting lagi, beberapa penyimpanan data non-relasional didistribusikan secara inheren dan memungkinkan pengumpulan data waktu-nyata (atau waktu-dekat-waktu) yang jauh lebih efisien yang bisa menjadi masalah dengan RDBMS karena penciptaan hotspot (mengelola pengindeksan saat memasukkan dalam satu meja). Masalah dalam ruang RDBMS ini biasanya diselesaikan dengan mengembalikan ke prosedur impor batch (kami berhasil dengan cara ini di masa lalu) sementara teknologi no-sql telah berhasil dalam pengumpulan dan agregasi real-time yang sangat besar (lihat contoh Splunk, disebutkan dalam balasan sebelumnya) .

Tabel Anda memiliki data dalam tabel tunggal. Jadi relasional vs non relasional bukanlah pertanyaan. Pada dasarnya Anda perlu membaca banyak data berurutan. Sekarang jika Anda memiliki RAM yang cukup untuk menyimpan data bernilai bertahun-tahun maka tidak ada yang seperti menggunakan Redis / MongoDB dll.

Sebagian besar basis data NoSQL akan menyimpan data Anda di lokasi yang sama pada disk dan dalam bentuk terkompresi untuk menghindari akses beberapa disk.

NoSQL melakukan hal yang sama seperti membuat indeks pada id perangkat dan metrik id, tetapi dengan caranya sendiri. Dengan database bahkan jika Anda melakukan ini, indeks dan data mungkin berada di tempat yang berbeda dan akan ada banyak IO disk.

Alat-alat seperti Splunk menggunakan backend NoSQL untuk menyimpan data deret waktu dan kemudian menggunakan pengurangan peta untuk membuat agregat (yang mungkin seperti yang Anda inginkan nanti). Jadi menurut saya untuk menggunakan NoSQL adalah pilihan karena orang sudah mencobanya untuk kasus penggunaan serupa. Tetapi sejuta baris akan membawa database untuk merayapi (mungkin tidak, dengan perangkat keras yang layak dan konfigurasi yang tepat).

Buat file, beri nama 1_2.data. ide weired? apa yang kau dapatkan:

• Anda menghemat hingga 50% ruang karena Anda tidak perlu mengulang nilai fk_to_device dan fk_to_metric untuk setiap titik data.
• Anda menghemat lebih banyak ruang karena Anda tidak memerlukan indeks apa pun.
• Simpan pasangan (cap waktu, metric_value) ke file dengan menambahkan data sehingga Anda mendapatkan pesanan dengan cap waktu secara gratis. (dengan asumsi bahwa sumber Anda tidak mengirimkan data pesanan untuk perangkat)

=> Query by timestamp berjalan sangat cepat karena Anda dapat menggunakan pencarian biner untuk menemukan tempat yang tepat dalam file untuk dibaca.

jika Anda menyukainya, lebih dioptimalkan mulai berpikir tentang memisahkan file Anda seperti itu;

• 1_2_january2014.data
• 1_2_februari2014.data
• 1_2_march2014.data

atau gunakan kdb + dari http://kx.com karena mereka melakukan semua ini untuk Anda :) berorientasi kolom adalah apa yang dapat membantu Anda.

Ada solusi berbasis kolom berbasis cloud yang muncul, jadi Anda mungkin ingin melihatnya di: http://timeseries.guru

Jika Anda melihat paket GPL, RRDTool adalah yang baik untuk dilihat. Ini adalah alat yang baik untuk menyimpan, mengekstraksi, dan membuat grafik data time-series. Kasing Anda terlihat persis seperti data deret waktu.

Ini adalah masalah yang harus kami pecahkan di ApiAxle. Kami menulis posting blog tentang bagaimana kami melakukannya menggunakan Redis. Sudah lama tidak ada di sana, tetapi terbukti efektif.

Saya juga menggunakan RRDTool untuk proyek lain yang sangat bagus.

Saya pikir jawaban untuk pertanyaan semacam ini terutama harus berkisar tentang cara penyimpanan Basis data Anda. Beberapa server Database menggunakan RAM dan Disk, beberapa hanya menggunakan RAM (Disk opsional untuk persistensi), dll. Solusi SQL Database yang paling umum adalah menggunakan memori + penyimpanan disk dan menulis data dalam tata letak berbasis Baris (setiap raw yang dimasukkan ditulis dengan cara yang sama lokasi fisik). Untuk toko jangka waktu, dalam kebanyakan kasus beban kerja adalah seperti: Interval relatif rendah dari jumlah besar sisipan, sedangkan bacaan berbasis kolom (dalam kebanyakan kasus Anda ingin membaca rentang data dari kolom tertentu, mewakili metrik)

Saya telah menemukan Basis Data Columnar (google itu, Anda akan menemukan MonetDB, InfoBright, parAccel, dll) melakukan pekerjaan yang hebat untuk rangkaian waktu.

Adapun pertanyaan Anda, yang secara pribadi saya pikir agak tidak valid (karena semua diskusi menggunakan istilah kesalahan NoSQL - IMO): Anda dapat menggunakan server Database yang dapat berbicara SQL di satu sisi, membuat hidup Anda sangat mudah karena semua orang tahu SQL untuk banyak tahun dan bahasa ini telah disempurnakan berulang kali untuk kueri data; tetapi masih menggunakan RAM, Cache dan Disk CPU dengan cara yang berorientasi pada Columnar, menjadikan solusi Anda paling cocok dengan Time Series

5 Jutaan baris bukanlah apa-apa untuk data deras hari ini. Harapkan data dalam TB atau PB hanya dalam beberapa bulan. Pada titik ini RDBMS tidak melakukan skala terhadap tugas dan kami membutuhkan skalabilitas linier dari basis data NoSql. Kinerja akan dicapai untuk partisi kolom yang digunakan untuk menyimpan data, menambahkan lebih banyak kolom dan lebih sedikit jenis konsep untuk meningkatkan kinerja. Leverage pekerjaan Open TSDB dilakukan di atas HBASE atau MapR_DB, dll.

Saya menghadapi persyaratan serupa secara teratur, dan baru-baru ini mulai menggunakan Zabbix untuk mengumpulkan dan menyimpan data jenis ini. Zabbix memiliki kemampuan grafiknya sendiri, tetapi cukup mudah untuk mengekstrak data dari basis data Zabbix dan memprosesnya sesuka Anda. Jika Anda belum memeriksa Zabbix, Anda mungkin merasa layak untuk melakukannya.

Anda harus melihat ke dalam database Time series . Itu dibuat untuk tujuan ini.

Database deret waktu (TSDB) adalah sistem perangkat lunak yang dioptimalkan untuk menangani data deret waktu, susunan angka yang diindeks oleh waktu (rentang waktu atau rentang waktu).

Contoh populer dari database time-series InfluxDB