Saya menulis aplikasi yang perlu menyimpan dan menganalisis sejumlah besar data listrik dan suhu.

Pada dasarnya saya perlu menyimpan sejumlah besar pengukuran penggunaan listrik per jam selama beberapa tahun terakhir dan selama bertahun-tahun yang akan datang untuk puluhan ribu lokasi dan kemudian menganalisis data dengan cara yang tidak terlalu rumit.

Informasi yang perlu saya simpan (untuk saat ini) adalah ID Lokasi, Stempel Waktu (Tanggal dan Waktu), Suhu dan Penggunaan Listrik.

Tentang jumlah data yang perlu disimpan, ini merupakan perkiraan, tetapi ada sesuatu di sepanjang garis itu:
20 000+ lokasi, 720 catatan per bulan (pengukuran per jam, sekitar 720 jam per bulan), 120 bulan (selama 10 tahun yang lalu) ) dan bertahun-tahun ke depan. Perhitungan sederhana menghasilkan hasil berikut:

20 000 lokasi x 720 catatan x 120 bulan (10 tahun yang lalu) = 1 728.000 catatan .

Ini adalah catatan yang lalu, catatan baru akan diimpor setiap bulan, jadi itu sekitar 20.000 x 720 = 14.400.000 catatan baru per bulan .

Total lokasi akan terus tumbuh juga.

Pada semua data itu, operasi berikut perlu dijalankan:

1. Ambil data untuk tanggal dan periode waktu tertentu: semua catatan untuk ID Lokasi tertentu antara tanggal 01.01.2013 dan 01.01.2017 dan antara 07: 00-13: 00.
2. Operasi matematika sederhana untuk tanggal dan rentang waktu tertentu, mis. MIN, MAX dan suhu AVG dan penggunaan listrik untuk ID Lokasi tertentu selama 5 tahun antara pukul 07: 00-13: 00.

Data akan ditulis setiap bulan, tetapi akan dibaca oleh ratusan pengguna (setidaknya) terus-menerus, sehingga kecepatan baca secara signifikan lebih penting.

Saya tidak punya pengalaman dengan database NoSQL tetapi dari apa yang saya kumpulkan, mereka adalah solusi terbaik untuk digunakan di sini. Saya sudah membaca di database NoSQL paling populer, tetapi karena mereka sangat berbeda dan juga memungkinkan untuk arsitektur tabel yang sangat berbeda, saya belum dapat memutuskan apa yang terbaik untuk digunakan database.

Pilihan utama saya adalah Cassandra dan MongoDB, tapi saya karena saya memiliki pengetahuan yang sangat terbatas dan tidak ada pengalaman nyata ketika datang ke data besar dan NoSQL saya tidak terlalu yakin. Saya juga membaca bahwa PostreSQL juga menangani jumlah data dengan baik.

Pertanyaan saya adalah sebagai berikut:

1. Haruskah saya menggunakan database NoSQL untuk data dalam jumlah besar. Jika tidak, bisakah saya tetap menggunakan MySQL?
2. Basis data apa yang harus saya gunakan?
3. Haruskah saya menyimpan tanggal dan waktu dalam kolom terpisah, diindeks (jika mungkin) untuk mengambil dan memproses data dengan cepat untuk periode waktu dan tanggal tertentu, atau dapatkah ini dilakukan dengan menjaga stempel waktu dalam satu kolom?
4. Apakah pendekatan pemodelan data deret waktu sesuai di sini, dan jika tidak, Anda bisa memberi saya petunjuk untuk desain tabel yang baik?

Terima kasih.

Ini persis apa yang saya lakukan setiap hari, kecuali alih-alih menggunakan data per jam, saya menggunakan data 5 menit. Saya mengunduh sekitar 200 juta catatan setiap hari, jadi jumlah yang Anda bicarakan di sini tidak menjadi masalah. Data 5 menit berukuran sekitar 2 TB dan saya memiliki data cuaca selama 50 tahun pada tingkat per jam berdasarkan lokasi. Jadi izinkan saya menjawab pertanyaan Anda berdasarkan pengalaman saya:

