Diez razones principales para migrar de Oracle a PostgreSQL

Oracle Relational Database Management System (RDBMS) ha sido ampliamente utilizado por grandes organizaciones y se considera, con mucho, la tecnología de base de datos más avanzada disponible en el mercado. Por lo general, es el RDBMS que se compara con más frecuencia con otros productos de bases de datos y actúa como el estándar "de facto" de lo que debería ofrecer un producto. Está clasificado por db-engines.com como el RDBMS n.º 1 disponible en el mercado actual.

PostgreSQL está clasificado como el RDBMS n.º 4, pero eso no significa que no haya ninguna ventaja en migrar a PostgreSQL. PostgreSQL ha existido desde 1989 y fue de código abierto en 1996. PostgreSQL ganó el DBMS del año en dos años consecutivos desde 2017 y 2018. Eso solo indica que no hay señales de dejar de atraer a una gran cantidad de usuarios y grandes organizaciones.

Una de las razones por las que PostgreSQL ha atraído mucha atención es porque la gente está buscando una alternativa a Oracle para poder reducir los altos costos de las organizaciones y escapar del bloqueo de proveedores.

Pasar de una base de datos Oracle funcional y productiva puede ser una tarea abrumadora. Inquietudes como el TCO (Costo total de propiedad) de la empresa es una de las razones por las que las empresas arrastran su decisión de deshacerse o no de Oracle.

En este blog, veremos algunas de las razones principales por las que las empresas eligen dejar Oracle y migrar a PostgreSQL.

Primer motivo:es un verdadero proyecto de código abierto

PostgreSQL es de código abierto y se publica bajo la licencia de PostgreSQL, una licencia liberal de código abierto, similar a las licencias BSD o MIT. La adquisición del producto y el soporte no requiere ninguna tarifa.

Si desea aprovechar el software de la base de datos, significa que puede obtener todas las funciones disponibles de la base de datos PostgreSQL de forma gratuita. PostgreSQL tiene más de 30 años de madurez en el mundo de las bases de datos y ha sido táctil como código abierto desde 1996. Ha disfrutado de décadas de trabajo de los desarrolladores para crear extensiones. Eso, en sí mismo, hace que los desarrolladores, instituciones y organizaciones elijan PostgreSQL para aplicaciones empresariales; impulsando las principales aplicaciones empresariales y móviles.

Una vez más, las organizaciones se están dando cuenta de que las soluciones de bases de datos de código abierto como Postgres ofrecen mayor capacidad, flexibilidad y soporte que no depende completamente de ninguna empresa o desarrollador. Postgres, como antes Linux, ha sido (y continúa siendo) diseñado por usuarios dedicados a resolver problemas comerciales cotidianos que eligen devolver sus soluciones a la comunidad. A diferencia de un gran desarrollador como Oracle, que puede tener diferentes motivos para desarrollar productos que sean rentables o que respalden un mercado limitado pero lucrativo, la comunidad de Postgres se compromete a desarrollar las mejores herramientas posibles para los usuarios cotidianos de bases de datos relacionales.

PostgreSQL a menudo lleva a cabo esas tareas sin agregar demasiada complejidad. Su diseño se centra estrictamente en el manejo de la base de datos sin tener que desperdiciar recursos, como administrar entornos de TI adicionales a través de funciones adicionales. Es una de las cosas que les gusta a los consumidores de este software de código abierto cuando migran de Oracle a PostgreSQL. Dedicar horas a estudiar tecnología compleja sobre cómo funciona una base de datos de Oracle, o cómo optimizarla y ponerla a punto, puede terminar con su soporte costoso. Esto atrae a las instituciones u organizaciones a encontrar una alternativa que pueda ser menos dolor de cabeza en el costo y genere ganancias y productividad. Consulte nuestro blog anterior sobre la capacidad de PostgreSQL para hacer coincidir la presencia de sintaxis SQL con la sintaxis de Oracle.

Razón dos:sin licencia y una gran comunidad

