2012-02-03 61 views
43

Estoy mirando DynamoDB de Amazon, ya que parece que le quita todas las molestias de mantener y escalar su servidor de base de datos. Actualmente estoy usando MySQL, y mantener y escalar la base de datos es un dolor de cabeza completo.¿Cómo consultas DynamoDB?

He revisado la documentación y estoy teniendo dificultades para entender cómo estructurar los datos para poder recuperarlos fácilmente.

Soy totalmente nuevo en NoSQL y bases de datos no relacionales.

Según la documentación de Dynamo, parece que solo puede consultar una tabla en la clave hash primaria y la clave de rango principal con un número limitado de operadores de comparación.

O puede ejecutar un escaneo completo de la tabla y aplicarle un filtro. El problema es que solo escaneará 1Mb a la vez, por lo que es probable que tenga que repetir el escaneo para encontrar una X cantidad de resultados.

Me doy cuenta de que estas limitaciones les permiten proporcionar un rendimiento predecible, pero parece que hace que sea realmente difícil sacar sus datos. Y la realización de escaneos de tabla completos parece como sería realmente ineficiente, y solo se volvería menos eficiente con el tiempo a medida que su tabla crezca.

Por ejemplo, supongo que tengo un clon de Flickr. Mi mesa Imágenes podría ser algo como:

  • ID de la imagen (Número, Hash clave principal)
  • Fecha Alta (número, Primary Key Range)
  • ID de usuario (String)
  • Etiquetas (String Set)
  • etc

Así, utilizando consulta sería capaz de enumerar todas las imágenes de los últimos 7 días y limitarlo a un número X de los resultados con bastante facilidad.

Pero si quisiera enumerar todas las imágenes de un usuario en particular, necesitaría hacer una exploración de tabla completa y filtrar por nombre de usuario. Lo mismo ocurriría con las etiquetas.

Y como solo puede escanear 1Mb a la vez, es posible que deba realizar varias exploraciones para encontrar una X cantidad de imágenes. Tampoco veo una forma de detenerse fácilmente en X cantidad de imágenes. Si intenta obtener 30 imágenes, su primer escaneo podría encontrar 5, y el segundo puede encontrar 40.

¿Tengo este derecho? ¿Es básicamente una compensación? Obtiene un rendimiento de base de datos predecible realmente rápido que prácticamente no requiere mantenimiento. ¿Pero la desventaja es que necesitas construir más lógica para lidiar con los resultados?

¿O estoy totalmente fuera de lugar aquí?

Respuesta

16

Sí, estás en lo correcto acerca de la equilibrio entre el rendimiento y la flexibilidad de consulta.

Pero hay algunos trucos para reducir el dolor, los índices secundarios/desnormalización probablemente sean los más importantes.

Tendría otra tabla introducida en la identificación del usuario, enumerando todas sus imágenes, por ejemplo. Cuando agrega una imagen, actualiza esta tabla y agrega una fila a la tabla introducida en la identificación de la imagen.

Debe decidir qué consultas necesita y luego diseñar el modelo de datos a su alrededor.

+0

Ok, eso tiene sentido. ¿Cómo harías algo como etiquetas? ¿La clave principal sería el nombre de la etiqueta y luego la clave de rango sería la identificación de la imagen? Supongo que la clave principal no puede ser un conjunto de cuerdas. – chriserwin

+0

Eso suena correcto, pero no estoy familiarizado con los detalles de DynamoDB; he trabajado con Cassandra en su lugar. – DNA

+0

Cuando consulto DynamoDB desde zend por primera vez, demora 3 segundos. y luego lleva menos de un segundo ejecutar otra consulta. ¿Cuál puede ser el motivo de esto? – keen

6

Creo que necesita crear su propio índice secundario, usando otra tabla.

Esta tabla "esquema" podrían ser:

User ID (String, Primary Key) 
    Date Added (Number, Range Key) 
    Image ID (Number) 

-

De esta manera se puede consultar por ID de usuario y filtrar por fecha, así

4

Puede usar clave de rango de compilación compuesta como índice principal.

Desde el DynamoDB Página:

Una clave primaria puede ser una clave hash de un solo atributo o una clave compuesta hash gama. Una clave principal de hash de atributo único podría ser, para el ejemplo , "ID de usuario". Esto le permitirá leer y escribir rápidamente los datos para un elemento asociado con una ID de usuario determinada.

Una clave de rango hash compuesta está indexada como un elemento clave hash y un elemento clave de rango . Esta clave de varias partes mantiene una jerarquía entre los valores del primer y segundo elemento. Por ejemplo, una clave compuesta de rangos hash podría ser una combinación de "UserID" (hash) y "Timestamp" (rango). Manteniendo constante el elemento de clave hash, puede buscar en todo el elemento clave de rango para recuperar elementos. Esto sería que le permite utilizar la API de consultas para, por ejemplo, recuperar todos los elementos para un único ID de usuario en un rango de marcas de tiempo.

Cuestiones relacionadas