1. Jangan gunakan NoSQL untuk ini. Data ini sangat terstruktur dan sangat cocok dengan basis data relasional.
2. Saya pribadi menggunakan SQL Server 2016 dan saya tidak punya masalah menerapkan perhitungan di volume data itu. Awalnya pada contoh PostgreSQL ketika saya memulai pekerjaan saya dan tidak bisa menangani volume data seperti pada contoh AWS kecil.
3. Saya akan sangat menyarankan mengekstraksi bagian jam dari tanggal dan menyimpannya terpisah dari tanggal itu sendiri. Percayalah, belajarlah dari kesalahan saya!
4. Saya menyimpan sebagian besar data-bijaksana (DATE, TIME, DATAPOINT_ID, VALUE) tapi itu bukan bagaimana orang ingin menginterpretasikan data. Bersiaplah untuk beberapa pertanyaan menghebohkan terhadap data dan sejumlah besar pivoting. Jangan takut untuk membuat tabel de-normalisasi untuk set hasil yang terlalu besar untuk dihitung dengan cepat.

Kiat umum: Saya menyimpan sebagian besar data di antara dua basis data, yang pertama adalah data deret waktu lurus dan dinormalisasi. Basis data kedua saya sangat tidak normal dan berisi data pra-agregat. Secepat sistem saya, saya tidak buta terhadap fakta bahwa pengguna bahkan tidak ingin menunggu 30 detik untuk memuat laporan - bahkan jika saya pribadi berpikir 30 detik untuk menggerogoti 2 TB data sangat cepat.

Untuk menguraikan mengapa saya merekomendasikan menyimpan jam terpisah dari tanggal, berikut adalah beberapa alasan mengapa saya melakukannya dengan cara itu:

1. Cara data listrik disajikan oleh Hour Ending- Oleh karena itu, 01:00 sebenarnya adalah rata-rata daya listrik untuk jam sebelumnya dan 00:00 adalah Akhir Jam 24. (Ini penting karena Anda benar-benar harus mencari dua tanggal untuk memasukkan nilai 24 jam - hari Anda sedang mencari ditambah tanda pertama pada hari berikutnya.) Namun, data cuaca sebenarnya disajikan secara maju (aktual dan perkiraan untuk jam berikutnya). Dalam pengalaman saya dengan data ini, konsumen ingin menganalisis pengaruh cuaca terhadap harga / permintaan daya. Jika Anda menggunakan perbandingan tanggal langsung, Anda sebenarnya akan membandingkan harga rata-rata untuk jam sebelumnya dengan suhu rata-rata untuk jam berikutnya, meskipun perangko waktunya sama.DATETIME kolom.
2. Performa. Saya akan mengatakan setidaknya 90% dari laporan yang saya hasilkan adalah grafik, biasanya memplot harga terhadap jam baik untuk satu tanggal atau untuk berbagai tanggal. Harus membagi waktu dari tanggal dapat menghambat kecepatan kueri yang digunakan untuk menghasilkan laporan tergantung pada rentang tanggal yang ingin Anda lihat. Sudah lazim bagi konsumen untuk ingin melihat satu tanggal, Tahun ke Tahun selama 30 tahun terakhir (sebenarnya untuk cuaca ini diperlukan untuk menghasilkan normal 30 tahun) - ini bisa lambat. Tentu saja Anda dapat mengoptimalkan kueri Anda dan menambahkan indeks, dan percayalah, saya memiliki beberapa indeks gila yang saya lebih suka tidak miliki tetapi itu membuat sistem berjalan cepat.
3. Produktifitas. Aku benci harus menulis kode yang sama lebih dari sekali. Saya dulu menyimpan tanggal dan waktu di kolom yang sama, sampai saya harus menulis permintaan yang sama berulang-ulang untuk mengekstrak bagian waktu. Setelah beberapa saat saya muak harus melakukan ini dan mengekstraknya ke kolomnya sendiri. Semakin sedikit kode yang Anda tulis, semakin kecil peluang ada kesalahan di dalamnya. Juga, harus menulis lebih sedikit kode berarti Anda bisa mengeluarkan laporan lebih cepat, tidak ada yang ingin menunggu sepanjang hari untuk laporan.
4. Pengguna akhir. Tidak semua pengguna akhir adalah pengguna yang kuat (yaitu tahu cara menulis SQL). Memiliki data yang sudah disimpan dalam format yang dapat mereka bawa ke Excel (atau alat serupa lainnya) dengan sedikit usaha akan membuat Anda menjadi pahlawan di kantor. Jika pengguna tidak dapat mengakses atau memanipulasi data dengan mudah, mereka tidak akan menggunakan sistem Anda. Percayalah, saya merancang sistem yang sempurna beberapa tahun yang lalu dan tidak ada yang menggunakannya karena alasan ini. Desain basis data bukan hanya tentang mematuhi seperangkat aturan / pedoman yang telah ditentukan, ini tentang membuat sistem dapat digunakan.

