Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Modelo de conjunto para gráficos de propiedades etiquetadas
Existen tres enfoques diferentes del modelo de piscina para LPGs Amazon Neptune:
+ **Estrategia de propiedades**: elija la estrategia de propiedades cuando necesite priorizar el uso de componentes de biblioteca establecidos, como el lenguaje Apache TinkerPop Gremlin, por encima del rendimiento. [PartitionStrategy](https://tinkerpop.apache.org/docs/current/reference/#partitionstrategy)
+ Estrategia de etiquetas de **prefijo: recomendamos la estrategia de etiquetas** de prefijo para la mayoría de los escenarios, en función del rendimiento y la limitación de los efectos de proximidad ruidosa.
+ Estrategia **de etiquetas múltiples: la estrategia de etiquetas múltiples** tiene el rendimiento mejorado de la estrategia de etiquetas de prefijo. También permite ejecutar consultas que abarquen a todos los inquilinos de un clúster (por ejemplo, consultas ISV para generar informes o supervisar a todos los inquilinos).
## Estrategia inmobiliaria
Con ella LPGs, los usuarios pueden añadir propiedades de pares clave-valor a los nodos, vértices y aristas. *Para lograr una separación lógica, la mayoría de los clientes la modelan intuitivamente como una propiedad única en cada nodo y periferia con una clave de propiedad arrendataria común.* La clave de propiedad del inquilino representa a todos los inquilinos propietarios del nodo. El *identificador del inquilino* es un valor único que identifica a un inquilino individual.
El siguiente diagrama muestra este modelo. Los dos subgrafos desconectados tienen varios nodos y aristas etiquetados, con la clave de propiedad del inquilino representada por`TId`. Cada nodo y borde de un subgrafo tiene un `TId` valor de. `1` En el otro subgrafo, cada nodo y borde tiene un `TId` valor de. `2`
En los gráficos de propiedades etiquetadas, hay dos formas de gestionar esto. El lenguaje de consultas Gremlin ofrece la biblioteca [PartitionStrategy](https://tinkerpop.apache.org/docs/current/reference/#partitionstrategy)transversal para ayudar a gestionar el particionamiento de los datos. El código del siguiente ejemplo espera que cada nodo y borde tenga una propiedad llamada: `TId`
```
strategy1 = new PartitionStrategy(partitionKey: "TId", writePartition: "1", readPartitions: ["1"])
strategy2 = new PartitionStrategy(partitionKey: "TId", writePartition: "2", readPartitions: ["2"])
```
Cuando se escriben nuevos nodos o aristas, la propiedad `"TId"` se añade con un valor de `"1"` o`"2"`, en función de si `strategy2` se ha seleccionado `strategy1` o no. Para el cliente con `"TId"` o`"1"`, usa`strategy1`. En el siguiente ejemplo, se muestran los datos de escritura para ese cliente:
```
g.withStrategies(strategy1).addV("Label1").property("Value", "123456").property(id, "Item_1")
```
En el caso de las consultas de lectura, `"TId == '2'"` se añade `"TId == '1'"` o se añade un filtro para cada recorrido de nodo o borde mediante `strategy1` o`strategy2`, respectivamente. Estas estrategias de partición simplifican el código, pero no son necesarias. La ventaja de usar la estrategia es que se puede inyectar en un nivel de autorización y pasarla al código de nivel inferior que forma la consulta. Esto separa el código que determina el identificador del cliente (`TId`) de la lógica de la consulta.
El siguiente código de ejemplo muestra una consulta de Gremlin para leer datos:
```
g.withStrategies(strategy1).V().hasLabel("Label1")
```
El código anterior equivale al siguiente ejemplo:
```
g.V().hasLabel("Label1").has("TId", "1")
```
Del mismo modo, al escribir datos mediante Gremlin, puede utilizar la siguiente consulta:
```
g.withStrategies(strategy1).addV("Label1").property("Value").property(id, "Item_1")
```
El código anterior equivale al ejemplo siguiente, que no utiliza la estrategia de partición y, por lo tanto, requiere que la `"TId"` propiedad se escriba de forma explícita:
```
g.addV("Label1").property("TId", "1").property("Value").property(id, "Item_1")
```
En OpenCypher, estas bibliotecas no existen. Usted es responsable de escribir y modificar las consultas para añadir el identificador del inquilino como una propiedad en los nodos y los bordes. Por ejemplo:
```
CREATE (n:Item {`~id`: 'Item_1', Value: '123456', TId: '1'})
CREATE (n:Item {`~id`: 'Item_2', Value: '123456', TId: '2'})
```
Tenga en cuenta la similitud entre el código de Gremlin sin la estrategia de partición. A continuación, puede leer el nodo escrito a partir de la primera `CREATE` sentencia utilizando el siguiente código:
```
MATCH (n:Item {TId: '1'})
RETURN n
--or
MATCH (n:Item)
WHERE n.TId == '1'
RETURN n
```
Puede elegir la estrategia inmobiliaria cuando desee utilizar construcciones nativas de TinkerPop Gremlin, como. PartitionStrategy Sin embargo, este modelo presenta inconvenientes de rendimiento en Amazon Neptune en comparación con la estrategia de etiquetas de prefijo. Para obtener información sobre estos inconvenientes de rendimiento, consulte la sección [Implicaciones en el rendimiento de los modelos a GLP](#perf).
Si se cumplen las siguientes condiciones, considere la posibilidad de modelar la estrategia de propiedades solo en los nodos, no en los bordes:
+ El gráfico tiene muchos más bordes que etiquetas.
+ Cada inquilino es un gráfico desconectado.
+ Para acceder al gráfico, solo se utilizan nodos como punto de partida, no etiquetas.
## Estrategia de etiquetas con prefijo
Si el rendimiento es una de las principales preocupaciones, te recomendamos encarecidamente que consideres la estrategia de etiquetas con prefijos en lugar de la estrategia de propiedades.
En la estrategia de etiquetas de prefijo, se etiqueta cada nodo con una combinación de identificador de inquilino y etiqueta de nodo. Por ejemplo, si el inquilino tiene un identificador de `"1"` y la etiqueta del nodo es`"Label1"`, especifique la etiqueta del nodo como. `"1-Label1"` El siguiente diagrama muestra dos subgráficos desconectados que utilizan este modelo.
Al escribir datos en Gremlin, puedes añadir un número de identificación a la etiqueta de cualquier nodo:
```
g.addV("1-Label1")
g.addV("2-Label6")
```
Al consultar este gráfico, puedes comprobar la existencia de este prefijo en un nodo:
```
g.V().hasLabel("1-Label1")
```
En OpenCypher puedes escribir datos usando una sentencia: `CREATE`
```
CREATE (n:`1-Label1` {`~id`: 'Item_1', Value: 'XYZ123456'})
```
Para consultar los datos que escribió en OpenCypher, utilice el siguiente código:
```
MATCH n= (:`1-Label1`)
RETURN n
```
La estrategia de etiquetas de prefijo supone que todos los nodos están asignados a uno o más inquilinos y que los permisos no se asignan en el ámbito perimetral. Evite utilizar esta estrategia en las etiquetas de borde, ya que provocará una gran cantidad de predicados y tendrá un impacto negativo en el rendimiento de Neptune.
El enfoque de las etiquetas de prefijo presenta dos inconvenientes principales. En primer lugar, es difícil ejecutar consultas que abarquen a todos los inquilinos. Un ejemplo es una consulta que cuenta todos los nodos de una etiqueta determinada para la generación de informes o la supervisión. Si este es su caso de uso, considere la posibilidad de combinar esta estrategia con la estrategia de etiquetas múltiples. Para obtener más información sobre la combinación de estrategias, consulte la sección sobre [modelos híbridos](hybrid-model.md).
En segundo lugar, la estrategia de etiquetas de prefijo requiere controles que impongan la aplicación adecuada del prefijo adecuado en cada consulta para evitar la filtración de datos. Sin embargo, esta estrategia es la opción más eficaz para las cargas de trabajo que requieren consultas de baja latencia, y la recomendamos encarecidamente. La sección [Implicaciones en el rendimiento de los modelos de GLP](#perf) proporciona ejemplos de por qué esta es la estrategia más eficiente.
## Estrategia de etiquetas múltiples
La tercera opción es utilizar una estrategia de etiquetas múltiples. Para este enfoque, se añaden etiquetas adicionales a cada nodo del gráfico. Por ejemplo, si necesita filtrar todos los datos de un arrendatario determinado, añada la etiqueta de identificador del arrendatario. Si necesitas filtrar todos los datos de una etiqueta determinada, independientemente del inquilino, añade esa etiqueta. El siguiente diagrama muestra la estrategia de etiquetas múltiples aplicada mediante el uso de tres etiquetas para cada nodo.
Ahora puede acceder al gráfico mediante tres patrones diferentes:
+ Filtre para obtener todos `Label1` los nodos con todos los inquilinos. `Label1`
+ Active el filtro `1` para obtener todos los nodos del inquilino 1.
+ Active el filtro `1-Label1` para mostrar todos los nodos solo para el inquilino 1 con la etiqueta`Label1`.
Pues LPGs, hay dos formas de implementar esto.
En Gremlin, puedes usar la estrategia transversal llamada [SubgraphStrategy](https://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.html)para limitar el alcance de todas las consultas solo a los vértices con una etiqueta específica, como: `"Label1"`
```
g.withStrategies(
new SubgraphStrategy(
vertices=hasLabel("Label1")
)
)
```
Por el contrario PartitionStrategy, SubgraphStrategy afecta solo a la lectura de los datos, no a la escritura de los datos. Para escribir los datos, asigne manualmente las etiquetas en cada consulta:
```
g.addV("Label1").property("Value","XYZ123456")
.addV("Label2").property("Value","XYZ123456")
```
Al leer los datos, puedes utilizarlos SubgraphStrategy para consultar todos los nodos con`"Label1"`:
```
g.withStrategies(
new SubgraphStrategy(vertices=.hasLabel("Label1"))
).
V().has("Value","XYZ123456")
```
Neptune devuelve solo el primer registro, que tiene `"Label1"` un valor de. `"XYZ123456"` Es equivalente a la siguiente consulta, que no utiliza SubgraphStrategy:
```
g.V().hasLabel("Label1").hasValue("XYZ123456")
```
En esta consulta básica, parece que SubgraphStrategy es más compleja de usar. Tenga en cuenta que sus bibliotecas pueden proporcionar una instancia `g` con la estrategia ya definida. Los desarrolladores no tienen que asegurarse de aplicar los filtros adecuados:
```
def getGraphTraversal():
return g.withStrategies(new SubgraphStrategy(vertices=.hasLabel("Label1"))
getGraphTraversal().has("Value","XYZ123456")
```
Las bibliotecas OpenCypher no tienen estas construcciones, por lo que debes crear varias etiquetas para cada nodo:
```
CREATE (n:`1`:`Label1`:`1-Label1` {`~id`: 'Item_1', Value: '12345'})
```
Al utilizar estas etiquetas para filtrar un subgrafo, puede devolver los nodos que tienen la etiqueta de cliente que busca o que comparten una relación con otro nodo que tiene esa etiqueta:
```
MATCH n=(:Label1:`1`)
// or
MATCH n=(:`1-Label1`)
```
La estrategia de etiquetas múltiples le brinda la mayor flexibilidad para consultar los nodos por tipo (`Label1`) o inquilino (`1`), o para usar la estrategia de etiquetas de prefijo, que es más eficiente, cuando el rendimiento es lo más importante (). `1-Label1`
El principal inconveniente de esta estrategia es que cada etiqueta es un objeto adicional almacenado en el gráfico. Un objeto es un nodo, una arista o una propiedad de un nodo o borde interno LPGs. La velocidad de ingesta se mide y se limita a objetos por segundo, y los costes de almacenamiento dependen de la cantidad de gigabytes consumidos. Esto significa que los objetos adicionales pueden tener un impacto medible a gran escala.
## Implicaciones de rendimiento para los modelos de GLP
El curso [Data Modeling for Amazon Neptune](https://explore.skillbuilder.aws/learn/course/external/view/elearning/16133/data-modeling-for-amazon-neptune), de AWS Skill Builder, describe en profundidad los aspectos internos del modelo de datos de Neptuno y las implicaciones del modelado, pero aquí resumiremos las consideraciones importantes para estos diseños. Considere la posibilidad de tener tres inquilinos (T1, T2, T3) en un solo cúmulo de Neptune. Estos inquilinos tienen los siguientes atributos:
+ El arrendatario 1 (T1) tiene un total de 100 millones de nodos y 10 millones son del tipo Item.
+ El arrendatario 2 (T2) tiene un total de 10 millones de nodos y 1 millón son del tipo Item.
+ El arrendatario 3 (T3) tiene un total de 100 millones de nodos y 1 millón son del tipo Item.
Ejecute una consulta que recupere los elementos del inquilino 3 utilizando la estrategia de propiedades. Neptune inspecciona las estadísticas de dos llamadas a índices:
+ ¿Dónde `tenant property key=T3` tiene 100 millones de resultados?
+ ¿Dónde `label = Item` tiene 12 millones de resultados (10 millones de la T1 \+ 1 millón de la T2 \+ 1 millón de la T3)
El optimizador de consultas de Neptune determina que es mejor aplicar primero la última consulta (12 millones de resultados) y, a continuación, inspecciona cada elemento. `tenant property key=T3` Recupera 12 millones de elementos para encontrar el millón de resultados.
Observe el impacto de esta consulta en los vecinos ruidosos. Si tuviera 100 millones de nodos de Item por usuario, la primera consulta tendría 300 millones de resultados en lugar de 12 millones (esto está demasiado simplificado a efectos ilustrativos). El optimizador de Neptune puede haber aplicado un orden de operaciones diferente).
A continuación, considere la estrategia de etiquetas de prefijo. Haga una sola llamada de índice Where`label=T3-Item`, que devolverá 1 millón de resultados. Con esto se obtiene el mismo resultado que con la estrategia inmobiliaria, pero se recuperan 11 millones de registros menos. Además, ya no tiene problemas de vecinos ruidosos porque la etiqueta no se superpone en el índice.
La estrategia de etiquetas múltiples no mejora directamente el rendimiento de las consultas en comparación con la estrategia de propiedades. Filtrar por valor de propiedad es comparable a filtrar por valor de etiqueta cuando el espacio de búsqueda también es comparable. En cambio, la estrategia de etiquetas múltiples permite una mayor flexibilidad. La estrategia de etiquetas múltiples proporciona un rendimiento equivalente al de la estrategia de etiquetas con prefijo para la etiqueta. `label=T3` `T3-Item` La estrategia de etiquetas múltiples proporciona un rendimiento equivalente al de la estrategia de propiedades para. `label=Item` La ventaja es que admite una variedad de patrones de acceso.