Translate

Mostrando las entradas con la etiqueta Postgres. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Postgres. Mostrar todas las entradas

lunes, 29 de julio de 2024

Procedimientos Almacenados y Funciones en PostgreSQL


PostgreSQL es una de las bases de datos relacionales más avanzadas y de código abierto que existen. Ofrece una amplia gama de características, incluida la capacidad de crear procedimientos almacenados y funciones, lo que permite encapsular lógica de negocios directamente en la base de datos. 

Un procedimiento almacenado es un conjunto de instrucciones SQL que puedes guardar y ejecutar en el servidor de base de datos. Estos procedimientos pueden aceptar parámetros, realizar operaciones complejas y devolver resultados. Son útiles para encapsular lógica de negocios, mejorar el rendimiento y simplificar el mantenimiento del código.

Una función en PostgreSQL es similar a un procedimiento almacenado, pero generalmente se usa para devolver un valor o un conjunto de resultados. Las funciones pueden ser escalar (devolviendo un único valor) o de conjunto (devolviendo una tabla de resultados).

Vamos a crear una función simple que suma dos números.


CREATE OR REPLACE FUNCTION suma(a INTEGER, b INTEGER)

RETURNS INTEGER AS $$

BEGIN

    RETURN a + b;

END;

$$ LANGUAGE plpgsql;



- **CREATE OR REPLACE FUNCTION**: Esta declaración crea una nueva función o reemplaza una existente.

- **RETURNS INTEGER**: Indica que la función devuelve un valor entero.

- **LANGUAGE plpgsql**: Especifica que la función está escrita en PL/pgSQL, el lenguaje de procedimientos de PostgreSQL.


Para ejecutar la función:

SELECT suma(3, 5); -- Devuelve 8



Vamos a crear una función que devuelve una lista de usuarios con su respectiva edad.


CREATE OR REPLACE FUNCTION obtener_usuarios()

RETURNS TABLE(nombre VARCHAR, edad INTEGER) AS $$

BEGIN

    RETURN QUERY

    SELECT nombre, edad FROM usuarios;

END;

$$ LANGUAGE plpgsql;


Para ejecutar la función:


SELECT * FROM obtener_usuarios();


A partir de PostgreSQL 11, se introdujo el soporte para procedimientos almacenados, que son similares a las funciones pero permiten realizar operaciones de control de transacciones (COMMIT y ROLLBACK) dentro del procedimiento.


Vamos a crear un procedimiento que inserta un nuevo usuario en la tabla `usuarios`.


CREATE OR REPLACE PROCEDURE insertar_usuario(nombre VARCHAR, edad INTEGER)

LANGUAGE plpgsql AS $$

BEGIN

    INSERT INTO usuarios (nombre, edad) VALUES (nombre, edad);

END;

$$;


Para ejecutar el procedimiento:


CALL insertar_usuario('Juan', 30);


Los procedimientos almacenados y las funciones en PostgreSQL son herramientas poderosas para encapsular lógica de negocios y mejorar la eficiencia de las operaciones de base de datos. Con el uso adecuado, pueden simplificar el desarrollo y mantenimiento de aplicaciones, al tiempo que mejoran el rendimiento y la seguridad.


jueves, 24 de septiembre de 2020

Como puedo obtener el número actual de conexiones en una base de datos PostgreSQL??



SELECT sum(numbackends) FROM pg_stat_database;


Y Listo!! Con esta query se cuantas conexiones hay en mi base de datos. 

domingo, 14 de junio de 2020

Programación reactiva + bases de datos relacionales = R2DBC


Al carecer de una API estándar y la falta de disponibilidad de controladores, un equipo de Pivotal comenzó a investigar la idea de una API relacional reactiva que sería ideal para fines de programación reactiva. Y en ese momento nació, R2DBC que significa Conectividad de base de datos relacional reactiva.

Entre las características de R2DBC podemos nombrar: 

R2DBC se basa en la especificación de Reactive Streams, que proporciona una API sin bloqueo totalmente reactiva.

Trabaja con bases de datos relacionales. A diferencia de la naturaleza bloqueante de JDBC, R2DBC le permite trabajar con bases de datos SQL utilizando una API reactiva.

Admite soluciones escalables. Con Reactive Streams, R2DBC le permite pasar del modelo clásico de "un subproceso por conexión" a un enfoque más potente y escalable.

Proporciona una especificación abierta. R2DBC es una especificación abierta y establece una interfaz de proveedor de servicios (SPI) para que los proveedores de controladores implementen y los clientes los consuman.

Actualmente existen las siguientes implementaciones : 
  • cloud-spanner-r2dbc: controlador para Google Cloud Spanner
  • jasync-sql: contenedor R2DBC para Java & Kotlin Async Database Driver para MySQL y PostgreSQL escrito en Kotlin.
  • r2dbc-h2: controlador nativo implementado para H2 como base de datos de prueba.
  • r2dbc-mariadb: controlador nativo implementado para MariaDB.
  • r2dbc-mssql: controlador nativo implementado para Microsoft SQL Server.
  • r2dbc-mysql: controlador nativo implementado para MySQL.
  • r2dbc-postgres: controlador nativo implementado para PostgreSQL.
Los estándares existentes, basados ​​en el bloqueo de I/O, cortan la programación reactiva de los usuarios de bases de datos relacionales. R2DBC especifica una nueva API para permitir código reactivo que funciona de manera eficiente con bases de datos relacionales.

R2DBC es una especificación diseñada desde cero para la programación reactiva con bases de datos SQL. Define un SPI sin bloqueo para implementadores de controladores de bases de datos y autores de bibliotecas de clientes. Los controladores R2DBC implementan completamente el protocolo de conexión de la base de datos sobre una capa de I/O sin bloqueo.

R2DBC está pensado principalmente como un SPI del controlador para ser consumido por las bibliotecas del cliente y no para ser utilizado directamente en el código de la aplicación.

R2DBC admite aplicaciones nativas en la nube que utilizan bases de datos relacionales como PostgreSQL, MySQL y otras. Los desarrolladores de aplicaciones son libres de elegir la base de datos adecuada para el trabajo sin estar limitados por las API.

Spring Data R2DBC, parte de la familia Spring Data, facilita la implementación de repositorios basados en R2DBC. Spring Data R2DBC aplica abstracciones de la familia de Spring y soporte de repositorio para R2DBC. Facilita la creación de aplicaciones basadas en Spring que utilizan tecnologías de acceso a datos relacionales en una stack de aplicaciones reactivas.

Spring Data R2DBC pretende ser conceptualmente fácil. Para lograr esto, NO ofrece almacenamiento en caché, carga diferida, escritura detrás o muchas otras características de los marcos ORM. Esto hace que Spring Data R2DBC sea un mapeador de objetos simple, limitado y con opiniones.

Spring Data R2DBC permite un enfoque funcional para interactuar con su base de datos proporcionando DatabaseClient como el punto de entrada para las aplicaciones.

Veamos un ejemplo con postgres : 

PostgresqlConnectionFactory connectionFactory = new PostgresqlConnectionFactory(PostgresqlConnectionConfiguration.builder()
.host(…)
.database(…)
.username(…)
.password(…).build());

DatabaseClient client = DatabaseClient.create(connectionFactory);

Mono<Integer> affectedRows = client.execute()
        .sql("UPDATE person SET name = 'Joe'")
        .fetch().rowsUpdated();

Flux<Person> all = client.execute()
        .sql("SELECT id, name FROM person")
        .as(Person.class)
        .fetch().all();

Otro enfoque para atacar el bloqueo de JDBC es Fibers. Fibers como una abstracción ligera que convertirá las API de bloqueo en no bloqueantes. Esto es posible mediante el cambio de pila tan pronto como una invocación ... Pero eso es otra Historia y va ha ser contada en otro post ... 

Dejo links: 

sábado, 28 de septiembre de 2019

Optimice y mejore el rendimiento de PostgreSQL con VACUUM, ANALYZE y REINDEX


Si tenes una base de datos PostgreSQL y te anda lenta, podes usar unos comandos para mejorar y optimizar el rendimiento: VACUUM, ANALYZE y REINDEX

Para evitar problemas es preferible ejecutar estos comandos durante el periodo de mantenimiento cuando nadie usa la base.

En la configuración por defecto de PostgreSQL, el demonio AUTOVACUUM debe estar habilitado y todos los parámetros de configuración necesarios se configuran según sea necesario. El demonio ejecutará VACUUM y ANALYZE a intervalos regulares. Para confirmar si el daemon de autovacuum se está ejecutando en UNIX o Linux, podes hacer :

$ ps aux | grep autovacuum | grep -v grep
postgres           334   0.0  0.0  2654128   1232   ??  Ss   16Mar17   0:05.63 postgres: autovacuum launcher process 