Seperti yang saya katakan di atas, ini semua didasarkan pada pengalaman pribadi saya, dan biarkan saya memberi tahu Anda, sudah beberapa tahun yang sulit dan banyak perancangan ulang untuk sampai ke tempat saya sekarang. Jangan lakukan apa yang saya lakukan, belajar dari kesalahan saya dan pastikan Anda melibatkan pengguna akhir sistem Anda (atau pengembang, penulis laporan dll ...) ketika membuat keputusan tentang database Anda.

Indeks PostgreSQL dan BRIN

Uji sendiri. Ini bukan masalah pada laptop berusia 5 tahun dengan SSD.

EXPLAIN ANALYZE
CREATE TABLE electrothingy
AS
  SELECT
    x::int AS id,
    (x::int % 20000)::int AS locid,  -- fake location ids in the range of 1-20000
    now() AS tsin,                   -- static timestmap
    97.5::numeric(5,2) AS temp,      -- static temp
    x::int AS usage                  -- usage the same as id not sure what we want here.
  FROM generate_series(1,1728000000) -- for 1.7 billion rows
    AS gs(x);

                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series gs  (cost=0.00..15.00 rows=1000 width=4) (actual time=173119.796..750391.668 rows=1728000000 loops=1)
 Planning time: 0.099 ms
 Execution time: 1343954.446 ms
(3 rows)

Jadi butuh 22 menit untuk membuat tabel. Sebagian besar, karena meja adalah 97GB sederhana. Selanjutnya kita buat indeks,

CREATE INDEX ON electrothingy USING brin (tsin);
CREATE INDEX ON electrothingy USING brin (id);    
VACUUM ANALYZE electrothingy;

Butuh waktu lama untuk membuat indeks juga. Meskipun karena mereka BRIN mereka hanya 2-3 MB dan mereka menyimpan dengan mudah di ram. Membaca 96 GB tidak instan, tetapi itu bukan masalah nyata untuk laptop saya di beban kerja Anda.

Sekarang kita query itu.

explain analyze
SELECT max(temp)
FROM electrothingy
WHERE id BETWEEN 1000000 AND 1001000;
                                                                 QUERY PLAN                                                                  
---------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=5245.22..5245.23 rows=1 width=7) (actual time=42.317..42.317 rows=1 loops=1)
   ->  Bitmap Heap Scan on electrothingy  (cost=1282.17..5242.73 rows=993 width=7) (actual time=40.619..42.158 rows=1001 loops=1)
         Recheck Cond: ((id >= 1000000) AND (id <= 1001000))
         Rows Removed by Index Recheck: 16407
         Heap Blocks: lossy=128
         ->  Bitmap Index Scan on electrothingy_id_idx  (cost=0.00..1281.93 rows=993 width=0) (actual time=39.769..39.769 rows=1280 loops=1)
               Index Cond: ((id >= 1000000) AND (id <= 1001000))
 Planning time: 0.238 ms
 Execution time: 42.373 ms
(9 rows)

Perbarui dengan cap waktu

Di sini kita menghasilkan tabel dengan cap waktu yang berbeda untuk memenuhi permintaan untuk mengindeks dan mencari pada kolom cap waktu, pembuatannya membutuhkan waktu sedikit lebih lama karena to_timestamp(int)jauh lebih lambat daripada now()(yang di-cache untuk transaksi)

EXPLAIN ANALYZE
CREATE TABLE electrothingy
AS
  SELECT
    x::int AS id,
    (x::int % 20000)::int AS locid,
    -- here we use to_timestamp rather than now(), we
    -- this calculates seconds since epoch using the gs(x) as the offset
    to_timestamp(x::int) AS tsin,
    97.5::numeric(5,2) AS temp,
    x::int AS usage
  FROM generate_series(1,1728000000)
    AS gs(x);

                                                               QUERY PLAN                                                                
-----------------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series gs  (cost=0.00..17.50 rows=1000 width=4) (actual time=176163.107..5891430.759 rows=1728000000 loops=1)
 Planning time: 0.607 ms
 Execution time: 7147449.908 ms
(3 rows)

Sekarang kita dapat menjalankan kueri pada nilai timestamp, sebagai gantinya,

