¿Qué tan grande es demasiado para una tabla PostgreSQL?

127

Estoy trabajando en el diseño de un proyecto de RoR para mi empresa, y nuestro equipo de desarrollo ya se ha enfrentado a un debate sobre el diseño, específicamente la base de datos.

Tenemos un modelo llamado Messageque debe persistir. Es un modelo muy, muy pequeño con solo tres columnas de db además de la identificación, sin embargo, es probable que haya MUCHOS de estos modelos cuando entremos en producción. Estamos viendo hasta 1,000,000 de inserciones por día. Los modelos solo serán buscados por dos claves externas en ellos que se pueden indexar. Además, los modelos nunca tienen que eliminarse, pero tampoco tenemos que conservarlos una vez que tienen unos tres meses.

Entonces, lo que nos preguntamos es si la implementación de esta tabla en Postgres presentará un problema de rendimiento significativo. ¿Alguien tiene experiencia con bases de datos SQL muy grandes para decirnos si esto será un problema o no? Y si es así, ¿con qué alternativa deberíamos ir?

— Dylan Karr
fuente

con una buena capa de almacenamiento en caché y una pequeña configuración en PG, debería estar bien. Debe abordar los problemas de rendimiento caso por caso y evitar la preoptimización. Dicho esto, la partición y la replicación son siempre excelentes opciones que puede aprovechar una vez que se encuentra con cuellos de botella.

— Sam

Pregunta relacionada aquí y aquí .

— Erwin Brandstetter

Procesamos alrededor de 30 millones de mensajes por día en una base de datos PostgreSQL de más de 5 TB, funciona bien.

— Frank Heikens

ver también stackoverflow.com/questions/3132444/…

— rogerdpack

Para su información, estaba leyendo postgresql.org/about hoy y noté que dice que (en principio) el número de filas en una tabla es ilimitado.

— Al Chou

Respuestas:

115

Las filas por tabla no serán un problema por sí mismas.

Entonces, aproximadamente, 1 millón de filas al día durante 90 días son 90 millones de filas. No veo ninguna razón por la que Postgres no pueda lidiar con eso, sin conocer todos los detalles de lo que está haciendo.

Dependiendo de su distribución de datos, puede usar una combinación de índices, índices filtrados y particiones de tablas de algún tipo para acelerar las cosas una vez que vea qué problemas de rendimiento puede tener o no. Su problema será el mismo en cualquier otro RDMS que yo conozca. Si solo necesita 3 meses de diseño de datos en un proceso para eliminar los datos, no necesita más. De esa manera, tendrá un volumen constante de datos sobre la mesa. Tiene suerte de saber cuántos datos existirán, pruébelos para su volumen y vea qué obtiene. Probar una tabla con 90 millones de filas puede ser tan fácil como:

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited

— Kuberchaun
fuente

Estoy de acuerdo en que 90 millones de filas no serán un problema para PostgreSQL. Pero podría ser un problema para un ORM con PostgreSQL. (Un ORM con cualquier DBMS, en realidad.)

— Mike Sherrill 'Cat Recall'

@ MikeSherrill'Catcall 'Buen punto, solo estaba concentrado en "¿Qué tan grande es demasiado para una tabla PostgreSQL?"

— Kuberchaun

@yeyo: Porque los ORM suelen utilizar muchas consultas para obtener datos que podrían devolverse con solo una o dos. El OP está utilizando Ruby on Rails.

— Mike Sherrill 'Cat Recall'

Esto es un poco tarde, pero creo que en muchos casos (especialmente con rieles / registro activo) es común eliminar completamente el ORM de la ecuación y escribir una cadena SQL sin procesar para consultar por razones de rendimiento. ¡No permita que su ORM tome decisiones sobre datos por usted! Es un accesorio, no imprescindible.

— Stefan Theard

La URL acerca de citada en la URL no muestra estos límites actualmente. ¿Alguien sabe a dónde se movió?

— Shorn el

Otra forma de acelerar significativamente sus consultas en una tabla con> 100 millones de filas es en las horas de inactividad agrupar la tabla en el índice que se usa con más frecuencia en sus consultas. Tenemos una tabla con más de 218 millones de filas y hemos encontrado 30 veces mejoras.

Además, para una tabla muy grande, es una buena idea crear un índice en sus claves externas.

— James Doherty
fuente

> en las horas de descanso agrupe la tabla en el índice que se utiliza con más frecuencia en sus consultas ... ¿puede explicar cómo se hace esto?

— espiar

Sí, aquí hay un EJEMPLO paso a paso: 1) La tabla a la que me refiero se llama inversión en este ejemplo. 2) El índice más utilizado en las consultas es (bankid, record_date) Así que aquí está su paso a paso: 1) psql -c "drop index investment_bankid_rec_dt_idx;" dbname 2) psql -c "crear índice investment_bankid_rec_dt_idx en la inversión (bankid, record_date);" 3) psql -c "cluster investment_bankid_rec_dt_idx sobre inversión"; 4) vacuumdb -d ccbank -z -v -t inversión Así que en los pasos uno y dos eliminamos el índice y lo volvemos a crear.

— James Doherty

Paso 3 creamos el clúster, esto básicamente coloca la tabla DB en el orden físico del índice, por lo que cuando postgresql realiza una consulta, almacena en caché las siguientes filas más probables. Paso 4 aspiramos la base de datos para restablecer las estadísticas del planificador de consultas

— James Doherty