

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.

# La caché de búsqueda de Neptune puede acelerar las consultas de lectura
<a name="feature-overview-lookup-cache"></a>

Amazon Neptune implementa una caché de búsqueda que utiliza el SSD NVMe basado en la `R5d` instancia para mejorar el rendimiento de lectura de las consultas con búsquedas frecuentes y repetitivas de valores de propiedades o literales RDF. La caché de búsqueda almacena temporalmente estos valores en el volumen de la NVMe SSD, donde se puede acceder a ellos rápidamente.

Las consultas de lectura que devuelven las propiedades de un gran número de vértices y bordes, o de muchos triples RDF, pueden tener una latencia alta si es necesario recuperar valores o literales de las propiedades de los volúmenes de almacenamiento del clúster y no de la memoria. Entre algunos ejemplos, se incluyen las consultas de lectura de larga duración que devuelven una gran cantidad de nombres completos de un gráfico de identidad o de direcciones IP de un gráfico de detección de fraudes. A medida que aumenta el número de valores de propiedades o literales RDF que devuelve la consulta, la memoria disponible disminuye y la ejecución de la consulta puede degradarse considerablemente.

# Casos de uso de la caché de búsqueda de Neptune
<a name="feature-overview-lookup-cache-when-to-use"></a>

La caché de búsqueda solo ayuda cuando las consultas de lectura devuelven las propiedades de un gran número de vértices y bordes o de triples RDF.

Para optimizar el rendimiento de las consultas, Amazon Neptune usa el tipo de instancia `R5d` para crear una caché grande para dichos valores de propiedad o literales. Por lo tanto, recuperarlos de la memoria caché es mucho más rápido que recuperarlos de los volúmenes de almacenamiento del clúster.

Como norma general, solo vale la pena habilitar la caché de búsqueda si se cumplen las tres condiciones siguientes:
+ Ha observado un aumento de la latencia en las consultas de lectura.
+ También observas una caída en la `BufferCacheHitRatio` [CloudWatch métrica](cw-metrics.md#cw-metrics-available) al ejecutar consultas de lectura (consulta[Monitorización de Neptune con Amazon CloudWatch](cloudwatch.md)).
+ Sus consultas de lectura dedican mucho tiempo a materializar los valores devueltos antes de representarlos (consulte el ejemplo del perfil de Gremlin que aparece a continuación para determinar cuántos valores de propiedades se están materializando para una consulta).

**nota**  
Esta característica *solo* es útil en el escenario específico descrito anteriormente. Por ejemplo, la caché de búsqueda no ayuda en absoluto en las consultas de agregación. A menos que esté ejecutando consultas que podrían beneficiarse de la caché de búsqueda, no hay ninguna razón para usar un tipo de instancia `R5d` en lugar de un tipo de instancia `R5` equivalente y menos costosa.

Si utiliza Gremlin, puede evaluar los costos de materialización de una consulta con [API `profile` de Gremlin](gremlin-profile-api.md). En la sección “Operaciones indexadas”, se muestra el número de términos que se materializaron durante la ejecución:

```
Index Operations
Query execution:
    # of statement index ops: 3
    # of unique statement index ops: 3
    Duplication ratio: 1.0
    # of terms materialized: 5273
Serialization:
    # of statement index ops: 200
    # of unique statement index ops: 140
    Duplication ratio: 1.43
    # of terms materialized: 32693
```

El número de términos no numéricos que se materializan es directamente proporcional al número de búsquedas de términos que Neptune debe realizar.

# Uso de la caché de búsqueda
<a name="feature-overview-lookup-cache-using"></a>

La caché de búsqueda solo está disponible en un tipo de instancia `R5d`, donde se habilita automáticamente de forma predeterminada. `R5d`Las instancias Neptune tienen las mismas especificaciones que las `R5` instancias, además de hasta 1,8 TB de almacenamiento SSD NVMe local. Las cachés de búsqueda son específicas de cada instancia y las cargas de trabajo que se benefician se pueden dirigir específicamente a las instancias `R5d` de un clúster de Neptune, mientras que otras cargas de trabajo se pueden dirigir a `R5` u otros tipos de instancias.

Para usar la caché de búsqueda en una instancia de Neptune, solo tiene que actualizar esa instancia al tipo de instancia `R5d`. Al hacerlo, Neptune establece automáticamente el parámetro del clúster de base de datos [neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache) en `1` (habilitado) y crea la caché de búsqueda en esa instancia concreta. A continuación, puede usar la API [Estado de la instancia](access-graph-status.md) para confirmar que la caché está habilitada.

Del mismo modo, para deshabilitar la caché de búsqueda en una instancia determinada, escale verticalmente la instancia de un tipo de instancia `R5d` a un tipo de instancia `R5` equivalente.

Cuando se lanza una instancia `R5d`, la caché de búsqueda se habilita en modo de arranque en frío, lo que significa que está vacía. Neptune comprueba primero en la caché de búsqueda los valores de las propiedades o los literales RDF mientras procesa las consultas y los añade si aún no están presentes. Esto calienta gradualmente la memoria caché.

Al dirigir las consultas de lectura que requieren búsquedas de valores de propiedad o literales RDF a una instancia de *lector* R5d, el rendimiento de lectura se reduce ligeramente mientras la caché se calienta. Sin embargo, cuando se calienta la memoria caché, el rendimiento de lectura se acelera considerablemente y, además, es posible que se reduzcan I/O los costes relacionados con las búsquedas realizadas en la memoria caché y no en el almacenamiento en clúster. La utilización de la memoria también mejora.

Si la instancia de *escritor* es `R5d`, calienta su caché de búsqueda automáticamente en cada operación de escritura. Este enfoque aumenta ligeramente la latencia de las consultas de escritura, pero calienta la caché de búsqueda de manera más eficiente. A continuación, si dirige las consultas de lectura que requieren búsquedas de valores de propiedades o literales RDF a la instancia del escritor, el rendimiento de lectura mejorará inmediatamente, ya que los valores ya se han almacenado en caché allí.

Además, si ejecuta el programa de carga masiva en una instancia de escritor `R5d`, es posible que note que su rendimiento se reduce ligeramente debido a la caché.

Como la caché de búsqueda es específica para cada nodo, la sustitución del host restablece la caché para que se inicie en frío.

Puede deshabilitar temporalmente la caché de búsqueda en todas las instancias del clúster de base de datos configurando el parámetro del clúster de base de datos [neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache) en `0` (deshabilitado). Sin embargo, en general, tiene más sentido deshabilitar la caché en instancias específicas reduciéndolas verticalmente del tipo de instancia `R5d` a `R5`.