En la base, se puede verificar el estado de autovacuum en pg_settings con la siguiente consulta:

select name, setting from pg_settings where name = 'autovacuum' ;

El comando VACUUM recuperará el espacio que todavía utilizan los datos que se han actualizado. 

En PostgreSQL, las tuplas de clave-valor actualizadas no se eliminan de las tablas cuando se cambian las filas, por lo que el comando VACUUM debe ejecutarse ocasionalmente para hacer esto.

VACUUM se puede ejecutar solo o con ANALYZE.

Veamos algunos ejemplos, ojo el nombre de la tabla es opcional, por eso se escribe así [nombre de tabla]. Sin una tabla especificada, VACUUM se ejecutará en las tablas disponibles en el esquema actual al que el usuario tiene acceso.

VACUUM simple: libera espacio para reutilizar

VACUUM [tablename]

VACUUM FULL: bloquea la tabla de la base de datos y reclama más espacio que un VACUUM simple

/* Before Postgres 9.0: */
VACUUM FULL
/* Postgres 9.0+: */
VACUUM(FULL) [tablename]

VACUUM completo y ANALYZE: realiza un VACUUM completo y recopila nuevas estadísticas sobre las rutas de ejecución de consultas utilizando ANALIZAR

/* Before Postgres 9.0: */
VACUUM FULL ANALYZE [tablename]
/* Postgres 9.0+: */
VACUUM(FULL, ANALYZE) [tablename]

Verbose Full VACUUM and ANALYZE: Igual que el anterior, pero con salida de progreso detallado

/* Before Postgres 9.0: */
VACUUM FULL VERBOSE ANALYZE [tablename]
/* Postgres 9.0+: */
VACUUM(FULL, ANALYZE, VERBOSE) [tablename]

ANALYZE recopila estadísticas para el planificador de consultas para crear las rutas de ejecución de consultas más eficientes. Según la documentación de PostgreSQL, las estadísticas precisas ayudarán al planificador a elegir el plan de ejecución más apropiado y, por lo tanto, a mejorar la velocidad del procesamiento de la consulta.

En el siguiente ejemplo, [nombre de tabla] es opcional. Sin una tabla especificada, ANALYZE se ejecutará en las tablas disponibles en el esquema actual al que el usuario tiene acceso.

ANALYZE VERBOSE [tablename]

El comando REINDEX reconstruye uno o más índices, reemplazando la versión anterior del índice. REINDEX se puede usar en muchos escenarios, incluidos los siguientes:


  • Un índice se ha dañado y ya no contiene datos válidos. Aunque en teoría esto nunca debería suceder, en la práctica los índices pueden corromperse debido a errores de software o fallas de hardware. REINDEX proporciona un método de recuperación.
  • Un índice se ha "hinchado", es decir, contiene muchas páginas vacías o casi vacías. Esto puede ocurrir con índices de árbol B en PostgreSQL bajo ciertos patrones de acceso poco comunes. REINDEX proporciona una forma de reducir el consumo de espacio del índice escribiendo una nueva versión del índice sin las páginas muertas.
  • Ha modificado un parámetro de almacenamiento (como el factor de relleno) para un índice y desea asegurarse de que el cambio haya tenido pleno efecto.
  • Una construcción de índice con la opción CONCURRENTEMENTE falló, dejando un índice "inválido". Dichos índices son inútiles, pero puede ser conveniente usar REINDEX para reconstruirlos. Tenga en cuenta que REINDEX no realizará una compilación concurrente. Para construir el índice sin interferir con la producción, debe borrar el índice y volver a crearlo con el comando CREATE INDEX CONCURRENTLY.

Veamos unos ejemplos, cualquiera de estos puede forzarse agregando la palabra clave FORCE después del comando: 

Recree un solo índice, myindex:

REINDEX INDEX myindex

Recrea todos los índices en una tabla, mytable:

REINDEX TABLE mytable

Recree todos los índices en el esquema público:

REINDEX SCHEMA public

Recree todos los índices en la base de datos postgres:

REINDEX DATABASE postgres

Recree todos los índices en los catálogos del sistema en bases de datos de postgres:

REINDEX SYSTEM postgres



martes, 24 de septiembre de 2019

Tuneando base de datos postgresql con pgtune


Tenes una base de datos postgresql que anda lento? no modificaste postgresql.conf?

