Büyük miktarda elektrik ve sıcaklık verilerini depolamak ve analiz etmek için gereken bir uygulama yazıyorum.

Temelde, son birkaç yıldır ve on binlerce lokasyon için uzun yıllar boyunca büyük miktarlarda saatlik elektrik kullanım ölçümlerini kaydetmem ve ardından verileri çok karmaşık olmayan bir şekilde analiz etmem gerekiyor.

Saklamam gereken bilgiler (şimdilik) Konum Kimliği, Zaman Damgası (Tarih ve Saat), Sıcaklık ve Elektrik Kullanımı.

Depolanması gereken verilerin miktarı hakkında, bu yaklaşık bir değerdir, ancak bu satırlar boyunca bir şey:
20 000+ konum, ayda 720 kayıt (saatlik ölçümler, ayda yaklaşık 720 saat), 120 ay (10 yıl önce ) ve gelecek yıllar boyunca. Basit hesaplamalar aşağıdaki sonuçları verir:

20 000 konum x 720 kayıt x 120 ay (10 yıl önce) = 1 728 000 000 kayıt .

Bunlar geçmiş kayıtlardır, aylık olarak yeni kayıtlar alınacaktır, bu yüzden ayda yaklaşık 20 000 x 720 = 14 400 000 yeni kayıt .

Toplam lokasyonlar da istikrarlı bir şekilde büyüyecek.

Tüm bu verilerde, aşağıdaki işlemlerin gerçekleştirilmesi gerekecektir:

1. Belirli bir tarih ve zaman periyodu için verileri alın: 01.01.2013 ve 01.01.2017 tarihleri ​​ile 07:00 ve 13:00 saatleri arasında belirli bir Konum Kimliği için tüm kayıtlar.
2. Belirli bir tarih ve zaman aralığı için basit matematiksel işlemler, örn. MIN, MAX ve AVG sıcaklığı ve belirli bir Konum Kimliği için elektrik kullanımı ve 5 yıl boyunca 07:00 - 13:00 arası.

Veriler aylık olarak yazılacak, ancak yüzlerce kullanıcı tarafından (en azından) sürekli olarak okunacak, bu nedenle okuma hızı çok daha önemli.

NoSQL veritabanları hakkında hiçbir tecrübem yok, ancak topladıklarımdan itibaren, burada kullanmak için en iyi çözüm. En popüler NoSQL veritabanlarını okudum, ancak oldukça farklı olduklarından ve aynı zamanda çok farklı masa mimarisine izin verdiklerinden, kullanılacak en iyi veritabanının ne olduğuna karar veremedim.

Başlıca seçimlerim Cassandra ve MongoDB idi, ancak çok sınırlı bir bilgiye sahip olduğumdan ve büyük veri ve NoSQL konusunda gerçek bir deneyimim olmadığından emin değilim. Ayrıca PostreSQL'in bu tür verileri iyi kullandığını da okudum.

Sorularım aşağıdaki gibidir:

1. Bu kadar büyük miktarda veri için NoSQL veritabanı kullanmalı mıyım? Değilse MySQL'e sadık kalabilir miyim?
2. Hangi veritabanını kullanmalıyım?
3. Verileri belirli saat ve tarih dönemlerinde hızlıca almak ve işlemek için tarih ve saati ayrı, dizine eklenmiş (mümkünse) sütunlarda mı tutmalıyım, yoksa zaman damgasını tek bir sütunda tutarak mı?
4. Burada bir zaman serisi veri modelleme yaklaşımı uygun mu ve eğer değilse iyi bir masa tasarımı için bana işaretçi verebilir misiniz?

Teşekkür ederim.

Bu tam olarak her gün yaptığım şey, saatlik verileri kullanmak yerine 5 dakikalık verileri kullanıyorum. Her gün yaklaşık 200 milyon kayıt indiriyorum, bu yüzden burada bahsettiğiniz miktar bir sorun değil. 5 dakikalık veri yaklaşık 2 TB boyutundadır ve hava durumuna göre 50 yıl geriye saat bazında geri dönüyor. Öyleyse size tecrübelerime dayanarak soruları cevaplayayım:

