Estructura del código fuente de Postgresql
PostgreSQL admite casi todos los estándares SQL y los tipos admitidos también son bastante ricos. El código fuente de la base de datos PostgreSQL es más fácil de leer que el código fuente de la base de datos MySQL. Si el equipo tiene sólidas capacidades en lenguaje C, puede desarrollarse en la base de datos PostgreSQL, como implementar un sistema similar a greenplum, que también puede cumplir con la tendencia distribuida actual.
Para ilustrar las funciones de PostgreSQL, comparemos brevemente la base de datos PostgreSQL y la base de datos Mysql de "50 cosas que debes saber antes de migrar de Oracle a MySQL".
50 Dificultades al migrar de Oracle a Mysql, 1. Bajo rendimiento de subconsultas. (PostgreSQL puede resolverlo)
2. La capacidad de procesamiento de consultas complejas es débil. (PostgreSQL puede solucionarlo)
3. El optimizador de consultas no es lo suficientemente maduro. (PostgreSQL puede resolverlo)
PostgreSQL es totalmente compatible con el estándar SQL-92 y SQL, y puede admitir consultas SQL complejas.
4. Herramientas de optimización del rendimiento e información de medición insuficientes. (PostgreSQL puede resolverlo)
PostgreSQL proporciona planes de ejecución y valores de costos detallados, lo que facilita ver la eficiencia de ejecución de SQL.
5. La función de auditoría es relativamente débil.
6. La función de seguridad es inmadura, no existe un concepto de grupos y roles de usuarios y no existe una función para reciclar permisos (solo se pueden otorgar permisos). Cuando un usuario inicia sesión con el mismo nombre de usuario/contraseña desde un host/red diferente, puede ser tratado como un usuario completamente diferente sin las capacidades de cifrado integradas de Oracle.
7. La función de autenticación está completamente integrada y no es compatible con LDAP, Active Directory u otras funciones de autenticación externas similares.
8.MysqlCluster puede ser muy diferente de lo que piensas.
9. Las funciones de los procedimientos almacenados y los disparadores son limitadas. (PostgreSQL puede resolverlo)
PostgreSQL proporciona soporte completo para procedimientos almacenados y activadores.
10. Escalabilidad vertical débil.
11, no soporta MPP (procesamiento paralelo masivo). (PostgreSQL puede resolverlo)
PostgreSQL es una arquitectura multiproceso similar a la base de datos Oracle, a diferencia de MySQL, que es una arquitectura multiproceso, por lo que puede admitir MPP.
12, admite SMP (multiprocesador simétrico), pero si cada procesador tiene 4 núcleos o más de 8 núcleos, la escalabilidad de Mysql es muy pobre.
13. Para tipos de tiempo como hora, fecha e intervalo, no hay tipos de almacenamiento inferiores a segundos.
14. Las funciones del lenguaje que se pueden utilizar para escribir procedimientos almacenados, activadores, eventos programados y funciones almacenadas son relativamente débiles.
15, no existe una función de recuperación basada en reversión, solo una función de recuperación en avance.
16. La función de instantánea no es compatible.
17. El enlace a la base de datos no es compatible. Existe un motor de almacenamiento llamado Federado, que se puede utilizar como retransmisión para transmitir declaraciones de consulta a tablas en servidores remotos. Pero sus funciones son toscas y existen muchas lagunas.
18. La verificación de la integridad de los datos es muy débil y, a menudo, ni siquiera se implementan las restricciones de integridad básicas. (PostgreSQL puede resolverlo)
PostgreSQL proporciona un mecanismo completo de verificación de la integridad de los datos y admite claves externas.
19. Hay algunas sugerencias de optimizador para optimizar el plan de ejecución de la declaración de consulta.
20. Sólo hay un tipo de combinación de tablas: no se admiten bucles anidados, combinaciones de combinación ordenadas ni combinaciones hash. (PostgreSQL puede resolverlo)
PostgreSQL admite estos tipos de conexión de tablas.
21. La mayoría de las consultas solo pueden usar un único índice en la tabla; en algunos casos, habrá consultas que usan múltiples índices, pero el optimizador de consultas generalmente subestima su costo y generalmente son más pequeños que la tabla; el escaneo es lento. (PostgreSQL puede solucionarlo)
Los datos de PostgreSQL no tienen este problema. Suponga que hay dos índices en col2 de col1 en la tabla T, idx_1 e idx_2, luego seleccione * desde donde col 1 =: aandcol 2 =: b al realizar la consulta, la base de datos PostgreSQL puede convertir esta consulta en Seleccionar * desde donde col 1; =:ainterectselect * desde donde col 2 =:b, para que se puedan utilizar ambos índices.
22. Bitmapindex no es compatible. Cada motor de almacenamiento admite diferentes tipos de índices. La mayoría de los motores de almacenamiento admiten índices de árbol B.
23. Hay pocas herramientas de gestión y las funciones no están lo suficientemente maduras.
24. No existen depuradores y herramientas IDE maduros y satisfactorios. Es posible que deba escribir procedimientos almacenados en un editor de texto y depurarlos insertando registros en una tabla (tabla de registro de depuración).
25. Cada tabla puede utilizar un motor de almacenamiento diferente. (PostgreSQL puede resolverlo)
26. Cada motor de almacenamiento puede variar mucho en comportamiento, características y funcionalidad. (PostgreSQL puede solucionarlo)
27. La mayoría de los motores de almacenamiento no admiten claves externas. (PostgreSQL puede solucionarlo)
28. El motor de almacenamiento predeterminado (MyISAM) no admite transacciones y se daña fácilmente. (PostgreSQL puede solucionarlo)
29. InnoDB es el motor de almacenamiento más avanzado y popular, propiedad de Oracle. (PostgreSQL puede resolverlo)
30. Algunos planes de ejecución solo admiten motores de almacenamiento específicos. Un determinado tipo de consulta de recuento que es rápida en este motor de almacenamiento puede ser lenta en otro motor de almacenamiento. (PostgreSQL puede resolverlo)
PostgreSQL tiene solo un motor de almacenamiento, por lo que la situación anterior no existe. PostgreSQL admite transacciones perfectas.
31. El plan de ejecución no se comparte globalmente, solo se comparte dentro de la conexión.
32. La función de búsqueda de texto completo es limitada y solo funciona con motores de almacenamiento no transaccionales. Lo mismo ocurre con consultas y tipos espaciales/GIS. (PostgreSQL puede resolverlo)
La base de datos PostgreSQL admite búsqueda de texto completo y más tipos de índices, como índices B-tree, R-tree, Hash, GIST, GIN, R-tree, GiST y GIN. , que se puede utilizar para tipos espaciales y consultas.
33. Sin control de recursos. Un usuario completamente no autorizado puede agotar fácilmente toda la memoria de un servidor y bloquearlo, o agotar todos los recursos de su CPU.
34. No existe integración de inteligencia empresarial, conjuntos de datos OLAP** * *y otros paquetes de software.
35. No existe ninguna herramienta similar a GridControl.
36. No existe una función similar a la del RAC. Si pregunta "Cómo construir RAC con Mysql", solo se puede decir que está haciendo la pregunta equivocada.
37. Los tipos o campos definidos por el usuario no son compatibles. (PostgreSQL puede resolverlo)
PostgreSQL admite tipos enriquecidos y tipos personalizados.
38. El número máximo de conexiones admitidas por consulta es 61.
39. Una pequeña parte de la sintaxis SQL soportada por MySQL (estándar ANSISQL). No se admiten consultas recursivas, expresiones generales de tablas (Oracle con declaraciones) ni funciones de ventana (funciones analíticas). Admite algunas extensiones de sintaxis SQL como Merge o funciones similares, pero las funciones son muy simples en comparación con Oracle. (PostgreSQL puede resolverlo)
Todas estas bases de datos PostgreSQL son compatibles, como funciones de ventana.
40. Las columnas de funciones no son compatibles (columnas basadas en cálculos o expresiones, Oracle11g comenzó a admitir columnas calculadas y versiones anteriores admitían rownum, rowid)).
41. Los índices funcionales no son compatibles y solo se pueden crear índices basados en columnas específicas. (PostgreSQL puede resolverlo)
PostgreSQL admite índices de funciones.
42. No se admiten vistas materializadas.
43. Las estadísticas varían mucho entre los diferentes motores de almacenamiento. Todos los motores de almacenamiento solo admiten cardinalidad simple y un cierto rango de registros (filas dentro del rango). En otras palabras, las estadísticas de distribución de datos son limitadas. No existen muchos mecanismos para actualizar las estadísticas.
44. No hay mecanismos integrados de equilibrio de carga y conmutación por error.
45. La función de copia es asíncrona y tiene grandes limitaciones. Por ejemplo, es de un solo subproceso, por lo que es difícil para un esclavo con mayor poder de procesamiento recuperarse más rápido que un maestro con un poder de procesamiento relativamente lento.
46. El clúster no es tan perfecto como se imagina. Tal vez ya haya mencionado esto, pero vale la pena repetirlo.
47. El diccionario de datos (INFORMATION_SCHEMA) tiene una funcionalidad muy limitada y su acceso es muy lento (y puede fallar fácilmente en un sistema ocupado).
48. No se admiten operaciones de tabla de cambios en línea.
49. No se admiten secuencias. (PostgreSQL puede resolverlo)
PostgreSQL admite secuencias.
50. Operaciones como ALTERTABLE o CREATETABLE no son transaccionales. Realizarán transacciones no confirmadas y no podrán revertir ni realizar recuperación ante desastres. Schame se guarda en el sistema de archivos, independientemente del motor de almacenamiento que utilice. (PostgreSQL puede solucionarlo)
PostgreSQL no tiene este problema.
Cada base de datos tiene diferentes escenarios de aplicación. PostgreSQL es más confiable y admite la coherencia e integridad de los datos que MySQL. Por lo tanto, PostgreSQL es más adecuado para escenarios de aplicaciones empresariales estrictas, la velocidad de consulta de MySQL es más rápida y es más adecuado para escenarios de Internet con una lógica empresarial relativamente simple y bajos requisitos de confiabilidad de datos. Las opiniones personales anteriores son bienvenidas para criticar y corregir.
Estoy de acuerdo contigo, por favor déjalo si te gusta, ¡gracias!
Si te gusto, sígueme. ¡Gracias de nuevo!