Bueno esta aplicación te permite tunear la base postgreslq con parámetros del hardware que estas utilizando. Lo importante es que toma solo el hardware por lo tanto es solo el comienzo, luego tenemos que seguir tuneando según el uso.

Sin más dejo el link: https://pgtune.leopard.in.ua/#/

jueves, 13 de diciembre de 2018

Libro gratuitos sobre Linux, postgresql, jetty, jdbc

Download Dev Guides!

 
Bash is a Unix shell and command language written by Brian Fox for the GNU Project as a free software replacement for the Bourne shell. First released in 1989, it has been distributed widely as it is a default shell on the major Linux distributions and OS X. Bash is a command processor that typically runs in a text window, where the user types commands that cause actions. Bash can also read commands from a file, called a script. Like all Unix shells, it supports filename globbing (wildcard matching), piping, here documents, command substitution, variables and control structures for condition-testing and iteration. The keywords, syntax and other basic features of the language were all copied from sh. Other features, e.g., history, were copied from csh and ksh. Bash is a POSIX shell, but with a number of extensions. In this ebook, we provide a compilation of BASH programming examples that will help you kick-start your own projects. We cover a wide range of topics, from user management and permissions setting, to specific commands like sed, tar, etc. 
 
 
PostgreSQL, often simply Postgres, is an object-relational database management system (ORDBMS) with an emphasis on extensibility and standards-compliance. As a database server, its primary function is to store data securely, and to allow for retrieval at the request of other software applications. It can handle workloads ranging from small single-machine applications to large Internet-facing applications with many concurrent users. PostgreSQL is developed by the PostgreSQL Global Development Group, a diverse group of many companies and individual contributors. It is free and open-source software, released under the terms of the PostgreSQL License, a permissive free-software license. In this ebook, we provide a compilation of PostgreSQL tutorials that will help you set up and run your own database management system. We cover a wide range of topics, from installation and configuration, to custom commands and datatypes. With our straightforward tutorials, you will be able to get your own projects up and running in minimum time.
 
 
Jetty is a Java HTTP (Web) server and Java Servlet container. While Web Servers are usually associated with serving documents to people, Jetty is now often used for machine to machine communications, usually within larger software frameworks. Jetty is developed as a free and open source project as part of the Eclipse Foundation. The web server is used in products such as Apache ActiveMQ, Alfresco, Apache Geronimo, Apache Maven, Apache Spark, Google App Engine, Eclipse, FUSE, iDempiere, Twitter’s Streaming API and Zimbra. Jetty is also the server in open source projects such as Lift, Eucalyptus, Red5, Hadoop and I2P. Jetty supports the latest Java Servlet API (with JSP support) as well as protocols HTTP/2 and WebSocket. In this ebook, we provide a compilation of Jetty examples that will help you kick-start your own projects. We cover a wide range of topics, from installation and configuration, to JMX and OSGi. With our straightforward tutorials, you will be able to get your own projects up and running in minimum time.
 
 
This tutorial is about JDBC (Java Database Connectivity), an API provided by Oracle that allows programmers to handle different databases from Java applications: it allows developers to establish connections to databases, defines how a specific client can access a given database, provides mechanisms for reading, inserting, updating and deleting entries of data in a database and takes care of transactions composed of different SQL statements. In this article we will explain the main JDBC components like Statements, Result Sets or Stored Procedures. JDBC needs drivers for the different databases that programmers may want to work with; we will explain this in detail and we will provide some examples. JDBC comes together with Java since the beginning of times; the first release came with the JDK 1.1 on February 1997 and since then, JDBC has been an important part of Java. The main packages where JDBC is contained are Package java.sql and Package javax.sql. All the information about the last JDBC release (4.2) and its development and maintenance can be found in the JSR 221. 

viernes, 13 de abril de 2018

Estadísticas de las base de datos relacionales.

Para que una base de datos relacional pueda resolver una consulta SQL de forma óptima necesita conocer los datos físicos de cada tabla, índice o cluster que intervienen en ella. Estos datos se almacenan en el diccionario de datos.

En oracle pueden ser consultadas usando las vistas adecuadas: dba_tables, dba_tab_statistics, dba_tab_col_statistics, dba_tab_histograms, dba_indexes, dba_ind_statistics… etc.

En concreto, es el optimizador quién de todos los planes de ejecución posibles analiza estos datos estadísticos para evaluar cuál de todos supone un menor coste en términos de I/O y uso de CPU.