explain analyze
SELECT count(*), min(temp), max(temp)
FROM electrothingy WHERE tsin BETWEEN '1974-01-01' AND '1974-01-02';
                                                                        QUERY PLAN                                                                         
-----------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=296073.83..296073.84 rows=1 width=7) (actual time=83.243..83.243 rows=1 loops=1)
   ->  Bitmap Heap Scan on electrothingy  (cost=2460.86..295490.76 rows=77743 width=7) (actual time=41.466..59.442 rows=86401 loops=1)
         Recheck Cond: ((tsin >= '1974-01-01 00:00:00-06'::timestamp with time zone) AND (tsin <= '1974-01-02 00:00:00-06'::timestamp with time zone))
         Rows Removed by Index Recheck: 18047
         Heap Blocks: lossy=768
         ->  Bitmap Index Scan on electrothingy_tsin_idx  (cost=0.00..2441.43 rows=77743 width=0) (actual time=40.217..40.217 rows=7680 loops=1)
               Index Cond: ((tsin >= '1974-01-01 00:00:00-06'::timestamp with time zone) AND (tsin <= '1974-01-02 00:00:00-06'::timestamp with time zone))
 Planning time: 0.140 ms
 Execution time: 83.321 ms
(9 rows)

Hasil:

 count |  min  |  max  
-------+-------+-------
 86401 | 97.50 | 97.50
(1 row)

Jadi dalam 83.321 ms kita bisa mengumpulkan 86.401 catatan dalam sebuah tabel dengan 1,7 Miliar baris. Itu harus masuk akal.

Jam berakhir

Menghitung akhir jam juga cukup mudah, pangkas stempel waktu, lalu tambahkan satu jam.

SELECT date_trunc('hour', tsin) + '1 hour' AS tsin,
  count(*),
  min(temp),
  max(temp)
FROM electrothingy
WHERE tsin >= '1974-01-01'
  AND tsin < '1974-01-02'
GROUP BY date_trunc('hour', tsin)
ORDER BY 1;
          tsin          | count |  min  |  max  
------------------------+-------+-------+-------
 1974-01-01 01:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 02:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 03:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 04:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 05:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 06:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 07:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 08:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 09:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 10:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 11:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 12:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 13:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 14:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 15:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 16:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 17:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 18:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 19:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 20:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 21:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 22:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 23:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-02 00:00:00-06 |  3600 | 97.50 | 97.50
(24 rows)

Time: 116.695 ms

Penting untuk dicatat, bahwa itu tidak menggunakan indeks pada agregasi, meskipun bisa. Jika itu biasanya permintaan Anda, Anda mungkin ingin BRIN di date_trunc('hour', tsin)sana terletak masalah kecil yang date_trunctidak dapat diubah sehingga Anda harus terlebih dahulu membungkusnya untuk membuatnya jadi.

Partisi

Poin penting lain dari informasi tentang PostgreSQL adalah bahwa PG 10 membawa partisi DDL . Jadi, Anda dapat, misalnya, dengan mudah membuat partisi untuk setiap tahun. Memecah database sederhana Anda menjadi yang kecil yang kecil. Dengan demikian, Anda harus dapat menggunakan dan mempertahankan indeks btree daripada BRIN yang akan lebih cepat.

CREATE TABLE electrothingy_y2016 PARTITION OF electrothingy
    FOR VALUES FROM ('2016-01-01') TO ('2017-01-01');

Atau terserah.

Saya kagum pada saya bahwa tidak ada orang di sini yang menyebutkan benchmarking - sampai @EvanCarroll datang dengan kontribusinya yang luar biasa!

Jika saya jadi Anda, saya akan meluangkan waktu (dan ya, saya tahu itu komoditas berharga!) Menyiapkan sistem, menjalankan apa yang Anda pikir akan (dapatkan input pengguna akhir di sini!), Katakanlah, 10 pertanyaan paling umum Anda.

Pikiran saya sendiri:

Solusi NoSQL dapat bekerja dengan sangat baik untuk kasus penggunaan tertentu tetapi seringkali tidak fleksibel untuk permintaan ad-hoc. Untuk penjelasan lucu tentang NoSQL oleh Brian Aker - mantan kepala arsitek MySQL, lihat di sini !

Saya setuju dengan @BrBrownstone bahwa data Anda sangat cocok untuk solusi relasional (dan pendapat ini telah dikonfirmasi oleh Evan Carroll )!