1. Bunun için NoSQL kullanmayın. Veriler yüksek düzeyde yapılandırılmıştır ve ilişkisel bir veritabanına mükemmel şekilde uyar.
2. Şahsen SQL Server 2016 kullanıyorum ve bu veri hacmi boyunca hesaplamalar yaparken hiçbir sorunum yok. İşime başladığımda aslında PostgreSQL örneğindeydi ve küçük bir AWS örneğindeki gibi veri hacmini kaldıramadı.
3. Yapardım derece tarihi saat kısmını çıkaran ve bugüne kendisinden ayrı depolanması önerilir. İnan bana hatalarımdan ders al!
4. Verileri liste halinde saklı tutarım (TARİH, SAAT, DATAPOINT_ID, DEĞER) ama insanların verileri yorumlamak istemeleri böyle değildir. Verilere ve büyük miktardaki döndürmeye karşı bazı korkunç sorgular için hazırlıklı olun. Anında hesaplamak için çok büyük olan sonuç kümeleri için normalize edilmiş bir tablo oluşturmaktan korkmayın.

Genel ipucu: Verilerin çoğunu iki veritabanı arasında depolarım, ilki yukarı yönlü zaman serisi verileridir ve normalleştirilir. İkinci veritabanım çok normalleştirildi ve önceden toplanmış veriler içeriyor. Sistemim ne kadar hızlı olursa, kullanıcıların bir raporun yüklenmesi için 30 saniye beklemesini bile istememeleri gerçeğine kör değilim - şahsen 2 TB veriyi kesmek için 30 saniyenin çok hızlı olduğunu düşünmeme rağmen.

Saati neden tarihten ayrı olarak saklamayı önerdiğimi açıklamak için, işte bu şekilde yapmamın birkaç nedeni:

1. Elektriksel verinin sunulma şekli Saat Sonuna Göredir- bu nedenle, 01:00 aslında önceki saatteki elektrik gücünün ortalamasıdır ve 00:00 Saat Sonu 24'tür. (Bu önemlidir, çünkü aslında 24 saatlik değeri içerecek iki tarih aramak zorundasınızdır - artı ertesi günün ilk damgasını arıyorlar.) Ancak, hava durumu verileri aslında ileri bir şekilde sunuluyor (bir sonraki saat için gerçek ve tahmini). Bu verilerle ilgili tecrübelerime göre, tüketiciler havanın güç fiyatı / talebi üzerindeki etkisini analiz etmek istiyor. Düzgün bir tarih karşılaştırması kullanacak olsaydınız, zaman damgaları aynı olsa bile, önceki saat için ortalama fiyatı ve sonraki saatin ortalama sıcaklığını karşılaştıracaksınız.DATETIME kolon, sütun.
2. Verim. Ürettiğim raporların en az% 90'ının grafik olduğunu söyleyebilirim, normalde fiyatı tek bir tarih veya bir dizi tarih için saate göre çizerim. Saati zamandan ayırmak, görmek istediğiniz tarih aralığına bağlı olarak rapor oluşturmak için kullanılan sorgunun hızını azaltabilir. Tüketicilerin son 30 yıl için Yıldan Yıla tek bir tarih görmek istemeleri nadir değildir (aslında hava şartları için bu 30 yıllık normları üretmek için gereklidir) - bu yavaş olabilir. Tabii ki, sorgunuzu optimize edebilir ve indeksler ekleyebilir ve bana güvenmek istemezdim ama delicesine göre dizginler var ama sistemin hızlı çalışmasını sağlar.
3. Üretkenlik. Aynı kod parçasını bir defadan fazla yazmaktan nefret ediyorum. Tarih bölümünü ve saatini aynı sütunda saklardım, zaman zaman bölümünü çıkarmak için aynı sorguyu tekrar tekrar yazmak zorunda kalana kadar. Bir süre sonra bunu yapmaktan bıktım ve kendi sütununa çıkarttım. Ne kadar az kod yazmanız gerekiyorsa o kadar az hata yapma ihtimaliniz o kadar az olur. Ayrıca, daha az kod yazmanız, raporlarınızı daha hızlı alabileceğiniz anlamına gelir; hiç kimse raporlar için bütün gün beklemek istemez.
4. Son kullanıcılar. Tüm son kullanıcılar uzman kullanıcılar değildir (örneğin, SQL yazmayı bilirler). Verileri Excel'e (veya benzeri bir araca) en az çabayla getirebilecekleri bir biçimde depolamak sizi ofiste bir kahraman haline getirecektir. Kullanıcılar verilere kolayca erişemiyorsa veya değiştiremiyorsa, sisteminizi kullanmayacaktır. İnan bana, mükemmel sistemi birkaç yıl önce tasarladım ve bu sebeple kimse kullanmadı. Veri tabanı tasarımı sadece önceden tanımlanmış bir kurallar / kılavuzlar dizisine uymakla kalmaz, sistemi kullanılabilir hale getirmekle de ilgilidir.

