Prácticas recomendadas para diseñar un esquema de grafo de Spanner

Vista previa — Spanner Graph

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Nota: Esta función está disponible en las ediciones Enterprise y Enterprise Plus de Spanner. Para obtener más información, consulta la descripción general de las ediciones de Spanner.

En este documento, se describe cómo crear consultas eficientes con las prácticas recomendadas para diseñar esquemas de gráficos de Spanner. El diseño de esquemas puede ser iterativo, por lo que te recomendamos que primero identifiques los patrones de consulta fundamentales para guiar tu diseño de esquemas.

Para obtener información general sobre las prácticas recomendadas de diseño de esquemas de Spanner, consulta Prácticas recomendadas para el diseño de esquemas.

Optimiza el recorrido de los bordes

El recorrido de aristas es el proceso de navegar por un grafo siguiendo sus aristas, comenzando en un nodo en particular y moviéndose a lo largo de aristas conectadas para llegar a otros nodos. El recorrido perimetral es una operación fundamental en el grafo de Spanner, por lo que Mejorar la eficiencia del recorrido perimetral es clave para el rendimiento de tu aplicación.

Se puede atravesar una arista en dos direcciones: al pasar del nodo fuente a el nodo de destino se denomina recorrido perimetral de avance, mientras se desplaza desde que el nodo de destino al nodo fuente se denomina reverso del borde inverso.

Optimiza el recorrido de borde hacia adelante con intercalación

Para mejorar el rendimiento del recorrido de borde directo, intercala la tabla de entrada de borde en la tabla de entrada del nodo de origen para colocar bordes con los nodos fuente. La intercalación es una técnica de optimización de almacenamiento en Spanner coloca físicamente las filas de la tabla secundaria con sus filas superiores correspondientes en y almacenamiento de los datos. Para obtener más información sobre la intercalación, consulta Descripción general de los esquemas.

En el siguiente ejemplo, se muestran estas prácticas recomendadas:

CREATE TABLE Person (
  id               INT64 NOT NULL,
  name             STRING(MAX),
) PRIMARY KEY (id);

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

Optimizar el recorrido perimetral inverso con clave externa

Para atravesar aristas inversas de manera eficiente, crea una restricción de clave externa entre entre el perímetro y el nodo de destino. Esta clave externa crea automáticamente un índice secundario en el perímetro con la clave de las claves del nodo de destino. El índice secundario se usa automáticamente durante la ejecución de la consulta.

En el siguiente ejemplo, se muestran estas prácticas recomendadas:

CREATE TABLE Person (
  id               INT64 NOT NULL,
  name             STRING(MAX),
) PRIMARY KEY (id);

CREATE TABLE Account (
  id               INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (id);

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id),
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

Optimiza el recorrido de aristas inverso con el índice secundario

Si no quieres crear una clave externa en el perímetro, por ejemplo, debido a la con la integridad de datos estricta que exige, puedes crear la tabla de entrada perimetral, como se muestra en el siguiente ejemplo:

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE INDEX Reverse_PersonOwnAccount
ON PersonOwnAccount (account_id);

No permitir bordes colgantes

Un borde colgante es un perímetro que conecta menos de dos nodos. Una prenda colgante perímetro puede ocurrir cuando se borra un nodo sin quitar sus bordes asociados. cuando se crea una arista sin vincularla correctamente a sus nodos.

La inhabilitación de los bordes colgantes proporciona los siguientes beneficios:

• Aplica la integridad de la estructura del grafo.
• Mejora el rendimiento de las consultas, ya que evita el trabajo adicional de filtrar los bordes donde no existen extremos.

No permitas bordes colgantes con restricciones referenciales

Para no permitir los bordes colgantes, especifica restricciones en ambos extremos:

• Intercala la tabla de entrada de borde en la tabla de entrada del nodo de origen. Esta garantiza que el nodo de origen de un perímetro siempre exista.
• Crea una restricción de clave externa en las aristas para garantizar que el nodo de destino de una arista.

