2010-06-28 27 views
40

Me doy cuenta de que, por documentos Pg (http://www.postgresql.org/about/), se puede almacenar un número ilimitado de filas en una tabla. Sin embargo, ¿cuál es la "regla de oro" para el número utilizable de filas, si corresponde?Número máximo (utilizable) de filas en una tabla de Postgresql

Antecedentes: deseo almacenar lecturas diarias durante un par de décadas para 13 millones de células. Eso funciona hasta 13 M * (366 | 365) * 20 ~ 9.5e10, o 95 filas B (en realidad, alrededor de 120 filas B).

Por lo tanto, al usar la división de tablas, configuré una tabla maestra y luego heredé las tablas por año. Eso divide las filas a ~ 5.2 B filas por mesa.

Cada fila es 9 SMALLINTs, y dos INTs, entonces, 26 bytes. Agregue a eso, la sobrecarga de Pg de 23 bytes por fila, y obtenemos 49 bytes por fila. Entonces, cada tabla, sin PK u otro índice, pesará en ~ 0.25 TB.

Para empezar, he creado solo un subconjunto de los datos anteriores, es decir, solo para unas 250,000 celdas. Tengo que hacer un montón de ajustes (crear índices adecuados, etc.), pero el rendimiento es realmente terrible en este momento. Además, cada vez que necesite agregar más datos, tendré que soltar las teclas y volver a crearlas. La ventaja es que una vez que todo está cargado, será una base de datos de solo lectura.

¿Alguna sugerencia? ¿Alguna otra estrategia para particionar?

+0

Sin un ajuste adecuado, el rendimiento tiene que ser malo, ninguna base de datos igualará su situación, ni la mía. Primero averigüe cuáles son los problemas, luego puede comenzar a resolverlos. –

+0

¿Qué tal resumir sus datos, realmente necesita esta granularidad? – pcent

+0

pcent - sí, necesito esta granularidad. Frank Heikens - sí, necesito sintonizar el DB, y estoy en proceso de identificar los problemas. Mi pregunta era de naturaleza preventiva, para tablas db de ese tamaño de las que estoy hablando. – punkish

Respuesta

45

No es solo "un montón de ajustes (índices, etc.)". Esto es crucial y debe hacer.

Ha publicado algunos detalles, pero intentémoslo.

La regla es: intente y encuentre el conjunto de trabajo más común. Ve si encaja en la RAM. Optimice el hardware, la configuración del búfer PG/OS y los índices PG/clústeres para él. De lo contrario, busque agregados, o si no es aceptable y necesita acceso completamente aleatorio, piense qué hardware podría escanear toda la tabla en un tiempo razonable.

¿Qué tan grande es su tabla (en gigabytes)? ¿Cómo se compara con la RAM total? ¿Cuáles son sus configuraciones de PG, incluidas shared_buffers y effective_cache_size? ¿Es este un servidor dedicado? Si tiene una mesa de 250 gigas y unos 10 GB de RAM, significa que solo puede caber el 4% de la mesa.

¿Hay alguna columna que se use comúnmente para filtrar, como el estado o la fecha? ¿Puede el conjunto de trabajo que se usa más comúnmente (como solo el mes pasado)? Si es así, considere particionar o agrupar en estas columnas, y definitivamente indexarlas. Básicamente, estás tratando de asegurarte de que la mayor cantidad de trabajo posible se ajuste a la RAM.

Evite escanear la tabla a toda costa si no cabe en la memoria RAM. Si realmente necesita acceso absolutamente aleatorio, la única forma en que podría ser utilizable es hardware realmente sofisticado. Necesitará una configuración de almacenamiento/RAM persistente que pueda leer 250 GB en un tiempo razonable.

Cuestiones relacionadas