Yukarıda da belirttiğim gibi, bunların hepsi kişisel deneyimime dayanıyor ve size söyleyeyim, şu an bulunduğum yere gelmek çok zor bir kaç yıl oldu. Yaptıklarımı yapmayın, hatalarımdan ders alın ve veritabanınızla ilgili kararlar alırken sisteminizin son kullanıcılarını (veya geliştiricileri, rapor yazarlarını vb.) Dahil ettiğinizden emin olun.

PostgreSQL ve BRIN indeksleri

Kendin için test et. Bu 5 yaşında bir dizüstü bilgisayarda bir ssd ile sorun değil.

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)

Bu yüzden tabloyu oluşturmak için 22 dakika sürdü. Büyük ölçüde, çünkü masa mütevazı bir 97GB. Sonra dizinleri oluşturacağız,

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

Dizinlerin oluşturulması da çok zaman aldı. BRIN oldukları için sadece 2-3 MB'lar ve koç içinde kolayca saklanıyorlar. 96 GB okuma anlık değil, ancak iş yükünüzdeki dizüstü bilgisayarım için gerçek bir sorun değil.

Şimdi sorgularız.

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)

Zaman damgalarıyla güncelleme

Burada, bir zaman damgası sütununda indeksleme ve arama talebini yerine getirmek için farklı zaman damgalarına sahip bir tablo oluşturuyoruz, oluşturma işlemi biraz daha uzun sürüyor çünkü işlem (işlem için önbelleğe alınmış) to_timestamp(int)büyük ölçüde daha yavaşnow()

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)

Şimdi bunun yerine zaman damgası değerinde bir sorgu çalıştırabiliriz.

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)

Sonuç:

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

Bu yüzden 83.321 ms'de, 1.7 Milyar sıra içeren bir tabloda 86.401 kayıt toplayabiliriz. Bu makul olmalı.

Saat biten

Saatin sonunu hesaplamak da oldukça kolaydır, zaman damgalarını kısaltın ve ardından sadece bir saat ekleyin.

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

Ancak, toplamada bir dizin kullanmadığını, ancak yapabildiğine dikkat etmek önemlidir. Bu genellikle sorgunuzsa, muhtemelen üzerinde bir BRIN istiyorsanız, bu konuda date_trunc('hour', tsin)küçük bir sorun var.date_trunc değişmez olmadığı yüzden bunu yapabilmek için önce onu sarmanız gerekir.

Bölümleme

PostgreSQL hakkındaki bir diğer önemli bilgi noktası ise, PG 10'un DDL'ye bölümleme getirmesidir . Böylece, örneğin, her yıl için kolayca bölümler oluşturabilirsiniz. Mütevazı veritabanınızı küçük olanlara ayırın. Bunu yaparken, daha hızlı olacak olan BRIN yerine kullanımı kullanıp btree endekslerini kullanabilmelisiniz.

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

Ya da her neyse.

Buradaki kimsenin kıyaslamadan bahsetmemesi beni şaşırtıyor - bu, @EvanCarroll mükemmel katkısı ile gelene kadar !

Yerinde olsam, biraz zaman harcardım (ve evet, bunun kıymetli bir ürün olduğunu biliyorum!) Sistemleri kurarak, olacağını düşündüğün şeyi çalıştırarak (burada son kullanıcı girişi yap!), En sık sorduğun 10 soruyu söyle.

Kendi düşüncelerim:

NoSQL çözümleri belirli kullanım durumları için çok iyi çalışabilir, ancak geçici sorgular için esnek değildir. MySQL'in eski mimar mimarı Brian Aker'in NoSQL'i eğlenceli bir şekilde ele alması için, buraya bakın . !

@ BayBrownstone ile verilerinizin ilişkisel bir çözüme çok uygun olduğuna katılıyorum (ve bu görüş Evan Carroll tarafından onaylandı )!