En el siguiente ejemplo, se usa la intercalación y una clave externa para aplicar la integridad referencial:

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id) ON DELETE CASCADE,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

Usa ON DELETE CASCADE para quitar automáticamente los bordes cuando se borre un nodo

Cuando uses la intercalación o una clave externa para no permitir los bordes colgantes, usa el ON DELETE para controlar el comportamiento cuando deseas borrar un nodo con que todavía están unidos. Para obtener más información, consulta cómo borrar de forma intercalada tablas intercaladas y cómo borrar de forma intercalada con claves foráneas.

Puedes usar ON DELETE de las siguientes maneras:

• ON DELETE NO ACTION (o bien omitir la cláusula ON DELETE): Borrar una de los nodos con perímetros fallarán.
• ON DELETE CASCADE: Si borras un nodo, se quitan automáticamente los bordes asociados en la misma transacción.

Eliminación en cascada de aristas que conectan diferentes tipos de nodos

• Borra los bordes cuando se borra el nodo de origen. Por ejemplo,INTERLEAVE IN PARENT Person ON DELETE CASCADE borra todas las llamadas salientes. Se borrarán PersonOwnAccount bordes del nodo Person. Para ver más información, consulta Crea tablas intercaladas.

• Borra las aristas cuando se borre el nodo de destino. Por ejemplo: CONSTRAINT FK_Account FOREIGN KEY(account_id) REFERENCES Account(id) ON DELETE CASCADE borra todos los bordes PersonOwnAccount entrantes. al nodo Account que se borrará. Para obtener más información, consulta Claves externas.

Borrar cascada para las aristas que conectan el mismo tipo de nodos

Cuando los nodos de origen y destino de un perímetro tienen el mismo tipo y la borde está intercalado en el nodo de origen, puedes definir ON DELETE CASCADE solo para el nodo de origen o de destino (pero no para ambos nodos).

Para quitar automáticamente los bordes colgantes en ambos casos, crea una clave externa en la referencia del nodo de origen del borde en lugar de intercalar la tabla de entrada del borde en la tabla de entrada del nodo de origen.

Recomendamos intercalar para Optimiza el recorrido del borde avanzado. Asegúrate de verificar el impacto en tus cargas de trabajo antes de continuar. Consulta la siguiente ejemplo, que usa AccountTransferAccount como entrada perimetral tabla:

--Define two Foreign Keys, each on one end Node of Transfer Edge, both with ON DELETE CASCADE action:
CREATE TABLE AccountTransferAccount (
  id               INT64 NOT NULL,
  to_id            INT64 NOT NULL,
  amount           FLOAT64,
  create_time      TIMESTAMP NOT NULL,
  order_number     STRING(MAX),
  CONSTRAINT FK_FromAccount FOREIGN KEY (id) REFERENCES Account (id) ON DELETE CASCADE,
  CONSTRAINT FK_ToAccount FOREIGN KEY (to_id) REFERENCES Account (id) ON DELETE CASCADE,
) PRIMARY KEY (id, to_id);

Cómo filtrar por propiedades de nodos o aristas con índices secundarios

Los índices secundarios son esenciales para un procesamiento eficiente de consultas. Admiten búsquedas rápidas de nodos y aristas en función de valores de propiedades específicos, sin tener que recorrer toda la estructura del gráfico. Esto es importante cuando trabajas con gráficos grandes, ya que recorrer todos los nodos y las aristas puede ser muy ineficiente.

Acelera el filtrado de nodos por propiedad

Para acelerar el filtrado por propiedades de nodos, crea índices secundarios en las propiedades. Por ejemplo, la siguiente consulta encuentra cuentas para un sobrenombre determinado. Sin un índice secundario, se analizan todos los nodos de Account para que coincidan los criterios de filtrado.

GRAPH FinGraph
MATCH (acct:Account)
WHERE acct.nick_name = "abcd"
RETURN acct.id;