Las estadísticas deben reflejar verazmente el estado físico de los objetos, y conforme vayan sufriendo transformaciones éstas se irán quedando obsoletas. Es por esto por lo que hay que recopilar las estadísticas de nuevo a medida que ya no reflejen la situación real de los objetos a los que describen.

Si una tabla no posee estadísticas, el motor de base de datos puede recopilar ciertos datos dinámicamente en el momento de la consulta. Esto se llama muestreo dinámico “dynamic sampling”.

Las estadísticas se pueden recopilar  manual o automáticamente. Por omisión, Oracle recopila las estadísticas a través del job programado con scheduler en una ventana de tiempo predefinida: por ejemplo de lunes a viernes de 22:00 a 6:00 y sábados y domingos completos. Durante esta recopilación automática se toman datos de tablas sin estadísticas o con estadísticas obsoletas (que han sufrido más de 10% de modificaciones desde la anterior toma de datos) pero antes debe haberse configurado el parámetro STATISTICS_LEVEL a un valor distinto de BASIC.

En oracle para seguir el número de registros modificados existe la vista existe all_tab_modifications. Ésta muestra el número aproximado de inserciones, modificaciones, borrados y truncados que ha sufrido la tabla desde la última recopilación. La vista es consultable por el usuario pero hay que tener en cuenta que estos datos no son visibles inmediatamente. Existe un retardo de unos minutos para evitar que la escritura interfiera en el rendimiento.

Para recopilar las estadísticas manualmente hay diferentes funciones dependiendo el motor por ejemplo en oracle hay que usar el paquete DBMS_STATS. Dicho paquete tiene métodos para:

  • Recopilar estadísticas.
  • Borrar estadísticas.
  • Guardar y asignar estadísticas.
  • Crear o borrar tablas donde guardar juegos de estadísticas.
  • Bloquear y desbloquear las estadísticas de las tablas.
  • Retornar las estadísticas que tenía una tabla en un momento dado.

En Oracle podemos ejecutar las estadísticas para todos los esquemas de la siguiente forma:

SQL> exec dbms_stats.gather_database_stats;
Procedimiento PL/SQL terminado correctamente.

En Postgres por ejemplo existe una herramienta llamada ANALYZE que permite correr las estadísticas de forma manual :

ANALYZE [ VERBOSE ] [ table_name [ ( column_name [, ...] ) ] ]

Como se puede ver hay diferentes modos de correr esto pero lo más común sería:

ANALYZE VERBOSE users;

En sql server, tambien podemos actualizar las estadísticas utilizando UPDATE STATISTICS o el  stored procedure sp_updatestats, veamos unos ejemplos:

USE AdventureWorks2012;
GO

UPDATE STATISTICS Sales.SalesOrderDetail;
GO

La actualización de estadísticas garantiza que las consultas compilan con estadísticas actualizadas. Sin embargo, actualizar las estadísticas hace que las consultas se recompilen. Por lo tanto puede haber una compensación de rendimiento entre la mejora de los planes de consulta y el tiempo que lleva recompilar las consultas.

Y por ultimo, algo muy importante es hacer backup tambien de las estadísticas, dado que si pasa algo con la base de datos, no solo vamos a querer restaurarla sino tambien que sea usable. Por lo tanto a la hora de hacer backup incluyamos las estadísticas.

lunes, 17 de agosto de 2015

Postgrest

Algo que me llamo la atención de CouchDB es que exponía sus datos con una API Rest, me pareció fantástico, porque la verdad es que no remplazaría a la capa de aplicación 100% de las veces. Pero para alguna aplicación pequeña. Además si todas las bases usan esta técnica, las aplicaciones no deberían saber si se comunican con una base, con otro sistema, ni es necesario saber  que base de datos es. Muchas ventajas!

Postgrest permite hacer esto con postgres, provee una API Rest para comunicarse con la base y de esta forma poder acceder a los datos a través de REST.

Cualquier base de datos Postgres puede utilizar este programa, solo es necesario llamarlo de la siguiente manera:

postgrest  --db-host localhost  --db-port 5432     \
           --db-name my_db      --db-user postgres \
           --db-pass foobar     --db-pool 200      \
           --anonymous postgres --port 3000        \
           --v1schema public

Podríamos
hablar de muchas ventajas como:

  • Seguro, puede utilizar https y provee autenticación.
  • Autodocumentado
  • Rapido


Dejo link:
https://github.com/begriffs/postgrest

lunes, 2 de septiembre de 2013

