versiones ventajas tutorial desventajas descargar caracteristicas database performance postgresql

database - ventajas - postgresql versiones



que db debo seleccionar si el rendimiento de postgres es bajo (12)

En una aplicación web que admite más de 5000 usuarios, postgres se está convirtiendo en el cuello de botella.

Lleva más de 1 minuto agregar un nuevo usuario. (Incluso después de las optimizaciones y en Win 2k3)

Entonces, como problema de diseño, ¿qué otros DB podrían ser mejores?

Creo que tu mejor opción sigue siendo PostgresSQL. Dedique un tiempo para asegurarse de haber ajustado su aplicación correctamente. Después de que confía en que ha alcanzado los límites de lo que se puede hacer con la optimización, comience a almacenar en caché todo lo que pueda. Después de eso, comience a pensar en pasar a una configuración de maestro esclavo asíncrono ... ¿También está ejecutando la funcionalidad de tipo OLAP en la misma base de datos en la que está haciendo su OLTP?

PostgreSQL escalas mejor que la mayoría, si vas a quedarte con un DB relacional, Oracle lo sería. ODBMS escala mejor, pero tienen sus propios problemas, ya que está más cerca de la programación para configurar uno.
Yahoo usa PostgreSQL , eso debería decirle algo acerca de la escalabilidad.

Primero, me aseguraré de que las optimizaciones sean, de hecho, útiles. Por ejemplo, si tiene muchos índices, a veces agregar o modificar un registro puede llevar mucho tiempo. Sé que hay varios proyectos grandes ejecutando PostgreSQL, así que eche un vistazo a este problema.

Cambie el sistema operativo bajo el cual ejecuta Postgres: el puerto de Windows, aunque inmensamente útil para ampliar la base de usuarios, todavía no está a la par de los puertos Un * x (mucho más antiguos y más maduros) (y especialmente el de Linux).

Permítanme presentarles la forma más simple y práctica de escalar casi cualquier servidor de base de datos si el diseño de la base de datos es realmente óptimo: simplemente duplique su ram para un aumento instantáneo en el rendimiento. Es como magia.

Si desea alejarse de PostgreSQL, Sybase SQL Anywhere es el número 5 en términos de precio / rendimiento en la lista de referencia de TPC-C . También es la opción de precio más bajo (de lejos) en la lista de los 10 principales, y es la única entrada que no es de Microsoft y que no es de Oracle.

Puede escalar fácilmente a miles de usuarios y terabytes de datos.

Divulgación completa: trabajo en el equipo de desarrollo de SQL Anywhere.

Lo más probable es que no sea PostgreSQL, es su diseño. Cambiar los zapatos lo más probable es que no te convierta en un mejor bailarín.

¿Sabes lo que está causando la lentitud? ¿Es competencia, es hora de actualizar índices, buscar tiempos? ¿Están todos los 5000 usuarios intentando escribir en la tabla de usuarios en el mismo momento exacto en que intentan insertar el usuario 5001? Eso, puedo creer que puede causar un problema. Puede que tenga que ir con algo sintonizado para manejar concurrencia extrema, como Oracle.

MySQL (según me dicen) se puede optimizar para hacer lecturas más rápidas que PostgreSQL, pero ambas son bastante ridículamente rápidas en términos de # transacciones / segundo que admiten, y no parece que ese sea su problema.

PD. Tuvimos una pequeña discusión en los comentarios sobre una respuesta diferente. Tenga en cuenta que algunas de las bases de datos más grandes del mundo, basadas en el almacenamiento, se implementan usando Postgres (aunque tienden a modificar las funciones internas del motor). Postgres escala extremadamente bien el tamaño de los datos, para la concurrencia mejor que la mayoría, y es muy flexible en términos de lo que puede hacer con él.

Ojalá hubiera una mejor respuesta para usted, 30 años después de que se inventó la tecnología, deberíamos poder hacer que los usuarios tengan un conocimiento menos detallado del sistema para que funcione sin problemas. Pero, por desgracia, se requiere una amplia reflexión y ajustes para todos los productos que conozco. Me pregunto si los creadores de podrían compartir cómo manejaron la concurrencia y escalabilidad de db. Están usando SQLServer, lo sé tanto.

PPS Así que, a falta de suerte, ayer me estrellé de cabeza en un problema de concurrencia en Oracle. No estoy seguro de tener razón, no ser un DBA, pero lo que los chicos explicaron fue algo como esto: tuvimos una gran cantidad de procesos conectando con el DB y examinando el diccionario del sistema, lo que aparentemente obliga a cerrarlo brevemente , a pesar de que es solo una lectura. Las consultas de análisis hacen lo mismo ... así que tuvimos (en un sistema multitera con miles de objetos) muchos tiempos de espera forzados porque los procesos se bloqueaban mutuamente fuera del sistema. Nuestro diccionario de sistema también fue excesivamente grande porque contiene una copia separada de toda la información para cada partición, de la cual puede haber miles por tabla. Esto no está realmente relacionado con PostgreSQL, pero lo más importante es que, además de verificar su diseño, asegúrese de que sus consultas utilicen variables de enlace y de que se vuelvan a utilizar, y la presión sobre los recursos compartidos es mínima.