Para acelerar la consulta, crea un índice secundario en la propiedad filtrada, como como se muestra en el siguiente ejemplo:

CREATE TABLE Account (
  id               INT64 NOT NULL,
  create_time      TIMESTAMP,
  is_blocked       BOOL,
  nick_name        STRING(MAX),
) PRIMARY KEY (id);

CREATE INDEX AccountByEmail
ON Account (nick_name);

Sugerencia: Usa índices filtrados por NULL para las propiedades dispersas. Para obtener más información, consulta Cómo inhabilitar la indexación de valores NULL.

Acelera el recorrido de borde hacia adelante con el filtrado de propiedades de borde

Cuando recorres un borde mientras filtras sus propiedades, puedes acelerar la consulta si creas un índice secundario en las propiedades del borde y entremezclas el índice en el nodo de origen.

Por ejemplo, la siguiente consulta encuentra las cuentas que pertenecen a una persona determinada después de un período determinado:

GRAPH FinGraph
MATCH (person:Person)-[owns:Owns]->(acct:Account)
WHERE person.id = 1
  AND owns.create_time >= PARSE_TIMESTAMP("%c", "Thu Dec 25 07:30:00 2008")
RETURN acct.id;

De forma predeterminada, esta consulta lee todos los bordes de la persona especificada y, luego, filtra. las aristas que satisfacen la condición de create_time

En el siguiente ejemplo, se muestra cómo mejorar la eficiencia de las consultas mediante la creación de un índice secundario en la referencia del nodo de fuente de borde (id) y la propiedad de borde (create_time). Intercala el índice debajo de la tabla de entrada del nodo de origen para ubicarlo junto con el nodo de origen.

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE INDEX PersonOwnAccountByCreateTime
ON PersonOwnAccount (id, create_time)
INTERLEAVE IN Person;

Con este enfoque, la consulta puede encontrar de manera eficiente todas las aristas que satisfacen el estado en create_time.

Acelera el recorrido del borde inverso con el filtrado de las propiedades de las aristas

Cuando recorres un borde inverso mientras filtras sus propiedades, puedes acelerar la consulta creando un índice secundario con el nodo de destino y las propiedades del borde para filtrar.

La siguiente consulta de ejemplo realiza un recorrido de arista inversa con el filtrado activado Propiedades de borde:

GRAPH FinGraph
MATCH (acct:Account)<-[owns:Owns]-(person:Person)
WHERE acct.id = 1
  AND owns.create_time >= PARSE_TIMESTAMP("%c", "Thu Dec 25 07:30:00 2008") 
RETURN person.id;

Para acelerar esta consulta con un índice secundario, usa una de las siguientes opciones:

• Crea un índice secundario en la referencia de nodo de destino perimetral (account_id) y la propiedad de borde (create_time), como se muestra en siguiente ejemplo:

  CREATE TABLE PersonOwnAccount (
    id               INT64 NOT NULL,
    account_id       INT64 NOT NULL,
    create_time      TIMESTAMP,
  ) PRIMARY KEY (id, account_id),
    INTERLEAVE IN PARENT Person ON DELETE CASCADE;
  
  CREATE INDEX PersonOwnAccountByCreateTime
  ON PersonOwnAccount (account_id, create_time);
  

  Este enfoque proporciona un mejor rendimiento porque las aristas inversas son ordenadas por account_id y create_time, lo que permite que el motor de consultas encontrar de manera eficiente aristas para account_id que satisfaga la condición de create_time Sin embargo, si diferentes patrones de consulta filtran en diferentes propiedades, cada propiedad podría requerir un índice independiente, lo que puede generar sobrecarga.

