PostgreSQL para transacciones de gran volumen y para almacenamiento de datos

Soy bastante nuevo en PostgreSQL, nunca antes había hecho una gran implementación usándolo. Pero tengo una buena experiencia en soluciones empresariales y quiero intentar aplicar algo de lo que aprendí usando PostgreSQL.

Tengo un sitio que está dimensionado para manejar gran cantidad de datos y tráfico. La infraestructura se construirá utilizando Amazon (AWS) utilizando instancias EC2 y volúmenes EBS.

El diseño debe tener dos bases de datos, una base de datos transaccional principal y un almacén de datos para manejar análisis e informes.

Base de datos transaccional principal

se utilizará para el sitio web en vivo, el sitio está construido en múltiples nodos para escalar usuarios concurrentes. Principalmente requerimos que la base de datos para este caso sea extremadamente rápida en las operaciones de lectura, esperamos datos> 100GB con un crecimiento anual del 30%. En este punto, estamos planeando usar dos servidores EC2 ( y agregar más más tarde según lo necesitemos ).

mi pregunta, ¿cuál es la configuración recomendada para los requisitos anteriores? Además, ¿hay alguna forma de administrar la partición de tablas y volúmenes? ¿Hay recomendaciones para usar la configuración de AWS?

Base de datos del almacén de datos

Se utilizará principalmente para capturar todos los datos de la base de datos transaccional principal en la dimensión de tiempo. por lo tanto, incluso los registros eliminados de la base de datos principal se capturarán en el DWH. Por lo tanto, los datos serán muy grandes y el crecimiento será aún mayor. También usaremos un par de instancias EC2 o más si es necesario.

¿Cuál es la configuración recomendada en este caso? esto requerirá una operación de escritura rápida debido a la escritura constante (ETL). ¿Podemos construir cubos OLAP en PostgreSQL? en caso afirmativo, ¿alguien lo intentó?

Conectando a la base de datos

Los servidores web se conectarán a la base de datos principal para consultar y escribir. Actualmente estamos desarrollando una aplicación usando django que usa una biblioteca nativa para conectarse. ¿Se recomienda usar el mismo método básico? o deberíamos configurar pgpool?

Almacén de datos (ETL)

¿Cuál es la forma recomendada para construir procesos ETL para leer desde el principal y cargar al almacén de datos? Alguna herramienta? metodología a seguir? ¿PostgreSQL ofrece funciones / herramientas útiles para construir procesos ETL?

Infraestructura / Servicios de bases de datos

Probablemente debería leer esto para obtener una descripción general de un sitio de alto volumen que se ejecuta en AWS con EBS. Se han trasladado al almacenamiento efímero, pero han tenido que crear cierta redundancia para poder (re) almacenar los datos.

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

Almacén de datos / ETL

He usado Pentaho en el pasado. No directamente con postgres, pero he encontrado que es una buena solución tanto para OLAP (Mondrian) como para ETL (Kettle)

http://www.pentaho.com/

editar: "Ediciones de la comunidad" se puede encontrar aquí

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

Conexión

A estas personas parece gustarles mucho pgbouncer. /programming/1125504/django-persistent-database-connection

Sin embargo, no tengo experiencia con eso. Aparentemente, Disqus lo usa.

Su configuración se parece a la que desarrollé para una universidad. La base de datos no era enorme, pero sí bastante grande, de unos 300 GB de tamaño y la tabla más grande contenía unos 500 millones de registros. Y sigue creciendo.

Para ello, se utilizaron dos servidores realmente robustos (hierro real, no virtualizados), uno dedicado a manejar los datos de un sitio web y el otro utilizado para cálculos y análisis estadísticos. Los datos se replicaron en ambas direcciones usando Slony. Los datos OLTP se replicaron en el servidor OLAP continuamente y algunos esquemas y tablas individuales se replicaron del servidor OLAP al OLTP. De esta manera, se podrían realizar cálculos pesados ​​en el servidor de análisis sin afectar el servidor OLTP. Hoy en día, hay algunas alternativas a Slony para replicar datos: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony fue bueno y rápido para nuestra preocupación, pero puede ser un maestro duro.

Como el servidor OLAP crecerá constantemente, debería considerar usar algún tipo de partición, si corresponde.

Si tiene la posibilidad, use la agrupación de conexiones. Solo he usado PgPool y funcionó a la perfección. PgBouncer es otra opción. Además de reducir la latencia de inicio, también reduce el inicio de sesión y la administración de sesión. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Otro beneficio de usar un grupo de conexiones es que tiene un punto único en el que puede redirigir fácilmente su tráfico (esto también podría ser un riesgo).

No he usado ningún ETL listo para cargar datos en el servidor OLAP. Escribí mi propio script en Python ya que algunos de los datos se entregaron en grandes archivos de texto con un formato peculiar.

La estructura de la base de datos debe considerarse cuidadosamente. Usar esquemas es bueno para reunir y facilitar el manejo de objetos. Para empezar, puede parecer engorroso usar esquemas, pero a medida que aumente la cantidad de objetos, se lo agradecerá. Sabiendo que tiene que anteponer explícitamente objetos con su esquema, sabe exactamente en qué objetos opera. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Para los atrevidos, PostgreSQL XC puede ser una alternativa interesante o simplemente un disfraz de gran tamaño http://postgres-xc.sourceforge.net/