DB-Engines Ranking

Existe un ranking de base de datos, en realidad de almacenes de datos porque hay del tradicional entidad-relación al NoSQL. Bien no se de donde toman los datos pero se ve coherente.

Dejo link:
http://db-engines.com/en/ranking

jueves, 11 de abril de 2013

MoSQL, de mongoDb a postgres!!





Con el crecimiento de NoSQL, las herramientas que permiten convivir NoSQL cn base de datos relacionales estan tomando mayor importancia. Por lo tanto les quiero presentar MoSQL, que permite hacer? Replicar datos desde una base de datos MongoDB a una postgres.


Con MoSQL, se puede ejecutar aplicaciones contra una base de datos MongoDB, pero también mantener una actualización de sus datos en PostgreSQL, listo para realizar consultas con toda la potencia de SQL.


Dejo link:
https://stripe.com/blog/announcing-mosql
https://github.com/stripe/mosql

jueves, 20 de diciembre de 2012

7 base de datos en 7 días



Se acuerdan que hable de un libro muy bueno llamado 7 lenguajes en 7 días, bueno Eric Redmond y Jim R. Wilson lanzaron un nuevo libro llamado 7 base de datos en 7 días. En el recorre base de datos relacionales y NoSQL. Las bases que se muestran son Redis, Neo4J, CouchDB, MongoDB, HBase, Riak, y Postgres. La idea es no saber todas, pero si sus particularidades y porque elegir una o la otra.

Dejo el link:
http://pragprog.com/book/rwdata/seven-databases-in-seven-weeks

miércoles, 5 de septiembre de 2012

select * from Dual en Oracle



En Oracle existe una tabla llamada DUAL, normalmente se usa para referenciar consultas que no tienen una tabla sino que son resultado de una función; por ejemplo:

Select SYSDATE from dual;

De esta forma podemos saber la fecha del servidor. Pero que pasa si queremos saber que tiene dual podemos hacer lo siguiente:

desc dual


Name                    Null?    Type
 ----------------------- -------- ----------------
 DUMMY                            VARCHAR2(1)

Claro en realidad DUAL es una table con un solo registro, de esta forma siempre nos devuelve un valor las consultas a dual: Vamoa a hacer un select * from Dual para ver que nos devuelve:

select * from Dual

Y nos retornara una sola fila con un único valor X para la tabla Dual. Supongamos que migramos de oracle a otra base y hacemos uso de la tabla dual o estamos acostumbrados a usarla. Por ejemplo en Postgres no existe esta tabla solo debemos hacer el select si From:


SELECT SYSDATE
o como deberia ser en PostgreSQL
SELECT now()
o
SELECT current_date


Otra solución es crear la tabla DUAL de la siguiente manera:

 CREATE TABLE DUAL
(
DUMMY VARCHAR(1)
)

Luego insertamos el único valor: 

INSERT INTO DUAL (DUMMY)
VALUES ('X')

Eso es todo amiguitos...

Dejo link:

sábado, 25 de agosto de 2012

Performance en Postgres





Al parecer cuando instalamos una base de datos Postgres; se instala una base de datos de juguete; es decir que se debe trabajar mucho para dejarla a punto para producción. Los parametros por defecto son muy inferiores a lo que puede soportar realmente Postgres.

El primer paso para entender como mejorar la performance de su base de datos es entender el ciclo de vida de una query:
  • La transmisión de la consulta a la base de datos back-end
  • Análisis de cadena de consulta
  • Planificación de consulta para optimizar la recuperación de datos
  • Recuperación de datos de hardware
  • Transmisión de resultados a cliente
Primero paso la transmisión de la consulta a la base de dato en este caso no se puede hacer mucho; solo en el caso de que la query sea muy grande se puede crear un store procedure para mejorar la trasmición de esta forma no viaja la query completa sino el nombre del store.

El segundo paso es el analisis de cadena que tambien se puede mejorar haciendo un store procedure.

La planificación de la consulta es donde realmente comienza PostgreSQL hacer algún trabajo. En esta etapa se comprueba si la consulta está bien para la versión de PostgreSQL. También se analiza el SQL para determinar cuál es la forma más eficaz de recuperar sus datos. ¿Debemos utilizar un índice? y si es así ¿cuál? Estas son algunas de las decisiones de la base de datos hace que en este punto del proceso. Este paso puede ser eliminado si la consulta se prepara previamente.

