design - trucos - ¿Cómo muestra Trello la historia tan rápido?

plataforma trello

Question

Trello muestra un registro histórico de todo lo que cualquier usuario ha hecho desde el inicio de la junta. Del mismo modo, si hace clic en una tarjeta específica, muestra el historial de cualquier cosa que alguien haya hecho relacionado con esa tarjeta.

Hacer un seguimiento de cada cambio / adición / eliminación que se mantiene indefinidamente debe reunir una tonelada de datos y también un posible cuello de botella al escribir en el registro del historial (suponiendo que se escriba de inmediato en un almacén de datos). Quiero decir, no es como si estuvieran almacenando todo en archivos de registro distribuidos en miles de servidores que solo recopilan y analizan cuando necesitan encontrar algo: muestran toda esta información todo el tiempo.

Sé que este no es el único servicio que ofrece algo como esto, pero ¿cómo harías para diseñar un sistema así?

Answer 1

Estoy en el equipo de Trello. Usamos una colección Actions en nuestra instancia MongoDB, con un índice compuesto en los ids de los modelos a los que hace referencia (una Tarjeta es un modelo, y también lo es un Miembro) y la fecha en que se realizó la acción. No hay almacenamiento en caché elegante ni nada, excepto en la medida en que el índice y los documentos usados ​​recientemente se mantienen en la memoria de la base de datos. Las acciones son, con mucho, nuestra mayor colección.

Vale la pena mencionar que la mayoría de los datos necesarios para mostrar una acción se almacenan desnormalizados en el documento de acción, lo que acelera considerablemente las cosas.

Answer 2

La manera más fácil que viene a la mente es tener una tabla como:

create table HistoryItems (
ID INT PK,
UserID INT PK,
DateTime datetime,
Data varbinary(max)/varchar(max)/...)

Indexar esto en UserID permite una recuperación rápida. Un índice de cobertura permitiría buscar el historial de un usuario completo en un solo disco, sin importar cuánto tiempo sea.

Esta tabla se puede agrupar en (ID de usuario asc, desc. Fechahora, ID) por lo que ni siquiera tiene que tener ningún índice y aún así tener un rendimiento óptimo.

Cualquier problema fácil para una base de datos relacional.

Answer 3

Tengo algo muy similar a @Brett de Trello que respondí anteriormente en mi aplicación PHP + MySQL que uso para rastrear la actividad del usuario en nuestra aplicación de administración de producción y pedidos para nuestra tienda web en línea.

Tengo actividades de mesa que tienen:

• user_id : usuario que realizó una acción
• action_id : la acción que se realizó (por ejemplo, crear, actualizar, eliminar, etc.)
• resource : la lista ENUM de recursos (modelos) en los que se realizó la acción (por ejemplo, pedidos, facturas, productos, etc.)
• resource_id : PK del recurso en el que se realizó la acción
• description : descripción de texto de la acción (puede ser nulo)

Es una mesa grande de hecho, pero con índices correctos maneja muy bien. Actúa su propósito. Es simple y rapido Actualmente tiene 200k registros y crece con cca. 1000 nuevas entradas por día.