Diseño de esquemas de redes sociales en DynamoDB

Caso de uso empresarial de redes sociales

En este caso de uso se habla del uso de DynamoDB como red social. Una red social es un servicio en línea que permite a diferentes usuarios interactuar entre sí. La red social que diseñaremos permitirá al usuario ver una cronología compuesta por las publicaciones, los seguidores, a quién sigue y las publicaciones escritas por las personas a las que sigue. Los patrones de acceso para este diseño de esquema son:

Diagrama de relaciones entre entidades de redes sociales

Este es el diagrama de relaciones entre entidades (ERD) que utilizaremos para el diseño del esquema de redes sociales.

Patrones de acceso de redes sociales

Estos son los patrones de acceso que consideraremos para el diseño del esquema de redes sociales.

Evolución del diseño de esquemas de redes sociales

DynamoDB es una base de datos NoSQL, por lo que no permite realizar una unión, una operación que combina datos de varias bases de datos. Es posible que los clientes que no estén familiarizados con DynamoDB apliquen filosofías de diseño del sistema de administración de bases de datos relacionales (RDBMS) (como crear una tabla para cada entidad) a DynamoDB cuando no lo necesiten. El propósito del diseño de tabla única de DynamoDB es escribir los datos en un formulario previamente unido de acuerdo con el patrón de acceso de la aplicación y, a continuación, utilizarlos inmediatamente sin cálculos adicionales. Para obtener más información, consulte Diseño de tabla única frente a múltiples tablas en DynamoDB.

Ahora, vamos a ver cómo evolucionaremos nuestro diseño de esquema para abordar todos los patrones de acceso.

Paso 1: Abordar el patrón de acceso 1 (getUserInfoByUserID)

Para obtener la información de un usuario determinado, necesitaremos realizar una operación Query en la tabla base con una condición clave de PK=<userID>. La operación de consulta le permite paginar los resultados, lo que puede ser útil cuando un usuario tiene muchos seguidores. Para obtener más información acerca de Query, consulte Consulta de tablas en DynamoDB.

En nuestro ejemplo, realizamos un seguimiento de dos tipos de datos para nuestro usuario: el “recuento” y la “información”. El “recuento” de un usuario refleja cuántos seguidores tiene, cuántos usuarios sigue y cuántas publicaciones ha creado. La “información” de un usuario refleja su información personal, como su nombre.

Vemos estos dos tipos de datos representados por los dos elementos siguientes. El elemento que tiene “recuento” en su clave de clasificación (SK) tiene más probabilidades de cambiar que el elemento con “información”. DynamoDB considera el tamaño del elemento tal como aparece antes y después de la actualización y el rendimiento aprovisionado consumido reflejará el mayor de estos tamaños de elemento. Aunque se actualice tan solo un subconjunto de atributos del elemento, UpdateItem consumirá la cantidad total de rendimiento provisionado (el mayor de los tamaños de elemento de "antes" y "después"). Puede obtener los elementos mediante una sola operación Query y usar UpdateItem para agregar o restar atributos numéricos existentes.

Paso 2: Abordar el patrón de acceso 2 (getFollowerListByUserID)

Para obtener una lista de los usuarios que siguen a un usuario determinado, necesitaremos Query la tabla base con una condición de clave de PK=<userID>#follower.

Paso 3: Abordar el patrón de acceso 3 (getFollowingListByUserID)

Para obtener una lista de los usuarios que sigue un usuario determinado, necesitaremos Query la tabla base con una condición de clave de PK=<userID>#following. A continuación, puede utilizar una operación TransactWriteItems para agrupar varias solicitudes y hacer lo siguiente:

Paso 4: Abordar el patrón de acceso 4 (getPostListByUserID)

Para obtener una lista de las publicaciones creadas por un usuario determinado, necesitaremos Query la tabla base con una condición de clave de PK=<userID>#post. Una cosa importante a tener en cuenta es que los ID de publicación de un usuario deben ser incrementales: el segundo valor del ID de publicación debe ser mayor que el primer valor del ID de publicación (ya que los usuarios desean ver las publicaciones de forma ordenada). Para ello, puede generar ID de publicación en función de un valor temporal, como un identificador ordenable lexicográficamente único y universal (ULID).

Paso 5: Abordar el patrón de acceso 5 (getUserLikesByPostID)

Para obtener una lista de los usuarios a los que les gusta una publicación de un usuario determinado, necesitaremos Query la tabla base con una condición de clave de PK=<postID>#likelist. Este enfoque es el mismo patrón que utilizamos para recuperar el seguidor y las listas de seguidores en el patrón de acceso 2 (getFollowerListByUserID) y el patrón de acceso 3 (getFollowingListByUserID).

Paso 6: Abordar el patrón de acceso 6 (getLikeCountByPostID)

Para obtener un recuento de los “me gusta” de una publicación determinada, tendremos que realizar una operación GetItem en la tabla base con una condición clave de PK=<postID>#likecount. Este patrón de acceso puede provocar problemas de limitación cuando un usuario con muchos seguidores (como una celebridad) crea una publicación, ya que la limitación se produce cuando el rendimiento de una partición supera los 1000 WCU por segundo. Este problema no se debe a DynamoDB, solo aparece en DynamoDB, ya que se encuentra al final de la pila de software.

Debe evaluar si es realmente esencial que todos los usuarios vean el recuento de me gusta simultáneamente o si se puede producir de forma gradual con el tiempo. En general, el recuento de “me gusta” de una publicación no necesita ser inmediatamente preciso al 100 %. Puede implementar esta estrategia poniendo una cola entre la aplicación y DynamoDB para que las actualizaciones se realicen periódicamente.

Paso 7: Abordar el patrón de acceso 7 (getTimelineByUserID)

Para obtener la cronología de un usuario determinado, necesitaremos realizar una operación Query en la tabla base con una condición de clave de PK=<userID>#timeline. Vamos a tener en cuenta un escenario en el que los seguidores de un usuario necesitan ver su publicación de forma sincrónica. Cada vez que un usuario escribe una publicación, se lee su lista de seguidores y el ID de usuario e ID de publicación se ingresan lentamente en la clave de la cronología de todos sus seguidores. A continuación, cuando se inicie la aplicación, podrá leer la clave de cronología con la operación Query y llenar la pantalla de la cronología con una combinación de ID de usuario e ID de publicación mediante la operación BatchGetItem para cualquier elemento nuevo. No puede leer la cronología con una llamada a la API, pero esta es una solución más rentable si las publicaciones se pueden editar con frecuencia.

La cronología es donde se muestran las publicaciones recientes, por lo que necesitaremos una forma de limpiar las antiguas. En lugar de utilizar WCU para eliminarlas, puede utilizar la característica TTL de DynamoDB para hacerlo de forma gratuita.

En la tabla siguiente se resumen todos los patrones de acceso y cómo los aborda el diseño del esquema:

Esquema final de red social

Este es el diseño final del esquema. Para descargar este diseño de esquema como un archivo JSON, consulte los ejemplos de DynamoDB en GitHub.

Tabla base:

Uso de NoSQL Workbench con este diseño de esquema

Puede importar este esquema final en NoSQL Workbench, una herramienta visual que proporciona características de modelado de datos, visualización de datos y desarrollo de consultas para DynamoDB, a fin de explorar y editar más a fondo el nuevo proyecto. Para comenzar, siga estos pasos: