Yüksek hacimli işlemler ve Veri ambarı için PostgreSQL

PostgreSQL için oldukça yeniyim, daha önce hiç kullanmadan büyük bir dağıtım yapmadım. Ancak, kurumsal çözümlerde iyi bir deneyime sahibim ve PostgreSQL kullanarak öğrendiklerimin bazılarını uygulamaya çalışıyorum.

Çok sayıda veri ve trafiği işleyecek boyutta bir sitem var. Altyapı, EC2 örnekleri ve EBS hacimleri kullanılarak amazon (AWS) kullanılarak oluşturulacaktır.

Tasarım, analiz ve raporlamayı idare etmek için iki veri tabanına, ana işlem veritabanına ve veri ambarına sahip olmalıdır.

Ana işlem veritabanı

canlı web sitesi için kullanılacaksa, site eşzamanlı kullanıcıları ölçeklendirmek için birden fazla düğüm üzerine kurulmuştur. Temelde bu durum için veritabanının okuma işlemlerinde son derece hızlı olmasını istiyoruz, yıllık% 30 büyüme ile 100GB'den fazla veri bekliyoruz. Bu noktada, iki EC2 sunucusu kullanmayı planlıyoruz ( ve ihtiyaç duyduğumuzda daha fazlasını ekliyoruz ).

sorum, yukarıdaki gereksinimler için önerilen kurulum nedir? Ayrıca, tablo ve birim bölümlemesini yönetmenin bir yolu var mı? kurulumu kullanmak için öneriler var mı?

Veri ambarı veritabanı

Esas olarak zaman boyutunda ana işlem veritabanından tüm verileri yakalamak için kullanılacaktır. böylece, ana veritabanından silinen kayıtlar bile DWH'de yakalanır. Bu nedenle, veriler çok büyük ve büyüme daha da büyük olacaktır. Ayrıca gerekirse birkaç EC2 örneği veya daha fazlasını kullanacağız.

Bu durumda önerilen kurulum nedir? bu sürekli yazma (ETL) nedeniyle hızlı yazma işlemi gerektirecektir. PostgreSQL'de OLAP küpleri oluşturabilir miyiz? evet ise, orada kimse denedi mi?

Veritabanına bağlanma

Web sunucuları sorgulamak ve yazmak için ana veritabanına bağlanacaktır. Şu anda bağlantı için yerel kütüphane kullanan django kullanarak bir uygulama geliştiriyoruz. Aynı temel yöntemi kullanmanız önerilir mi? veya pgpool'u yapılandırmalı mıyız?

Veri ambarı (ETL)

Ana depodan veri deposuna okumak için ETL süreçleri oluşturmanın önerilen yolu nedir? Herhangi bir alet var mı? izlenecek metodoloji? PostgreSQL ETL süreçlerinin oluşturulmasında yararlı fonksiyonlar / araçlar sunuyor mu?

Altyapı / Veritabanı Hizmetleri

EBS ile AWS üzerinde çalışan yüksek hacimli bir siteye genel bakış için bunu okumalısınız. Geçici depolamaya taşındılar ancak verileri (yeniden) depolayabilmek için bir miktar fazlalık yaratmak zorunda kaldılar.

http://blog.reddit.com/2012/01/january-2012-state-of-servers.html

Veri Ambarı / ETL

Geçmişte Pentaho'yu kullandım. Doğrudan postgres ile değil, hem OLAP (Mondrian) hem de ETL (Kettle) için iyi bir çözüm buldum

http://www.pentaho.com/

edit: "Topluluk Sürümleri" burada bulunabilir

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

Bağ

Bu millet gerçekten pgbouncer gibi görünüyor. /programming/1125504/django-persistent-database-connection

Bununla ilgili hiçbir deneyimim yok. Görünüşe göre Disqus bunu kullanıyor.

Kurulumunuz bir üniversite için geliştirdiğim düzenlemeye benziyor. Veritabanı büyük değildi, ancak oldukça büyük, yaklaşık 300GB boyutundaydı ve en büyük tablo yaklaşık 500 milyon kayıt içeriyordu. Ve hala büyüyor.

Bu amaçla, biri bir web sitesindeki verileri işlemek için ayrılmış ve diğeri istatistiksel hesaplamalar ve analizler için kullanılan iki gerçekten sığır sunucu (sanallaştırılmamış gerçek demir) kullanıldı. Veriler Slony kullanılarak her iki yönde de tekrarlandı. OLTP verileri OLAP sunucusuna sürekli olarak kopyalandı ve bazı şemalar ve tek tablolar OLAP sunucusundan OLTP'ye çoğaltıldı. Bu şekilde, OLTP sunucusunu etkilemeden analiz sunucusunda ağır hesaplamalar gerçekleştirilebilir. Günümüzde, verileri kopyalamak için Slony'ye bazı alternatifler var: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony endişemiz için iyi ve hızlıydı ama sert bir öğretmen olabilir.

OLAP sunucusu sürekli büyüyeceğinden, varsa bir tür ayrıştırma kullanmayı düşünmelisiniz.

Olanak varsa, bağlantı havuzu kullanın. Ben sadece PgPool kullandım ve kusursuz çalıştı. PgBouncer başka bir seçenektir. Başlangıç ​​gecikmesini azaltmanın yanı sıra oturum başlatma ve oturum yönetimini de azaltır. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Bağlantı havuzu kullanmanın bir diğer yararı da, trafiğinizi kolayca yeniden yönlendirebileceğiniz tek bir noktaya sahip olmanızdır (bu elbette bir risk de olabilir).

OLAP sunucusuna veri yüklemek için hazır ETL kullanmadım. Python'da kendi betiğimi yazdım, çünkü bazı veriler tuhaf bir formatta büyük metin dosyalarında teslim edildi.

Veritabanının yapısı dikkatle değerlendirilmelidir. Şema kullanmak, nesneleri toplamak ve işlemeyi kolaylaştırmak için iyidir. Şemaları kullanmaya başlamak zahmetli görünebilir, ancak nesne sayısı arttıkça kendinize teşekkür edersiniz. Nesneleri şemalarına açıkça önek eklemeniz gerektiğini bilerek, tam olarak hangi nesneleri çalıştırdığınızı bilirsiniz. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Cesur olanlar için PostgreSQL XC ilginç bir alternatif ya da sadece büyük bir kostüm http://postgres-xc.sourceforge.net/