Ahora que PostgreSQL tiene un plan de lo que cree que es la mejor manera de recuperar los datos, es el momento de ejecutar el plan. Si bien hay algunas opciones de optimización que ayudarían, este paso se optimiza principalmente por la configuración de hardware.

Y, finalmente, el último paso es la transmisión de los resultados al cliente. Si bien no hay ninguna opción de optimización real de este paso, se debe tener en cuenta que todos los datos que están estrayendo desde el disco y se envía a través del cable al cliente. Reducir al mínimo el número de filas y columnas para sólo aquello que es necesario a menudo puede aumentar el rendimiento.

Vamos a ver los parametros que hay que tocar para mejorar la performance de nuestra base. Se pueden cambiar los parametros de postgres de diferente formas pero la más facil es modificar el archivo postgresql.conf ejecutando SHOW config_file  podremos saber donde se encuentra este archivo.

max_connections = <num> esta opción establece el número máximo de backend de base de datos para tener en un momento dado. Utilice esta función para asegurarse que no tenga tanto clientes y puedan matar la base.

shared_buffers = <num> La edición de esta opción es la forma más sencilla de mejorar el rendimiento de su servidor de base de datos. El valor por defecto es bastante bajo para la mayoría del hardware moderno. General se dice que esto se debe establecer en aproximadamente el 25% de la memoria RAM disponible en el sistema. Como la mayoría de las opciones que se describen aquí, simplemente tendrá que probar en diferentes niveles (tanto hacia arriba como hacia abajo) y ver lo bien que funciona en su sistema particular.

effective_cache_size = <num> Este valor es la cache de postgres. Esto se debe establecer la cantidad de memoria asignada a shared_buffers más la cantidad de caché del sistema operativo disponible. A menudo esto es más de 50% de la memoria total del sistema.

work_mem = <num> Esta opción se utiliza para controlar la cantidad de memoria utilizando en las operaciones de ordenación y tablas hash. Si bien es posible que necesite aumentar la cantidad de memoria se debe tener cuidado de no aumentarlo demasiado.

max_fsm_pages = <num> Esta opción ayuda a controlar el mapa de espacio libre. Cuando algo se elimina de una tabla no se elimina del disco inmediatamente, simplemente se marca como "libre" en el mapa de espacio libre. El espacio se puede volver a utilizar para cualquier inserción en la tabla. Si su configuración tiene una alta tasa de eliminaciones e inserta puede ser necesario aumento de este valor.

commit_delay = <num> y commit_siblings = <num> Estas opciones se utilizan en conjunto para ayudar a mejorar el rendimiento de escritura múltiples transacciones que están comitiando al mismo tiempo. Si hay una serie de backends commit_siblings activos en el instante en que la transacción se comitea, el servidor espera microsegundos commit_delay para tratar de confirmar las transacciones a la vez.

random_page_cost = <num>controla la forma en PostgreSQL considera las lecturas no secuenciales. Un valor más alto hace que sea más probable que un recorrido secuencial.

Dejo link:
http://wiki.postgresql.org/wiki/Performance_Optimization

miércoles, 22 de agosto de 2012

Savepoint


Cuando jugábamos algún juego de aventura había una luz, una bandera o un objeto medio raro que indicaba que si moríamos en ese nivel no tendríamos que hace de nuevo todo el nivel sino que comenzaríamos de ese punto.


Algo así son los savepoint de las bases de datos, si vemos la wikipedia podemos leer:

"Un savepoint (en español, punto de recuperación) es una forma de implementar subtransacciones (también conocidas como transacciones anidadas) dentro de un sistema gestor de base de datos relacional indicando un punto dentro de unatransacción de base de datos que puede ser "rolled back" (devuelta) sin afectar a cualquier trabajo realizado en la transacción antes de que el punto de recuperación fuera creado. Varios savepoints pueden existir dentro de una transacción individual. Los Savepoints son útiles para implementar recuperación de errores complejos en aplicaciones de base de datos — si ocurre un error en el medio de una transacción de múltiples sentencias, la aplicación puede ser capaz de recuperarse del error (devolviendo, "rolling back", hasta un savepoint) sin necesidad de abortar la transacción completa."

Pero como puedo utilizar este punto de recuperación? En Postgres, es como esta definido en el siguiente ejemplo:

BEGIN;
    INSERT INTO table1 VALUES (1);
    SAVEPOINT my_savepoint;
    INSERT INTO table1 VALUES (2);
    ROLLBACK TO SAVEPOINT my_savepoint;
    INSERT INTO table1 VALUES (3);