• Crea un índice secundario en la referencia del nodo de destino de la red perimetral (account_id) y almacena la propiedad de la red perimetral (create_time) en una columna de almacenamiento, como se muestra en el siguiente ejemplo:

  CREATE TABLE PersonOwnAccount (
    id               INT64 NOT NULL,
    account_id       INT64 NOT NULL,
    create_time      TIMESTAMP,
  ) PRIMARY KEY (id, account_id),
    INTERLEAVE IN PARENT Person ON DELETE CASCADE;
  
  CREATE INDEX PersonOwnAccountByCreateTime
  ON PersonOwnAccount (account_id) STORING (create_time);
  

  Con este enfoque, se pueden almacenar varias propiedades: Sin embargo, la consulta debe leer todos los perímetros del nodo de destino y, luego, filtrar según las propiedades perimetrales.

Puedes combinar estos enfoques siguiendo estos lineamientos:

• Usa propiedades de borde en las columnas de índice si se usan en consultas críticas para el rendimiento.
• Agrega las propiedades que se usan en consultas menos sensibles al rendimiento en las columnas de almacenamiento.

Modela tipos de nodos y aristas con etiquetas y propiedades

Los tipos de nodos y aristas suelen modelarse con etiquetas. Sin embargo, también puedes usar propiedades a los tipos de modelos. Considera un ejemplo en el que hay muchos tipos de cuentas diferentes, como BankAccount, InvestmentAccount y RetirementAccount. Puedes almacenar las cuentas en tablas de entrada separadas y modelarlas como etiquetas independientes o almacenar las cuentas en una sola y usar una propiedad para diferenciar entre los tipos.

Para comenzar el proceso de modelado, modela los tipos con etiquetas. Considera usar propiedades en las siguientes situaciones.

Mejora la administración de esquemas

Si tu grafo tiene muchos tipos de nodos y aristas diferentes, administrar una entrada independiente tabla para cada uno puede volverse difícil. Para facilitar la administración del esquema, modela el tipo como una propiedad.

Tipos de modelos en una propiedad para administrar tipos que cambian con frecuencia

Cuando modelas tipos como etiquetas, agregar o quitar tipos requiere cambios en el esquema. Si actualizas el esquema en un período breve, Spanner podría throttle el procesamiento de actualizaciones de esquema en cola. Para obtener más información, consulta Limita la frecuencia de las actualizaciones de esquemas.

Si necesitas cambiar el esquema con frecuencia, te recomendamos modelar el escribe una propiedad para evitar limitaciones en la frecuencia del esquema actualizaciones.

Acelera las consultas

Los tipos de modelado con propiedades pueden acelerar las consultas cuando el nodo o el patrón perimetral hace referencia a varias etiquetas. La siguiente consulta de ejemplo busca todas las instancias de SavingsAccount y InvestmentAccount son propiedad de Person, suponiendo que se trata de una cuenta tipos se modelan con etiquetas:

GRAPH FinGraph
MATCH (:Person {id: 1})-[:Owns]->(acct:SavingsAccount|InvestmentAccount)
RETURN acct.id;

El patrón de nodo acct hace referencia a dos etiquetas. Si esta es una consulta crítica para el rendimiento, considera modelar Account con una propiedad. Esta puede proporcionar un mejor rendimiento de las consultas, como se muestra en la siguiente consulta ejemplo. Te recomendamos que compares ambas consultas.

GRAPH FinGraph
MATCH (:Person {id: 1})-[:Owns]->(acct:Account)
WHERE acct.type IN ("Savings", "Investment")
RETURN acct.id;

Almacena el tipo en la clave del elemento del nodo para acelerar las consultas

Para acelerar las consultas con el filtrado del tipo de nodo cuando se modela un tipo de nodo con una propiedad y el tipo no cambia a lo largo de la vida útil del nodo, sigue estos pasos:

1. Incluye la propiedad como parte de la clave del elemento del nodo.
2. Agrega el tipo de nodo a la tabla de entrada perimetral.
3. Incluye el tipo de nodo en las claves de referencia de los bordes.

En el siguiente ejemplo, se aplica esta optimización al nodo Account y al Borde de AccountTransferAccount.

CREATE TABLE Account (
  type             STRING(MAX) NOT NULL,
  id               INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (type, id);

CREATE TABLE AccountTransferAccount (
  type             STRING(MAX) NOT NULL,
  id               INT64 NOT NULL,
  to_type          STRING(MAX) NOT NULL,
  to_id            INT64 NOT NULL,
  amount           FLOAT64,
  create_time      TIMESTAMP NOT NULL,
  order_number     STRING(MAX),
) PRIMARY KEY (type, id, to_type, to_id),
  INTERLEAVE IN PARENT Account ON DELETE CASCADE;

CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    Account
  )
  EDGE TABLES (
    AccountTransferAccount
      SOURCE KEY (type, id) REFERENCES Account
      DESTINATION KEY (to_type, to_id) REFERENCES Account
  );

Configura el TTL en nodos y aristas

El tiempo de actividad (TTL) de Spanner es un mecanismo que admite el vencimiento y la eliminación automáticos de datos después de un período especificado. Esto suele usarse para datos que tienen una relevancia o un período de vida limitado, como la información de la sesión, las cachés temporales o los registros de eventos. En estos casos, el TTL ayuda a mantener el tamaño y el rendimiento de la base de datos.

En el siguiente ejemplo, se usa el TTL para borrar cuentas 90 días después de su cierre:

CREATE TABLE Account (
  id               INT64 NOT NULL,
  create_time      TIMESTAMP,
  close_time       TIMESTAMP,
) PRIMARY KEY (id),
  ROW DELETION POLICY (OLDER_THAN(close_time, INTERVAL 90 DAY));

Si la tabla de nodos tiene un TTL y una tabla de aristas intercaladas, el intercalado se debe definir con ON DELETE CASCADE. Del mismo modo, si la tabla de nodos tiene un TTL y una tabla de aristas hace referencia a ella a través de una clave externa, la clave externa se debe definir con ON DELETE CASCADE.

En el siguiente ejemplo, AccountTransferAccount se almacena por un máximo de diez años. mientras la cuenta permanece activa. Cuando se borra una cuenta, la transferencia también se borrará el historial.

CREATE TABLE AccountTransferAccount (
  id               INT64 NOT NULL,
  to_id            INT64 NOT NULL,
  amount           FLOAT64,
  create_time      TIMESTAMP NOT NULL,
  order_number     STRING(MAX),
) PRIMARY KEY (id, to_id),
  INTERLEAVE IN PARENT Account ON DELETE CASCADE,
  ROW DELETION POLICY (OLDER_THAN(create_time, INTERVAL 3650 DAY));

Combina tablas de entrada de nodos y bordes

Puedes usar la misma tabla de entrada para definir más de un nodo y borde en tu esquema.

En las siguientes tablas de ejemplo, los nodos Account tienen una clave compuesta (owner_id, account_id) Hay una definición de borde implícita, el nodo Person con la clave (id) es propietario del nodo Account con la clave compuesta (owner_id, account_id) cuando id es igual a owner_id.

CREATE TABLE Person (
  id INT64 NOT NULL,
) PRIMARY KEY (id);

-- Assume each account has exactly one owner.
CREATE TABLE Account (
  owner_id INT64 NOT NULL,   
  account_id INT64 NOT NULL,        
) PRIMARY KEY (owner_id, account_id);

En este caso, puedes usar la tabla de entrada Account para definir el Account y el borde PersonOwnAccount, como se muestra en el siguiente ejemplo de esquema. Para garantizar que todos los nombres de las tablas de elementos sean únicos, en el ejemplo se le da a la arista la definición de tabla del alias Owns.

CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    Person,
    Account
  )
  EDGE TABLES (
    Account AS Owns
      SOURCE KEY (owner_id) REFERENCES Person
      DESTINATION KEY (owner_id, account_id) REFERENCES Account
  );

¿Qué sigue?

• Crea, actualiza o descarta un esquema de grafo de Spanner.
• Insertar, actualizar o borrar datos del gráfico de Spanner.