Al leer numerosos art铆culos en el centro sobre la migraci贸n exitosa de Oracle a PostgreSQL, un lector inexperto puede tener la impresi贸n de que PostgreSQL no es peor, o incluso mejor que Oracle. Y la elecci贸n es obvia. Y los cientos de miles de empresas que terminan pagando miles de millones de d贸lares a Oracle solo est谩n desperdiciando su dinero. Pero intentar茅 tranquilizarlo, d贸nde, d贸nde y en las grandes empresas saben c贸mo contar el dinero. Y sus decisiones de ninguna manera est谩n equivocadas.
El prop贸sito del art铆culo es crear un grano de duda en el alma de un lector que est谩 tratando de elegir entre bases de datos relacionales que funcionan en modo versionado.
驴Por qu茅 exactamente el modo versionado? Aqu铆 la elecci贸n no es grande, pero en los bloqueadores hay competidores dignos y la elecci贸n es a煤n m谩s dif铆cil (驴Cu谩nto cuesta la versi贸n gratuita de DB2 para bases de datos peque帽as?)
No soy un experto en la base de datos Oracle, aunque he trabajado con esta base de datos durante muchos a帽os y no solo con ella. Todo lo que puedo hacer es usar sus ventajas y lograr un rendimiento 贸ptimo. Adem谩s, no soy un experto en PostgreSQL (nunca lo he usado en producci贸n).
Lectura de art铆culos sobre migraci贸n exitosa: entiendo que estas empresas ni siquiera necesitaban Oracle o que la base de datos se seleccion贸 inicialmente incorrectamente. Usaron solo una peque帽a fracci贸n de las capacidades de esta base de datos. Solo as铆 podr铆an tomar una decisi贸n sobre la migraci贸n e implementarla. Simplemente, si usa toda la potencia de esta base de datos, nunca tendr谩 el deseo de migrar porque es similar a escribir su aplicaci贸n desde cero.
Finalmente, hablemos sobre los beneficios de rendimiento que proporciona Oracle y, bas谩ndose en esta informaci贸n, encontrar谩 la respuesta por s铆 mismo.
- Partici贸n (8i) . Partici贸n: permite el crecimiento del volumen de datos pr谩cticamente sin efecto en el rendimiento general. Una ventaja agradable e importante es la partici贸n de 铆ndices. Las particiones PostgreSQL aparecer谩n solo en la versi贸n 10. Antes de esto, la herencia (HEREDAS) es un truco sucio. Y las capacidades de partici贸n en Oracle est谩n aumentando con cada versi贸n.
- Fusionar (8i) . S铆, s铆, la misma combinaci贸n que ha estado en MSSQL durante muchos a帽os (2008) y que ni siquiera existir谩 en PostgreSQL 11. Proporciona un aumento de diez veces en velocidad en comparaci贸n con las operaciones individuales. S铆, s茅 que PostgreSQL admite subconsultas y puede implementar todo a trav茅s de Insert select y la actualizaci贸n complicada. Pero esto est谩 lejos de ser lo mismo.
- RESULT_CACHE (Seleccionar) (11g). En Oracle, esta tecnolog铆a apareci贸 hace relativamente poco. Si usa esta tecnolog铆a con prudencia, le da una ganancia en algunas cosas decenas o cientos de veces. Lo principal es aprender a usarlo de manera inteligente.
- Opci贸n INMEMORY ( 12 ) No hay an谩logo en PostgreSQL. Crecimiento real en algunas consultas cientos de veces.
- Optimizador + ajuste de consultas . Comenzando con 11g, se convirti贸 en casi un clic en siguiente-> siguiente en EM. PostgreSQL es m谩s complicado con esto, y la falta de un an谩logo de EM en su conjunto es bastante inc贸modo.
PL / SQL. S铆, s茅 sobre la variedad de idiomas en PostgreSQL. Pero Oracle mejora constantemente el lenguaje con un enfoque en el rendimiento.
- Compilaci贸n El bycode ocurre durante el guardado (en PostgreSQL durante la primera llamada en el plan de sesi贸n + consulta durante la primera ejecuci贸n). Comenzando con 10g, Oracle puede compilar en c贸digo nativo.
- Entero nativo : acelera significativamente el trabajo con n煤meros. PostgreSQL puede usar otros lenguajes m谩s adecuados (traductores). En Oracle, esto tambi茅n se puede resolver usando Java y C.
- Cambiar el "contexto" de PL / SQL. Oracle est谩 muy preocupado por optimizar esta m茅trica y mejorarla de una versi贸n a otra. Para reducir los retrasos Al cambiar el "contexto", obtenga BULK COLLECT y FORALL y m谩s.
Dado el estado de los lenguajes PostgreSQL, esta tarea no es importante en esta etapa. - Cach茅 de resultados (funci贸n) (11 g) Con el uso adecuado, la capacidad de respuesta de la aplicaci贸n en su conjunto puede crecer varias veces sin requerir mucho esfuerzo. En algunas consultas docenas de veces.
Bueno, como dicen, el diablo est谩 en los detalles, y Oracle ha resuelto estos detalles mucho mejor. Oracle nunca deja de sorprender con cada versi贸n. Y no importa a qu茅 base de datos se transfiera despu茅s de Oracle; siempre tendr谩 la sensaci贸n: bueno, maldita sea, en Oracle ha sido durante mucho tiempo, o en Oracle est谩 mejor hecho.
Estoy casi seguro de que con el mismo hardware y con todas las caracter铆sticas de PostgreSQL y Oracle, puede obtener un mejor rendimiento, con menos esfuerzo en ORACLE.
PD En ning煤n caso, no considere este art铆culo como una base de datos de relaciones p煤blicas de Oracle.
Entiendo bien que siempre hay cosas que se hacen mejor en PostgreSQL. Pero en general, Oracle en este segmento de la base de datos n煤mero 1.
Espec铆ficamente no toqu茅 cosas relacionadas con la administraci贸n. Imagine que puede transferir el archivo de fecha de un disco a otro o restaurar el "bloque roto" en el estado En l铆nea. Y puede hacer la transici贸n a nuevos servidores sin detener la base de datos. Y estas no son caracter铆sticas nuevas. En Oracle, todo es mucho mejor all铆, y no soy administrador de DB.
Anteriormente, en alg煤n lugar hasta la versi贸n 10, el administrador casi siempre era necesario. Ahora, la necesidad de administrador ha disminuido dr谩sticamente, aunque las calificaciones del administrador ahora se necesitan m谩s. Quiz谩s, en la versi贸n 15, el concepto de DB "admin" ser谩 cosa del pasado :)
S铆, y Pl / SQL es m谩s atento que otros, aunque, por supuesto, esto no es C # :). Es cierto que esto es puramente individual.
Bueno, no toqu茅 cosas que ayudan poco en velocidad.
PSS Y s铆, apenas recuerdo todas las posibilidades. Solo aquellos que estaban en la "superficie". Agregue los comentarios. Lo incluir茅 en upd.