Me he estado preguntando cómo Facebook administra el diseño de la base de datos para todas las diferentes cosas que puede "me gusta". Si hay una sola cosa para agradar, esto es simple, solo una clave externa para lo que te gusta y una clave externa para lo que eres.Facebook "me gusta" estructura de datos
Pero debe haber cientos de tablas diferentes que puede "me gusta" en Facebook. ¿Cómo almacenan los Me gusta?
Si desea representar este tipo de estructura en una base de datos relacional, entonces necesita usar una jerarquía que normalmente se conoce como herencia de tablas. En la herencia de tablas, tiene una sola tabla que define un tipo padre, luego tablas secundarias cuyas claves primarias también son claves foráneas de nuevo al padre.
Usando el ejemplo de Facebook, es posible que tenga algo como esto:
User
------------
UserId (PK)
Item
-------------
ItemId (PK)
ItemType (discriminator column)
OwnerId (FK to User)
Status
------------
ItemId (PK, FK to Item)
StatusText
RelationshipUpdate
------------------
ItemId (PK, FK to Item)
RelationshipStatus
RelationTo (FK to User)
Like
------------
OwnerId (FK to User)
ItemId (FK to Item)
Compound PK of OwnerId, ItemId
En la integridad de interés, vale la pena señalar que Facebook no utiliza un RDBMS para este tipo de cosas. Han optado por una solución NoSQL para este tipo de almacenamiento. Sin embargo, esta es una forma de almacenar dicha información débilmente acoplada dentro de un RDBMS.
Puede tener una tabla con Id, ForeignId y Tipo. Tipo puede ser cualquier cosa como Foto, Estado, Evento, etc ... ForeignId sería la identificación del registro en la tabla Tipo. Esto hace posible los comentarios y me gusta. Solo necesita una tabla para todos los Me gusta, uno para todos los comentarios y el que describí.
Ejemplo:
Items
Id | Foreign Id | Type
----+-------------+--------
1 | 322 | Photo
4 | 346 | Status
Likes
Id | User Id | Item Id
----+-------------+--------
1 | 111 | 1
Aquí, el usuario con el identificador 111 le gusta la foto con Id 322.
Nota: Asumo que está utilizando un RDBMS, pero veo la respuesta de Adron. Facebook hace no usa un RDBMS para la mayoría de sus datos.
Pero entonces no se puede utilizar restricciones en el "ID foráneo" – Enrique
@Enrique puedes contar? Ciertamente hay restricciones en cuanto a lo que se puede y no se puede hacer cumplir en un patrón de herencia de tablas usando solo restricciones de RI, pero no está claro de qué se está hablando. –
@ Adam Robinson La columna "Foreign_Id" en la tabla "Artículos" no es un FK real, porque no se puede apuntar a ninguna tabla, porque apunta a muchas tablas en realidad (dependiendo de la columna "Tipo"), entonces no puedes poner un FK (y por lo tanto una restricción) allí. Eso podría hacer que sus datos sean inconsistentes. – Enrique
Facebook no tiene claves externas tradicionales y tal, ya que no usan bases de datos relacionales para la mayor parte de su almacenamiento de datos. Simplemente, no lo cortan por eso.
Sin embargo, utilizan varios almacenes de datos de tipo NoSQL. El "Me gusta" probablemente se atribuye en función de un servicio, probablemente configurado de manera SOA en toda su infraestructura. De esta manera, el "Me gusta" se puede atribuir básicamente a cualquier cosa que quieran que se asocie. Todo esto, con gran escalabilidad y sin problemas relacionales estrechamente relacionados con los que lidiar. Algo que Facebook, realmente no puede afrontar en el volumen que operan.
También podrían estar utilizando un mecanismo de procesamiento de estilo AOP (Aspecto orientado) para "adjuntar" un "Me gusta" a cualquier cosa que pueda necesitar en el tiempo de renderizado de la página, pero me da la sensación de que es un proceso asíncrono mediante JavaScript contra un servicio web de estilo SOA u otro mecanismo de entrega.
De cualquier manera, me encantaría saber cómo tienen esta configuración desde una perspectiva de arquitectura. Teniendo en cuenta su volumen, incluso el simple botón "Me gusta" se convierte en una implementación significativa de la tecnología.
-1. "No lo cortan para eso" es una cuestión de opinión y mucha especulación. La única parte de esta respuesta que realmente aborda la pregunta (cómo podrían almacenarse tales cosas) es su segundo párrafo. –
+1 @adam, simple hecho tecnológico, sin opinión involucrada. Los RDBMS están diseñados para un modelo de uso diferente. –
Como @StephanEggermont dice que Adam es para un modelo diferente, un propósito diferente, Facebook necesitaba más. No estoy especulando y la comunidad general de bases de datos y la comunidad científica están de acuerdo. Esa es la razón por la que existen otras soluciones. #justsayin En cuanto a su afirmación anterior, las teclas no están alineadas de esa manera. Es una forma que funciona para un RDBMS, pero el RDBMS no pudo suministrar ni manejar los datos que trata Facebook. Facebook no intentó soltar RDBMS solo porque querían escribir algo más. – Adron
Estoy bastante seguro de que Facebook no almacena información "me gusta" como otros sugirieron usar RDBMS. Con millones de usuarios y posiblemente miles de usuarios similares, estamos buscando miles de filas para unirnos, lo que afectaría el rendimiento.
El mejor enfoque aquí es agregar todos los "me gusta" en una sola fila. Por ejemplo, una tabla con la columna user_like_id de tipo de datos de texto. Luego, se anexan todas las identificaciones a las que les gustó la publicación. En este caso, solo consultas una fila y obtienes todo. Esto será mucho más rápido que unir mesas y obtener conteos.
EDIT: No he estado aquí en este sitio últimamente y acabo de descubrir que esta respuesta ha sido desestimada. Bueno, aquí hay un example post with like count and their avatars. Este es mi diseño donde acabo de implementar lo que estoy hablando.
Los dos componentes aquí son 1.) Tabla XREF y 2.) Objeto JSON.
Los gustos aún se almacenan en una tabla XREF. Pero al mismo tiempo, los datos se anexan al objeto JSON y se almacenan en una columna de texto en la tabla de publicaciones.
¿Por qué almacené la información de "Me gusta" en una columna de texto como JSON? De modo que no hay necesidad de hacer búsquedas/uniones de db para los "me gusta". Si alguien a diferencia de la publicación, el objeto JSON se acaba de actualizar.
Ahora no entiendo por qué de esta respuesta se bajan los votos de algunos usuarios aquí. Esta respuesta proporciona una recuperación de datos rápida. Esto está cerca del enfoque NoSQL, que es cómo FB accede a los datos. En este caso, no hay necesidad de combinaciones/búsquedas adicionales para obtener información de Me gusta.
Y aquí está la tabla que contiene los gustos. Es solo una simple asignación de XREF entre el usuario y la tabla de elementos.
Eso podría ser una solución, creo que el problema es que "everyhing" debe ser un "Item" porque ¿qué pasa si tienes una tabla que no es un Item y algún día quieres un Me gusta también para eso ?. Creo que a veces cuanto más simple es mejor, ¿por qué no hacer la herencia opuesta? al igual que el padre y usted tiene una tabla like_for_status con un estado FK, y like_for_photo, etc. puede extenderla fácilmente a cualquier tabla, y sus consultas también son más rápidas. – Enrique
+1, aunque creo que te refieres a ** Tabla por tipo ** o TPT. – Yuck
@Yuck: Sí, TPT (en lugar de Table-Per-Hierarchy), aunque TPT y TPH son, hasta donde sé, parte del léxico de Entity Framework en lugar de ser más genéricamente SQL. –