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

Question

Trello muestra un registro histórico de todo lo que cualquier usuario ha hecho desde el inicio de la placa. 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.

Realizar un seguimiento de cada cambio/adición/eliminación que se mantiene indefinidamente debe reunir una tonelada de datos y también un cuello de botella al escribir en el registro de seguimiento de historial (suponiendo que se escriba inmediatamente 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 de este tipo?

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 forma más sencilla 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)/...) 

de indexación en este ID de usuario permite la 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 pueden agruparse en (asc ID de usuario, DateTime la descripción, ID) por lo que ni siquiera tiene que tener cualquier índice en absoluto 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 respondió anteriormente en mi aplicación PHP + MySQL que utilizo 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.

He actividades de mesa que se tiene:

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

Es una mesa grande de hecho, pero con índices adecuados se 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.