Para los usuarios de la plataforma Oracle RDBMS, es difícil encontrar algún tipo de soporte comunitario que sea gratuito o sin una tarifa considerable. Instituciones, organizaciones y desarrolladores a menudo terminan encontrando información alternativa en línea que puede ofrecer respuestas o soluciones a sus problemas de forma gratuita.

Cuando se utiliza Oracle, es difícil decidirse por un producto específico o si optar por el Soporte de productos porque (generalmente) se involucra una gran cantidad de dinero. Puede probar un producto específico para probarlo, terminar comprándolo, solo para darse cuenta de que no puede ayudarlo. Con PostgreSQL, la comunidad es gratuita y está llena de expertos con amplia experiencia que estarán felices de ayudarlo con sus problemas actuales.

Puede suscribirse a la lista de correo aquí mismo en https://lists.postgresql.org/ para comenzar a comunicarse con la comunidad. Los novatos o prodigios de PostgreSQL tocan aquí para comunicarse, exhibir y compartir sus soluciones, tecnología, errores, nuevos hallazgos o incluso compartir su software emergente. Incluso puede pedir ayuda del chat de IRC usando irc.freenode.net y uniéndose al canal #postgresql. También puede comunicarse con la comunidad a través de Slack uniéndose a https://postgres-slack.herokuapp.com/ o https://postgresteam.slack.com/. Hay muchas opciones para tomar y muchas organizaciones de código abierto que pueden hacerle preguntas

Para obtener más detalles e información sobre dónde comenzar, consulte aquí https://www.postgresql.org/community/.

Si desea ir y pagar los servicios profesionales en PostgreSQL, hay toneladas de opciones para elegir. Incluso consultando su sitio web en https://www.postgresql.org/support/professional_support/northamerica/, puede encontrar una gran lista de empresas allí y algunas de ellas tienen un precio económico. Incluso aquí en Variousnines, también ofrecemos soporte para Postgres, que es parte de la licencia de ClusterControl o una consultoría de DBA.

Razón tres:  Amplia compatibilidad con la conformidad con SQL

PostgreSQL siempre ha tenido interés en adaptarse y ajustarse a SQL como un estándar de facto para su lenguaje. El nombre formal del estándar SQL es ISO/IEC 9075 "Lenguaje de base de datos SQL". Cualquier versión revisada sucesiva de las versiones estándar reemplaza a la anterior, por lo que las afirmaciones de conformidad con versiones anteriores no tienen mérito oficial.

A diferencia de Oracle, todavía están presentes algunas palabras clave u operadores que no cumplen con el estándar ANSI SQL (lenguaje de consulta estructurado). Ejemplo, el operador OUTER JOIN (+) puede atribuir confusiones con otros DBA's que no han tocado o con la menor familiaridad con Oracle. PostgreSQL sigue el estándar ANSI-SQL para la sintaxis JOIN y eso deja una ventaja para saltar fácil y simplemente con otras bases de datos RDBMS de código abierto como las bases de datos MySQL/Percona/MariaDB.

Otra sintaxis muy común con Oracle es el uso de consultas jerárquicas. Oracle utiliza la sintaxis START WITH..CONNECT BY no estándar, mientras que en SQL:1999, las consultas jerárquicas se implementan mediante expresiones de tabla comunes recursivas. Por ejemplo, las consultas a continuación difieren en su sintaxis de acuerdo con las consultas jerárquicas:

Oráculo

SELECT

    restaurant_name, 

    city_name 

FROM

    restaurants rs 

START WITH rs.city_name = 'TOKYO'

CONNECT BY PRIOR rs.restaurant_name = rs.city_name;

PostgreSQL

WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name

                                 FROM restaurants

                                WHERE city_name = 'TOKYO'

                                UNION

                               SELECT m.restaurant_name, m.city_name

                                 FROM restaurants m

                                 JOIN tmp ON tmp.restaurant_name = m.city_name)

                  SELECT restaurant_name, city_name FROM tmp;

PostgreSQL tiene un enfoque muy similar al de los otros RDBMS principales de código abierto como MySQL/MariaDB.