Necesitamos más detalles: ¿qué versión está usando? ¿Cuál es el uso de memoria del servidor? ¿Estás limpiando la base de datos? Sus problemas de rendimiento podrían no estar relacionados con PostgreSQL.

Si tiene muchas lecturas sobre escrituras, es posible que desee probar MySQL suponiendo que el problema es con Postgres, pero su problema es un problema de escritura.

Aún así, es posible que desee examinar el diseño de su base de datos y posiblemente considerar la posibilidad de fragmentación. Para una base de datos realmente grande, puede que tenga que mirar los 2 problemas anteriores independientemente.

También puede consultar servidores de bases de datos que no sean RDBMS o documentos orientados como Mensia y CouchDB dependiendo de la tarea en cuestión. Ninguna herramienta única administrará todas las tareas, por lo tanto, elija sabiamente.

Solo por curiosidad, ¿tiene algún procedimiento almacenado que pueda estar causando este retraso?

Como se destacó anteriormente, el problema no está en la base de datos particular que está utilizando, es decir, PostgreSQL sino en una de las siguientes:

  • Esquema de diseño, tal vez necesita agregar, eliminar, refinar sus índices
  • El hardware tal vez le pregunte a gran parte de su servidor: dijo 5k usuarios pero, de nuevo, muy pocos probablemente consulten el DB al mismo tiempo.
  • Consultas: quizás mal definidas, lo que resulta en mucha ineficiencia

Una forma pragmática de averiguar qué está sucediendo es analizar los archivos de registro de PostgeSQL y descubrir qué consultas en términos de:

  • Más frecuentemente ejecutado
  • La carrera más larga
  • etcétera etcétera.

Una revisión rápida le indicará dónde concentrar sus esfuerzos y lo más probable es que resuelva sus problemas con bastante rapidez. No hay una solución mágica, tienes que hacer algunos deberes, pero esto será pequeño en comparación con cambiar tu proveedor de db.

Buenas noticias ... hay muchas utilidades para analayse sus archivos de registro que son fáciles de usar y producen resultados fáciles de interpretar, aquí hay dos:

pgFouine - un analizador de registro PostgreSQL (PHP)

PQA (ruby)

Hola, tuve el mismo problema anteriormente con mi compañía actual. Cuando me uní a ellos por primera vez, sus consultas fueron enormes y muy lentas. Lleva 10 minutos ejecutarlos. Pude optimizarlos a unos pocos milisegundos o 1 a 2 segundos. Aprendí muchas cosas durante ese tiempo y compartiré algunos aspectos destacados en ellas.

  1. Verifique su consulta primero. hacer una combinación interna de todas las tablas que necesita siempre llevará algún tiempo. Una cosa que sugeriría es comenzar siempre con la tabla con la que realmente puede cortar sus datos a los que necesita.

    por ejemplo, SELECCIONAR * FROM (SELECCIONAR * FROM persona DONDE persona ilike ''% abc'') COMO persona;

Si miras el ejemplo anterior, esto reducirá tus resultados a algo que sabes que necesitas y puedes refinarlos más haciendo una unión interna. Esta es una de las mejores maneras de acelerar su consulta, pero hay más de una manera de despellejar un gato. No puedo explicarlos todos aquí porque son demasiados, pero a partir del ejemplo anterior, solo necesita modificar eso para adaptarlo a sus necesidades.

  1. Depende de tu versión de postgres. El postgres anterior optimiza internamente la consulta. en el ejemplo es que en postgres 8.2 y siguientes, las declaraciones IN son más lentas que las 8.4.

  2. EXPLAIN ANALYZE es tu amigo. si su consulta se está ejecutando lentamente, haga un análisis de explicación para determinar cuál de ellos está causando la lentitud.

  3. Aspire su base de datos. Esto asegurará que las estadísticas en su base de datos casi coincidan con el resultado real. Se producirá una gran diferencia en las estadísticas y en la realidad cuando la consulta se ejecute lentamente.

  4. Si todo esto no te ayuda, intenta modificar tu postgresql.conf. Aumente la memoria compartida e intente experimentar con la configuración para satisfacer mejor sus necesidades.

Espero que esto ayude, pero por supuesto, estos son solo para la optimización de postgres.

por cierto. 5000 usuarios no son mucho. Mi DB contiene usuarios con aproximadamente 200,000 usuarios.