COMMIT;

En el ejemplo el insert con valor 2 no se aplica dadoque hace un rollback al savepoint my_savepoint.

En Oracle es muy similar veamos otro ejemplo:

DECLARE
   emp_id        employees.employee_id%TYPE;
   emp_lastname  employees.last_name%TYPE;
   emp_salary    employees.salary%TYPE;
BEGIN
   SELECT employee_id, last_name, salary INTO emp_id, emp_lastname,
     emp_salary FROM employees WHERE employee_id = 120;
   UPDATE emp_name SET salary = salary * 1.1 WHERE employee_id = emp_id;
   DELETE FROM emp_name WHERE employee_id = 130;
   SAVEPOINT do_insert;
   INSERT INTO emp_name VALUES (emp_id, emp_lastname, emp_salary);
EXCEPTION
   WHEN DUP_VAL_ON_INDEX THEN
      ROLLBACK TO do_insert;
      DBMS_OUTPUT.PUT_LINE('Insert has been rolled back');
END;
/

Luego de correr esta instrucción podemos ejecutar cualquier instrucción y romper todo. Que tenemos un punto donde podemos volver.

viernes, 13 de julio de 2012

PostgreSQL 9.2 con soporte nativo a JSON


Sip, como lo escuchan PostgreSQL 9.2 va a soportar JSON. JSON es una notación que se ha extendido rápidamente, como sabrán esta basada en Javascript y es un formato que es soportado de forma nativa por Javascript.  Mira lo que dice la wikipedia:


"La simplicidad de JSON ha dado lugar a la generalización de su uso, especialmente como alternativa a XML en AJAX. Una de las supuestas ventajas de JSON sobre XML como formato de intercambio de datos en este contexto es que es mucho más sencillo escribir un analizador sintáctico (parser) de JSON. En JavaScript, un texto JSON se puede analizar fácilmente usando el procedimiento eval(), lo cual ha sido fundamental para que JSON haya sido aceptado por parte de la comunidad de desarrolladores AJAX, debido a la ubicuidad de JavaScript en casi cualquier navegador web."




En  PostgreSQL 9.2 vamos a poder hacer lo siguiente: 



CREATE TABLE test(gid serial PRIMARY KEY, title text, geog geography(Point, 4326));

INSERT INTO test(title, geog) 
 VALUES('a'
 , ST_GeogFromText('POINT(-71.057811 42.358274)'));

INSERT INTO test(title, geog) 
 VALUES('b'
 , ST_GeogFromText('POINT(42.358274 -71.057811 )'));


SELECT array_to_json(array_agg(t))
FROM test As t;
Y esto nos devolvera las filas en formato JSON. También podemos utilizar la función row_to_json;

Y esto para que me sirve? Bueno si usan frameworks como node.js estan hechos pueden trabajar todo bajo javascript y json. Sino por ejemplo para paginas pequeñas donde no es necesario tener una aplicación multicapa podemos llenar objetos javascript, por ejemplo en PHP:

var mi_variable = <?php echo buscarAlgo(); ?>

o un uso ideal es para funciones ajax.

Dejo link:
http://www.postgresql.org/docs/9.2/static/functions-json.html

viernes, 3 de febrero de 2012

Postgres Plus® Cloud Database

La verdad estoy sorprendido al leer esto: EnterpriseDB ha anunciado la disponibilidad de Postgres Plus Nube de base de datos (PPCDB), una base de datos con un servicio que ofrece PostgreSQL 9.1 y Postgres Plus Advanced Server 9.0 como IAM en Amazon AWS. OpenStack incluirá soporte para PPCDB.

PPCDB viene con una interfaz web para la instalación y la gestión de casos individuales o grupos de bases de datos Postgres en la nube, y funciones de escala automática, leer y escribir en el balanceador de carga, la replicación binaria, conmutación por error, de auto-aprovisionamiento, almacenamiento elástico, la clonación de DB, y automatización copias de seguridad.

Postgres Plus Advanced Server incluye compatibilidad con Oracle permite a los desarrolladores ejecutar  SQL de Oracle contra una base de datos PostgreSQL.

Dejo un video:



Dejo Links:
http://www.infoq.com/news/2012/02/PostgreSQL-Neo4J-Cloud
http://www.enterprisedb.com/products-services-training/products-overview/postgres-plus-cloud-database