Según el manual de PostgreSQL, el desarrollo de PostgreSQL apunta a la conformidad con la última versión oficial del estándar donde dicha conformidad no contradiga las características tradicionales o el sentido común. Se admiten muchas de las características requeridas por el estándar SQL, aunque a veces con una sintaxis o función ligeramente diferente. Esto es, de hecho, lo bueno de PostgreSQL, ya que también cuenta con el apoyo y la colaboración de las diferentes organizaciones, ya sean pequeñas o grandes. La belleza se mantiene en la conformidad del lenguaje SQL con lo que tiene el impulso estándar.

El desarrollo de PostgreSQL apunta a la conformidad con la última versión oficial del estándar donde dicha conformidad no contradiga las características tradicionales o el sentido común. Se admiten muchas de las características requeridas por el estándar SQL, aunque a veces con una sintaxis o función ligeramente diferente. Se pueden esperar más avances hacia la conformidad con el tiempo.

Razón cuatro:Paralelismo de consultas

Para ser justos, el paralelismo de consultas de PostgreSQL no es tan rico en comparación con la ejecución paralela de Oracle para sentencias SQL. Entre las características del paralelismo de Oracle se encuentran la cola de declaraciones con sugerencias, la capacidad de establecer el grado de paralelismo (DOP), establecer una política de grado paralelo o el paralelismo adaptativo.

PostgreSQL tiene un grado simple de paralelismo basado en los planes admitidos, pero eso no define que Oracle supere al PostgreSQL de código abierto.

El paralelismo de PostgreSQL ha mejorado constantemente y mejorado continuamente por la comunidad. Cuando se lanzó PostgreSQL 10, agregó más atractivo para el público, especialmente las mejoras en el soporte de paralelismo para combinación de combinación, escaneo de montón de mapa de bits, escaneo de índice y escaneo de solo índice, fusión de recopilación, etc. Las mejoras también agregan estadísticas a pg_stat_actividad.

En las versiones de PostgreSQL <10, el paralelismo está deshabilitado de forma predeterminada, por lo que debe establecer la variable max_parallel_workers_per_gather.

postgres=# \timing

Timing is on.

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                   QUERY PLAN                                                   

----------------------------------------------------------------------------------------------------------------

 Seq Scan on movies  (cost=0.00..215677.28 rows=41630 width=68) (actual time=0.013..522.520 rows=84473 loops=1)

   Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

   Rows Removed by Filter: 8241546

 Planning time: 0.039 ms

 Execution time: 525.195 ms

(5 rows)



Time: 525.582 ms

postgres=# \o /dev/null 

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 596.947 ms

El plan de consulta revela que el tiempo real puede rondar los 522,5 ms, luego el tiempo real de ejecución de la consulta ronda los 596,95 ms. Mientras que habilitar el paralelismo,

postgres=# set max_parallel_workers_per_gather=2;

Time: 0.247 ms

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                          QUERY PLAN                                                           

-------------------------------------------------------------------------------------------------------------------------------

 Gather  (cost=1000.00..147987.62 rows=41630 width=68) (actual time=0.172..339.258 rows=84473 loops=1)

   Workers Planned: 2

   Workers Launched: 2

   ->  Parallel Seq Scan on movies  (cost=0.00..142824.62 rows=17346 width=68) (actual time=0.029..264.980 rows=28158 loops=3)

         Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

         Rows Removed by Filter: 2747182

 Planning time: 0.096 ms

 Execution time: 342.735 ms

(8 rows)



Time: 343.142 ms

postgres=# \o /dev/null

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 346.020 ms

El plan de consulta determina que la consulta necesita usar paralelismo y luego usa un nodo Gather. El tiempo real se estima en 339 ms con 2 trabajos y se estima en 264 ms antes de que el plan de consulta lo haya agregado. Ahora, el tiempo real de ejecución de la consulta tomó 346 ms, que está muy cerca del tiempo real estimado del plan de consulta.

Esto solo ilustra lo rápido y beneficioso que es con PostgreSQL. Aunque PostgreSQL tiene sus propios límites cuando puede ocurrir el paralelismo o cuando el plan de consulta determina que es más rápido que usar el paralelismo, no hace que su característica sea una gran diferencia con respecto a Oracle. El paralelismo de PostgreSQL es flexible y se puede habilitar o utilizar correctamente siempre que su consulta coincida con la secuencia requerida para el paralelismo de consultas.

