PostgreSQL'de yuvarlanan verileri depolama ve sorgulama

Ben bir PostgreSQL veritabanına konuyor hava modeli veri büyük miktarda var. Makine 8 çekirdeğe ve 16 GB RAM'e sahiptir. PostGIS 2.1 ile PostgreSQL 9.3 kullanıyorum. Her tablonun farklı hava durumu verileri (sıcaklık, çiy noktası, rüzgar vb.) Olacaktır. Her tablonun 6-7 sütunu olacaktır: enlem, boylam, nokta geometrisi, yükseklik, modelin ilgili olduğu tarih ve 1-2 veri değeri. Veriler öncelikle bir sınırlama kutusu için zamana ve yüksekliğe göre sorgulanacaktır. Tablo başına yaklaşık 145.757.360 satır olacaktır (şu andan daha eski veriler artık alakalı değildir silinecektir). Kabaca dizin boyutunu yaklaşık 10 GB olacak şekilde tahmin ediyorum. (Bu, 52 bayt veri artı satır başına 23 bayt ek yüktür). Yeni model verileri kullanıma sunuldukça veriler düzenli olarak güncellenecek / eklenecektir. Not:

Bu iki plana bakıyorum:

Nokta geometrisi için ek bir indeksle (tarih, yükseklik) endeksleyin ve kümeleyin. Eski satırları silen, vakum / analiz çalıştıran ve kümeleri yeniden düzenleyen düzenli bir cron işi çalıştırın.
Tarih saatine göre bölümleme ve ardından geometri üzerinde bir dizinle tablo başına yükseklik ile küme ve dizin. İleriye yeni tablolar eklemek ve eski tabloları bırakmak için düzenli bir cron işi çalıştırın.

Daha ileri,

Yani, bir masa bırakmanın çok daha verimli, silme ve vakumlama olduğunu biliyorum. Aksi takdirde performans artışı görür müyüm?
Alakasız olarak silinene kadar tüm tablolar eşit olarak güncellendiğinde ve seçildiğinde bölümler uygun mudur?

Verileri iletirken seçimler kümelenmiş dizinden daha hızlı olur mu? Aynı anda birden fazla istek yapılıyorsa cevap değişir mi?

Teşekkür ederim. Umarım gerekli tüm verileri koyarım. Değilse bana bildirin ve ben ekleyeceğim.

— bshender
kaynak

Hata! Bu dar satırlar, PostgreSQL'in büyük satır başlıklarının gerçekten incinmeye başladığı yerdir. Yazık ki kaldırılabilecek pek bir şey yok; biz kaybedebilir gibi değil xminya xmax, vb bir özellik var olabilir büyük bir anlaşma daha uygun bu gibi şeyler yapacaktır minmax indeksleri denilen muhtemelen sizi heyecanlandıracak 9.4, dönüştürebilmek.

— Craig Ringer

Şu kombinasyon tekrarlanıyor mu: "enlem, boylam, nokta geometrisi, yükseklik". Evetse, başka bir tabloya normalleştirmek biraz yer tasarrufu sağlayabilir.

— AK

Sadece çok az. PostGIS geometrisi ikili bir dizidir ve insan tarafından okunamaz. Çıktıda bu değerleri türetebildim, ama sonra onları kümelendiremedim. Küme için bir GeoHash kullanabilirsiniz, ancak artık lat lon olacağını daha okunabilir değil. Ama her iki şekilde de alan sorun değil. Doldurabildiğim kadar çok terrabayt teklif ettiler. Sorun, terrabytes'i hızlı bir şekilde sorgulayamıyorum. Veritabanının kendisi büyük ölçüde işlemsiz olacaktır. Yalnızca iki komut dosyasının yazma erişimi olacaktır. Diğer her şey kesinlikle salt okunurdur.

— bshender

Craig: Çıktıkları zaman onlarla deneme yapmayı dört gözle bekliyorum. 9.3'te kurulumum hakkında ne düşünüyorsun?

— bshender

Lütfen iki parça bilgi verebilir misiniz: 1) Sizin için en önemli olan şey, ekleme hızı veya sorgu hızı? 2) En sık sorulan sorular nelerdir?

— Thomas Kejser

Her şey göz önüne alındığında, seçenek 2 ile giderdim. Tarihler eşit olarak seçilecek, ancak belirli bir sorgu için sadece bir veya iki tarih bölümünün yer alacağını tahmin edeceğim. Coğrafi konum ve tarihte bölümleme yapamayacağınız bir utanç ki bu ideal olacaktır. Sınırlayıcı kutular yeterince küçükse, yükseklik yine de coğrafi konum ile ilişkili olma eğilimindedir.

Mevcut seçenekler göz önüne alındığında, daha temiz veri işlemleri ve günlük vakumdan kaçınmak iyi bir şeydir.

Seçimler sunmak seçenek 1 ile daha hızlı olabilir , ancak muhtemelen bir yıkama olacağından şüpheleniyorum. Seçenek 1 ile, aynı tarih ve yüksekliğe sahip kayıtlar büyük bir kümelenmiş dizine yan yana yerleştirilir. Seçenek 2 ile, aynı tarih ve yüksekliğe sahip kayıtlar daha küçük kümelenmiş dizinlerde yan yana yerleştirilir.

— Carlos Bueno
kaynak