2012-02-18 19 views
5

Estoy planeando sobre el uso de la siguiente fórmula para calcular la "tendencia" mensajes:¿Cómo estructurar una base de datos DynamoDB para permitir consultas para publicaciones de tendencias?

Trending Score = (p - 1)/(t + 2)^1.5 

p = votos (puntos) de los usuarios. t = tiempo desde la presentación en horas.

Estoy buscando consejos sobre cómo estructurar las tablas de mi base de datos para que pueda consultar las publicaciones de tendencias con DynamoDB (un servicio de base de datos nosql de Amazon).

DynamoDB requiere una clave principal para cada elemento en una tabla. La clave principal puede constar de 2 partes: el atributo hash (cadena o número) y el atributo de rango (cadena o número). El atributo hash debe ser único para cada elemento y es obligatorio. El atributo de rango es opcional, pero si se usa, DynamoDB generará un índice de rango ordenado en el atributo de rango.

La estructura que tenía en mente es la siguiente:

TableName: Usuarios

HashAttribute: user_id 
RangeAttribute: NONE 
OtherFields: first_name, last_name 

NombreTabla: Mensajes

HashAttribute: post_id 
RangeAttribute: NONE 
OtherFields: user_id,title, content, points, categories[ ] 

NombreTabla: Categorías

HashAttribute: category_name 
RangeAttribute: post_id 
OtherFields: title, content, points 

TableName: Contadores

HashAttribute: counter_name 
RangeAttribute: NONE 
OtherFields: counter_value 

Así que aquí es un ejemplo de los tipos de solicitudes que haría con la siguiente configuración de la tabla (ejemplo: user_id = 100):

usuario Acción 1:

El usuario crea una nueva publicación y etiqueta la publicación para 2 categorías (béisbol, fútbol)

Query (1):

Comprobar valor actual para la counter_name = 'post_id' y el incremento + 1 y utilizar el nuevo post_id

Query (2): Introduce el siguiente en el tabla Mensajes:

post_id=value_from_query_1, user_id=100, title=user_generated, content=user_generated, points=0, categories=['baseball','soccer'] 

Query (3):

Inserte el siguiente en la tabla Categorías:

category_name='baseball', post_id=value_from_query_1, title=user_generated, content=user_generated, points=0 

Consulta (4):

Introduce el siguiente en la tabla Categorías:

category_name='soccer', post_id=value_from_query_1, title=user_generated, content=user_generated, points=0 



El objetivo final es para poder realizar los siguientes tipos de consultas:

1. Consulta de mensajes de tendencias

2. consulta para puestos en una determinada categoría

3. Consulta de mensajes con el punto más alto valora

¿Alguien tiene alguna idea de cómo podría estructurar mis tablas para poder hacer una consulta para las publicaciones de tendencias? ¿O es algo que le doy la posibilidad de hacer cambiando a DynamoDB?

+1

Es mejor ser específico acerca de la base de datos que está utilizando. Las diversas bases de datos "NoSQL" son muy diferentes. –

+0

¿Con qué frecuencia va a volver a calcular las publicaciones de tendencias? ¿Dónde está almacenando la marca de tiempo anterior? ¿Durante qué período de tiempo está dispuesto a superar la antigüedad de las publicaciones para ser elegible para tendencias? – Nick

+0

@Layble Estaba planeando usar el post_id como un contador incremental (por lo que ordenar el post_id en orden descendente mostraría las últimas publicaciones). La razón por la que estaba pensando en utilizar post_id frente a una marca de tiempo era para poder evitar la posibilidad de atributos de rango duplicados en la tabla de categorías (por ejemplo, si dos usuarios diferentes hacían una publicación sobre fútbol al mismo tiempo). Creo que me gustaría recalcular los mensajes de tendencias al menos cada minuto. –

Respuesta

1

Estoy comenzando con una nota sobre su comentario con la marca de tiempo vs post_id.
Dado que va a usar DynamoDB como su generador de post_id, hay un problema de escalabilidad allí mismo. Esos números son inherelables y es mejor utilizar un objeto de fecha. Si es necesario crear mensajes en un tiempo de velocidad de locura que puede empezar a leer acerca de cómo Twitter están haciendo http://blog.twitter.com/2010/announcing-snowflake

Ahora vamos a volver a su cheque de tendencias:
Creo que su escenario está haciendo mal uso DynamoDB.
Digamos que tiene una categoría HOT que tiene la mayoría de las publicaciones en ella. Básicamente, tendrá que escanear todas las publicaciones (ya que los datos no se distribuyen bien) y para cada inicio mirar los puntos y hacer las comparaciones en su servidor. Esto simplemente no funcionará o será muy costoso ya que cada vez probablemente usará toda su capacidad de unidades de lectura reservadas.

El enfoque DynamoDB para ese tipo de comprobación de las tendencias es el uso de MapReduce
Lea aquí cómo implementar los: http://aws.typepad.com/aws/2012/01/aws-howto-using-amazon-elastic-mapreduce-with-dynamodb.html

no puedo especificar un tiempo, pero creo que se encuentra este enfoque escalable - aunque no podrás usarlo a menudo.

En otra nota: puede mantener una lista de las "10/100" preguntas de moda y actualizarlas en "tiempo real" cuando se sube la publicación - obtiene la lista, verifique si es necesario para actualizarse con la pregunta recientemente actualizada y guardarla de nuevo en la base de datos si es necesario.

+0

http://engineering.twitter.com/2010/06/announcing-snowflake.html es inalcanzable. Vaya a https://blog.twitter.com/2010/announcing-snowflake – Kibria

Cuestiones relacionadas