¿Particionar o no particionar?

Después de haber leído varias preguntas sobre SO, publicaciones de blog externas y manual

• SO : restricción de clave externa para tabla particionada en Pg
• dba.SE : diferentes formas de manejar FK a la tabla particionada en Pg
• Manual : Herencia
• Manual : Particionamiento
• Manual : disparadores de restricción
• Blog : modelado de Postgres con herencia

Todavía me pregunto si debería seguir con la partición considerando mi caso o no.

El caso - simplificado

Almacenar datos del cliente. Todos los nombres de las tablas mencionadas a continuación están compuestos por claridad.

1. Tener objetos que son identificables por el cliente y que son seres no físicos, también sus objetos físicos en los que realmente se almacenan en caso de que necesiten enviar algunos objetos al cliente a pedido, o procesarlos de alguna otra manera. Están mapeados en una relación de muchos a muchos. objects_nonphysical, objects_physical, objects_mapping_table.

2. La segunda relación de muchos a muchos es entre esos objetos no físicos y sus métricas. Hay objetos que están vinculados con algunas métricas. metrics,metrics_objects_nonphysical

3. Tanto los objetos no físicos como los físicos tienen sus tablas de jerarquía que son relaciones padre-hijo. objects_nonphysical_hierarchy,objects_physical_hierarchy

Dependiendo de las necesidades y requisitos de cada cliente, los datos sobre objetos físicos pueden suministrarse o pueden necesitarse desde cero. Básicamente, lo que necesito hacer es:

• Mantenga un sistema interno rápido INSERTy SELECTenunciado, porque aquí es donde se realizará el mapeo.

• Mantenga el sistema para que el cliente externo pueda ver y operar en sus objetos no físicos : recuperación rápida de datos. Gran necesidad de eficiencia para las SELECTdeclaraciones: esta información está disponible para que muchos clientes la busquen cuando lo deseen.

Mi consideracion

Puede haber un cliente, que puede acceder a los datos, verlos y operar con ellos, pero no es necesario que sea un contratista del que obtuvimos los datos / para los que los procesamos.

Esto me ha llevado a introducir la partición de tablas en mi sistema, teniendo en cuenta que siempre sé en qué datos de partición deben caer ( particionamiento para contratistas ), y luego a un sistema principal para clientes externos donde necesito particiones para clientes (esto se haría con algunos Retrasar el uso de herramientas de automatización y un conjunto de reglas para reescribir los datos de manera de los clientes, de modo que para cada cliente solo escaneemos una partición para cada tabla.

Volumen de datos

Mis datos crecerán constantemente, especialmente al importar objetos y métricas de nuevos clientes. El ritmo de los nuevos datos que llegan al sistema es impredecible en este momento a largo plazo. Realmente no hay forma de medirlo sin saber quién será el próximo cliente. En este momento hay solo 2 clientes con más o menos filas de 1 millón para cada cliente en cada tabla. Pero en el futuro, predigo que nuevos clientes vendrán con un volumen de 10 millones de filas más o menos.

Preguntas

Estas preguntas están todas relacionadas entre sí.

1. ¿Debería considerarse realmente la partición aquí, o es una exageración? Considero que es útil ya que siempre estoy escaneando exactamente una partición.
2. Si la partición es el camino a seguir, ¿cómo hago cumplir la FKrestricción de la manera más efectiva teniendo en cuenta mis necesidades? ¿Debo ir constraint triggers, o simplemente mantenerlo en la capa de aplicación para el sistema interno, o tal vez algún otro método?
3. Si la partición no es el camino a seguir, ¿en qué debería sumergirme?

Si no se proporcionan suficientes datos, hágamelo saber en los comentarios a continuación.

Hay muchos extremos abiertos en su pregunta, pero la partición por cliente podría ser el camino a seguir, especialmente si:

• esperas muchos clientes,
• cada uno de ellos podría tener toneladas de datos ("toneladas" significa mucho más que el tamaño de caché de RAM),
• La mayoría de sus conjuntos de datos serán mutuamente excluyentes (cada cliente ve un subconjunto de datos diferente).

Las REGLAS o los desencadenantes son una sobrecarga de rendimiento y se pueden evitar.

Considere algo en este sentido:

BEGIN;

CREATE USER tenant1;
CREATE USER tenant2;

CREATE SCHEMA app;
CREATE SCHEMA tenant1;
CREATE SCHEMA tenant2;

CREATE TABLE app.objects_nonphysical(id int);
CREATE TABLE app.objects_physical(id int);
CREATE TABLE app.objects_mapping(id int);    
CREATE TABLE tenant1.objects_nonphysical() INHERITS(app.objects_nonphysical);
CREATE TABLE tenant1.objects_physical() INHERITS(app.objects_physical);
CREATE TABLE tenant1.objects_mapping() INHERITS(app.objects_mapping);
CREATE TABLE tenant2.objects_nonphysical() INHERITS(app.objects_nonphysical);
CREATE TABLE tenant2.objects_physical() INHERITS(app.objects_physical);
CREATE TABLE tenant2.objects_mapping() INHERITS(app.objects_mapping);

GRANT USAGE ON SCHEMA tenant1 TO tenant1;
GRANT USAGE ON SCHEMA tenant2 TO tenant2;
GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA tenant1 TO tenant1;
GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA tenant2 TO tenant2;

/* TEST: simulate login as customer */
SET SESSION AUTHORIZATION tenant2;
/* No schema needed - default search_path works */
SELECT count(*) FROM objects_nonphysical; 

ROLLBACK;

No necesita ningún activador / regla para mantenerlo.

Aquí hay extremos abiertos, eso es solo un borrador ... Algunos problemas:

• PK, FK e índices no son "heredados".
• incluso si los crea, la PK no se aplica en la tabla maestra
• puede superar esto utilizando la misma secuencia para todos los inquilinos
• obviamente, la aplicación debe ajustarse para este modelo

No afectará si implementa la partición ahora, pero use una sola partición hasta que su sistema realmente requiera una nueva. En cuanto al rendimiento, solo habrá una pequeña sobrecarga, para lidiar con las claves principales y demás.

Recomiendo el uso de reglas para redireccionar inserciones y una tabla externa para las claves principales (por ejemplo CREATE TABLE objects_physical_ids (id bigserial NOT NULL PRIMARY KEY), junto con un activador de función que inserta una fila en la tabla de identificadores y la copia a NEW.id (por ejemplo INSERT INTO objects_physical_ids DEFAULT VALUES RETURNING id INTO NEW.id;), y otros activadores que se ocupan de la eliminación y actualizaciones, y un activador que ejecuta esos activadores de funciones para cada tabla heredada (¡no olvide hacer esto cuando cree una nueva tabla heredada!). Luego, todas las tablas relacionadas pueden tener una FOREIGN KEYtabla de identificadores relevantes (incluidas las acciones de teclas externas como ON UPDATEo ON DELETE)