Cinco motivo:Soporte JSON avanzado y siempre está mejorando

La compatibilidad con JSON en PostgreSQL siempre está a la par en comparación con otros RDBMS de código abierto. Eche un vistazo a este blog externo de LiveJournal donde la compatibilidad con JSON de PostgreSQL revela ser siempre más avanzada en comparación con los otros RDBMS. PostgreSQL tiene una gran cantidad de funciones y características JSON.

El tipo de datos JSON se introdujo en PostgreSQL-9.2. Desde entonces, tiene muchas mejoras significativas y, entre las principales, se presentó en PostgreSQL-9.4 con la adición del tipo de datos JSONB. PostgreSQL ofrece dos tipos de datos para almacenar datos JSON:json y jsonb. Con jsonb, es una versión avanzada del tipo de datos JSON que almacena los datos JSON en formato binario. Esta es la mejora principal que marcó una gran diferencia en la forma en que se buscaron y procesaron los datos JSON en PostgreSQL.

Oracle también cuenta con una amplia compatibilidad con JSON. Por el contrario, PostgreSQL tiene un amplio soporte, así como funciones que se pueden usar para la recuperación de datos, formateo de datos u operaciones condicionales que afectan la salida de los datos o incluso los datos almacenados en la base de datos. Los datos almacenados con el tipo de datos jsonb tienen una mayor ventaja con la capacidad de usar GIN (Índice invertido generalizado) que se puede usar para buscar de manera eficiente claves o pares clave/valor que ocurren dentro de una gran cantidad de documentos jsonb.

PostgreSQL tiene extensiones adicionales que son útiles para implementar TRANSFORM FOR TYPE para el tipo jsonb en sus lenguajes de procedimientos admitidos. Estas extensiones son jsonb_plperl y jsonb_plperlu para PL/Perl. Mientras que para PL/Python, estos son jsonb_plpythonu, jsonb_plpython2u y jsonb_plpython3u. Por ejemplo, al usar valores jsonb para mapear arreglos de Perl, puede usar las extensiones jsonb_plperl o jsonb_plperlu.

ArangoDB había publicado un punto de referencia que comparaba el rendimiento de JSON de PostgreSQL junto con otras bases de datos compatibles con JSON. Aunque es un blog antiguo, todavía muestra cómo funciona JSON de PostgreSQL en comparación con otras bases de datos donde JSON es la característica principal en su núcleo de base de datos. Esto solo hace que PostgreSQL tenga su propia ventaja incluso con su función secundaria.

Razón seis:compatibilidad con DBaaS por parte de los principales proveedores de la nube

PostgreSQL ha sido ampliamente compatible como DBaaS. Estos servicios provienen de Amazon, Microsoft con su base de datos Azure para PostgreSQL y Cloud SQL para PostgreSQL de Google.

En comparación, Oracle solo está disponible en Amazon RDS para Oracle. Los servicios ofrecidos por los principales jugadores comienzan a un precio asequible y son muy flexibles para configurarlos de acuerdo con sus necesidades. Esto ayuda a las instituciones y organizaciones a configurarse en consecuencia y aliviar su gran costo vinculado a la plataforma Oracle.

Séptima razón:mejor manejo de grandes cantidades de datos

PostgreSQL RDBMS no está diseñado para manejar cargas de trabajo analíticas y de almacenamiento de datos. PostgreSQL es una base de datos orientada a filas, pero tiene la capacidad de almacenar una gran cantidad de datos. PostgreSQL tiene los siguientes límites para manejar el almacén de datos:

Si desea utilizar las funciones principales de PostgreSQL, puede almacenar una gran cantidad de datos mediante jsonb. Por ejemplo, una gran cantidad de documentos (PDF, Word, hojas de cálculo) y almacenarlos usando el tipo de datos jsonb. Para aplicaciones y sistemas de geolocalización, puede utilizar PostGIS.

Razón ocho:escalabilidad, alta disponibilidad, redundancia/redundancia geográfica y soluciones tolerantes a fallas a bajo costo