Jika saya berkomitmen untuk pengeluaran apa pun, itu akan menjadi teknologi disk saya! Saya akan menghabiskan uang yang saya miliki untuk NAS atau SAN atau mungkin beberapa disk SSD untuk menampung data agregat yang jarang saya tulis!

Pertama saya akan melihat apa yang saya miliki sekarang . Jalankan beberapa tes dan tunjukkan hasilnya kepada pembuat keputusan. Anda sudah memiliki proxy dalam bentuk karya EC ! Tapi, satu atau dua tes cepat dikocok bersama pada perangkat keras Anda sendiri akan lebih meyakinkan!

Kemudian pikirkan tentang pengeluaran uang! Jika Anda akan menghabiskan uang, lihat perangkat keras lebih dulu daripada perangkat lunak. AFAIK, Anda dapat menyewa teknologi disk untuk masa uji coba, atau lebih baik lagi, memutar beberapa konsep bukti di cloud.

Port of call pertama saya pribadi untuk sebuah proyek seperti ini adalah PostgreSQL. Itu bukan untuk mengatakan bahwa saya akan mengesampingkan solusi berpemilik, tetapi hukum fisika dan disk adalah sama untuk semua orang! "Yae cannae beet the law of 'Jim fisika" :-)

Jika Anda belum melakukannya, lihatlah DBMS deret waktu, karena ini dioptimalkan untuk menyimpan dan menanyakan data di mana fokus utama adalah jenis tanggal / waktu. Biasanya basis data seri waktu digunakan untuk merekam data dalam rentang menit / detik / sub-detik, jadi saya tidak yakin apakah itu masih sesuai untuk kenaikan per jam. Yang mengatakan, jenis DBMS ini tampaknya layak untuk dilihat. Saat ini InfluxDB tampaknya menjadi basis data time series yang paling mapan dan banyak digunakan.

Jelas ini bukan masalah NoSQL, tapi saya akan menyarankan bahwa sementara solusi RDBMS akan bekerja, saya pikir pendekatan OLAP akan jauh lebih baik dan mengingat rentang data yang sangat terbatas, saya akan sangat menyarankan menyelidiki penggunaan DB berbasis kolom ketimbang yang berbasis baris. Pikirkan seperti ini, Anda mungkin memiliki 1,7 miliar keping data, tetapi Anda hanya perlu 5 bit untuk mengindeks setiap nilai jam atau hari dalam sebulan.

Saya memiliki pengalaman dengan domain masalah serupa di mana Sybase IQ (sekarang SAP IQ) digunakan untuk menyimpan hingga 300 juta counter per jam data manajemen kinerja peralatan telekomunikasi, tetapi saya ragu apakah Anda memiliki anggaran untuk solusi semacam itu. Di arena open source, MariaDB ColumnStore adalah kandidat yang sangat menjanjikan, tetapi saya akan merekomendasikan juga menyelidiki MonetDB.

Karena kinerja kueri adalah penggerak utama bagi Anda, berikan pertimbangan tentang bagaimana kueri akan diungkapkan. Di sinilah OLAP dan RDBMS menunjukkan perbedaan terbesar mereka: - dengan OLAP Anda menormalkan kinerja permintaan, bukan untuk mengurangi pengulangan, mengurangi penyimpanan atau bahkan untuk menegakkan konsistensi. Jadi selain stempel waktu asli (Anda masih ingat untuk menangkap zona waktunya, saya harap?) Memiliki bidang terpisah untuk stempel waktu UTC, yang lain untuk tanggal dan waktu, dan lebih banyak lagi untuk tahun, bulan, hari, jam, menit dan offset UTC. Jika Anda memiliki informasi tambahan tentang lokasi, jangan ragu untuk menyimpannya di tabel lokasi terpisah yang dapat dilihat sesuai permintaan dan jangan ragu untuk menyimpan kunci ke tabel itu di catatan utama Anda tetapi simpan nama lokasi lengkap di tabel utama Anda sebagai baiklah, setelah semua,

Sebagai saran terakhir, gunakan tabel terpisah untuk data agregat populer dan gunakan pekerjaan batch untuk mengisinya, dengan cara itu Anda tidak harus mengulang latihan untuk masing-masing dan setiap laporan yang menggunakan nilai agregat dan membuat kueri yang membandingkan saat ini dengan historis atau historis hingga historis jauh lebih mudah dan lebih cepat.