Herhangi bir harcamayı taahhüt edersem, disk teknolojim olurdu! Elimdeki herhangi bir parayı nadiren yazılı toplam verilerimi tutmak için NAS ya da SAN ya da bazı SSD disklerine harcıyordum!

İlk önce şu an elimde olanlara bakardım . Bazı testler yapın ve sonuçları karar vericilere gösterin. Zaten EC'nin çalışması şeklinde bir vekiliniz var ! Ancak, kendi donanımınıza bir araya çırpınan hızlı bir test daha ikna edici olacaktır!

O zaman para harcamayı düşünün! Para harcayacaksanız, önce yazılım yerine donanıma bakın. AFAIK, deneme süresi boyunca disk teknolojisini işe alabilir ya da daha iyisi, bulutun üzerinde birkaç kavram kanıtı oluşturabilirsiniz.

Bunun gibi bir proje için kendi kişisel ilk bağlantı limanım PostgreSQL olacaktır. Bu, tescilli bir çözümü reddedeceğimi söylemek değildir, ancak fizik ve disk yasaları herkes için aynıdır! "Yae canee 'fizik Jim yasaları pancar" :-)

Henüz yapmadıysanız, DBMS zaman serisine bakın, çünkü birincil odağın tarih / saat türü olduğu yerlerde veri depolamak ve sorgulamak için optimize edilmiştir. Tipik olarak zaman serisi veritabanları dakika / saniye / alt saniye aralıklarında verileri kaydetmek için kullanılır, bu nedenle saatlik artışlar için hala uygun olup olmadığından emin değilim. Bununla birlikte, bu DBMS türünün araştırılmaya değer olduğu görülüyor. Şu anda InfluxDB en köklü ve yaygın olarak kullanılan zaman serisi veritabanı gibi görünüyor.

Açıkçası bu bir NoSQL sorunu değil, ancak bir RDBMS çözümü işe yarayacak olsa da, bir OLAP yaklaşımının daha uygun olacağını ve ilgili çok sınırlı veri aralıkları verildiğinde, sütun temelli bir DB kullanımını araştıracağımı düşünüyorum. bunun yerine satır tabanlı olanı. Bu şekilde düşünün, 1.7 milyar parça veriye sahip olabilirsiniz, ancak ayın veya günün her bir olası değerini indekslemek için hala 5 bit yeterli olacaktır.

Sybase IQ'nun (şimdiki SAP IQ) saatte bir 300 milyon sayaçlı telekomünikasyon ekipmanı performans yönetimi verilerini depolamak için kullanıldığı benzer bir sorun alanıyla ilgili deneyimim var, ancak bu tür bir çözüm için bütçeniz olup olmadığından şüpheliyim. Açık kaynak arenada, MariaDB ColumnStore çok umut verici bir adaydır, ancak MonetDB'nin de araştırılmasını tavsiye ederim.

Sorgu performansı sizin için önemli bir sürücü olduğundan, sorguların nasıl ifade edileceğine dikkat edin. OLAP ve RDBMS'nin en büyük farklarını gösterdikleri yer: - OLAP ile sorgu performansını normalleştiriyor, tekrarlamayı azaltmak, depolamayı azaltmak ve hatta tutarlılığı sağlamak için normalleştiriyorsunuz. Böylece, orijinal zaman damgasına ek olarak (umarım zaman dilimini yakalamayı hatırladınız mı?) UTC zaman damgası için ayrı bir alana, tarih ve saat için diğerlerine ve yine yıl, ay, gün, saat, dakika için ve UTC ofseti. Konumlar hakkında ek bilgiye sahipseniz, talep üzerine aranabilecek ayrı bir konum tablosunda saklamaktan çekinmeyin ve bu tablonun anahtarını ana kayıtlarınızda tutmaktan çekinmeyin, ancak tam konum adını ana tablonuzda saklayın. sonuçta

Son bir öneri olarak, popüler toplanmış veriler için ayrı tablolar kullanın ve bunları doldurmak için toplu işlerden yararlanın; bu şekilde, toplanmış bir değer kullanan her bir rapor için alıştırmayı tekrarlamanıza gerek kalmaz ve güncelle geçmiş ya da geçmişi karşılaştıran sorgular yapar. tarihselden çok daha kolay ve çok, çok daha hızlı.