Oracle ofrece soluciones similares, pero potentes, como Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware y Oracle Data Guard, por nombrar algunas. Estas tecnologías pueden aumentar sus costos crecientes y son impredeciblemente costosas de implementar y estabilizar. Es difícil deshacerse de estas soluciones. Se debe mejorar la capacitación y las habilidades y desarrollar a las personas involucradas en el proceso de despliegue e implementación.

PostgreSQL tiene soporte masivo y tiene muchas opciones para elegir. PostgreSQL incluye transmisión y replicación lógica integradas en el paquete central del software. También puede configurar una replicación síncrona para que PostgreSQL tenga más clústeres de alta disponibilidad, mientras hace que un nodo en espera procese sus consultas de lectura. Para obtener alta disponibilidad, le sugerimos que lea nuestro blog Principales soluciones de alta disponibilidad (HA) de clústeres de PG para PostgreSQL, que cubre una gran cantidad de excelentes herramientas y tecnología para elegir.

También hay características empresariales que ofrecen soluciones de respaldo, monitoreo y alta disponibilidad. ClusterControl es una de estas tecnologías y ofrece un precio asequible en comparación con Oracle Solutions.

Motivo nueve:compatibilidad con varios lenguajes de procedimiento:PL/pgSQL, PL/Tcl, PL/Perl y PL/Python.

Desde la versión 9.4, PostgreSQL tiene una gran función en la que puede definir un nuevo lenguaje de procedimiento de acuerdo con su elección. Aunque no se admite toda la variedad de lenguajes de programación, tiene varios lenguajes compatibles. Actualmente, con distribución base, incluye PL/pgSQL, PL/Tcl, PL/Perl y PL/Python. Los idiomas externos son:

Lo mejor de esto es que, a diferencia de Oracle, los desarrolladores que se han lanzado recientemente a PostgreSQL pueden proporcionar rápidamente lógica comercial a sus sistemas de aplicaciones sin tener que dedicar más tiempo a aprender sobre PL/SQL. PostgreSQL hace que el entorno para los desarrolladores sea más fácil y eficiente. Esta naturaleza de PostgreSQL contribuye a la razón por la cual a los desarrolladores les encanta PostgreSQL y comienzan a alejarse de las soluciones de plataforma empresarial hacia el entorno de código abierto.

Razón diez:índices flexibles para datos grandes y textuales (GIN, GiST, SP-GiST y BRIN)

PostgreSQL tiene una gran ventaja cuando se trata de soporte de índices que son beneficiosos para el manejo de grandes datos. Oracle tiene muchos tipos de índices que también son beneficiosos para manejar grandes conjuntos de datos, especialmente para la indexación de texto completo. Pero para PostgreSQL, estos tipos de índices están hechos para ser flexibles según su propósito. Por ejemplo, estos tipos de índices son aplicables para grandes datos:

GIN - (Índices invertidos generalizados) 

Este tipo de índice se aplica a las columnas de tipo de datos jsonb, hstore, range y arrays. Es útil cuando tiene tipos de datos que contienen múltiples valores en una sola columna. De acuerdo con los documentos de PostgreSQL, “GIN está diseñado para manejar casos en los que los elementos que se indexarán son valores compuestos, y las consultas que manejará el índice deben buscar valores de elementos que aparecen dentro de los elementos compuestos. Por ejemplo, los elementos podrían ser documentos y las consultas podrían ser búsquedas de documentos que contengan palabras específicas”.

GiST - (Árbol de búsqueda generalizado)

Un árbol de búsqueda de altura equilibrada que consta de páginas de nodos. Los nodos constan de filas de índice. Cada fila de un nodo hoja (leaf row), en general, contiene algún predicado (expresión booleana) y una referencia a una fila de la tabla (TID). Los índices GiST son mejores si los usa para tipos de datos geométricos como si desea ver si dos polígonos contienen algún punto. En un caso, un punto específico puede estar contenido dentro de un cuadro, mientras que otro punto solo existe dentro de un polígono. Los tipos de datos más comunes en los que desea aprovechar los índices GiST son los tipos de geometría y el texto cuando se trata de búsqueda de texto completo

Al elegir qué tipo de índice usar, GiST o GIN, tenga en cuenta estas diferencias de rendimiento:

• Las búsquedas en el índice GIN son unas tres veces más rápidas que las de GiST
• Los índices GIN tardan aproximadamente tres veces más en construirse que GiST
• Los índices GIN son moderadamente más lentos para actualizar que los índices GiST, pero aproximadamente 10 veces más lentos si se deshabilitó el soporte de actualización rápida
• Los índices GIN son dos o tres veces más grandes que los índices GiST

Como regla general, los índices GIN son mejores para datos estáticos porque las búsquedas son más rápidas. Para datos dinámicos, los índices GiST se actualizan más rápido.

SP-GiST - (GiST con particiones espaciales) 

Para conjuntos de datos más grandes con agrupamiento natural pero desigual. Este tipo de árboles de partición de espacio de aprovechamiento de índice. Los índices SP-GiST son más útiles cuando sus datos tienen un elemento de agrupamiento natural y tampoco son un árbol igualmente equilibrado. Un gran ejemplo de esto son los números de teléfono, por ejemplo en los EE. UU., usan el siguiente formato:

• 3 dígitos para el código de área
• 3 dígitos para el prefijo (históricamente relacionado con el cambio de un operador de telefonía)
• 4 dígitos para el número de línea

Esto significa que tiene un agrupamiento natural alrededor del primer conjunto de 3 dígitos, alrededor del segundo conjunto de 3 dígitos, luego los números pueden desplegarse en una distribución más uniforme. Pero, con los números de teléfono, algunos códigos de área tienen una saturación mucho mayor que otros. El resultado puede ser que el árbol esté muy desequilibrado. Debido a ese agrupamiento natural por adelantado y la distribución desigual de datos, datos como números de teléfono podrían ser un buen caso para SP-GiST.

BRIN - (Índice de rango de bloque) 

Para conjuntos de datos realmente grandes que se alinean secuencialmente. Un rango de bloques es un grupo de páginas adyacentes entre sí, donde la información de resumen sobre todas esas páginas se almacena en el Índice. Los índices de rango de bloques pueden enfocarse en algunos casos de uso similares a SP-GiST en el sentido de que son mejores cuando hay un orden natural en los datos, y los datos tienden a ser muy grandes. ¿Tiene una tabla de mil millones de registros, especialmente si se trata de datos de series temporales? BRIN puede ayudar. Si está consultando un gran conjunto de datos que se agrupan de forma natural, como los datos de varios códigos postales (que luego se acumulan en alguna ciudad), BRIN ayuda a garantizar que los códigos postales similares estén ubicados uno cerca del otro en el disco.

Cuando tiene conjuntos de datos muy grandes que están ordenados, como fechas o códigos postales, los índices BRIN le permiten omitir o excluir una gran cantidad de datos innecesarios muy rápidamente. BRIN, además, se mantienen como índices más pequeños en relación con el tamaño total de los datos, lo que los convierte en una gran ventaja cuando se tiene un gran conjunto de datos.

Conclusión

PostgreSQL tiene algunas ventajas importantes cuando compite con la plataforma empresarial y las soluciones comerciales de Oracle. Definitivamente es fácil aclamar a PostgreSQL como su elección de RDBMS de código abierto, ya que es casi tan poderoso como Oracle.

Oracle es difícil de superar (y esa es una verdad difícil de aceptar) y tampoco es fácil deshacerse de la plataforma empresarial del gigante tecnológico. Cuando los sistemas le brindan poder y resultados productivos, eso podría ser un dilema.

A veces, sin embargo, hay situaciones en las que se debe tomar una decisión, ya que la inversión excesiva continua en el costo de su plataforma puede superar el costo de sus otras capas comerciales y prioridades, lo que puede afectar el progreso.

PostgreSQL y sus soluciones de plataforma subyacentes pueden ser de su elección para ayudarlo a reducir costos, aliviar sus problemas presupuestarios; todos con cambios moderados a pequeños.