Ho java logging delle attività degli utenti su Fluentd , Fluentd sta quindi scrivendo queste attività in un elasticsearch indice.
Ogni attività dell'utente è registrata, alcuni includono:
- Utente1 segue utente2
- Utente1 piace articolo1
- L'utente1 crea l'articolo
- Utente1 cerca il tag
- utente2 si iscrive
- piu '...
Ora per ciascuna di queste attività sto memorizzando un oggetto utente. Ad esempio, un'attività CREATED sarà simile a questa:
{
activity: "CREATED",
user: {
userId: X,
userName: xxxx,
},
{
article: {
title: XOXO,
description: "LOTS OF MARKUP",
date: DATE_CREATED,
...more data on article include locations, coords, etc...
tags: [
{tagName: "relatedTagToArticle, tagId: 1}
{tagName: "relatedTag2ToArticle, tagId: 2}
],
},
}}
Il documento potrebbe diventare più grande per diverse attività. Ma memorizzando questo tipo di informazioni sarei in grado di select * activities where activities.user = [list of the users followers] ed elaborare i risultati in una sorta di algoritmo.
Va bene conservare attività come questa? Dovrei evitare questo, in caso affermativo perché?
Mi sto anche chiedendo come dovrei capire e archiviare tag e ricerche popolari?
Devo avere un programma che esegue ogni X minuti e calcola il numero di attività uniche SEARCH e memorizza tali informazioni in un elenco Redis?
Modifica
Uno dei motivi principali per cui vorrei aggiungere tutte queste informazioni extra (la memorizzazione di oggetti interi, come un articolo) è che posso interrogare l'indice ES e ottenere attività da utenti seguaci!
Quindi dire che volevo creare un feed di notizie nella mia app, potrei interrogare es con qualcosa di simile a questo (pseudo codice):
{
select all from user_activities
where {
activity_type: [LIKE, COMMENT, CREATED, FOLLOW]
userId: [LIST_OF_FOLLOWING_IDS]
date > XX AND date < YY
<SOMETHING HERE TO DETERMINE POPULAR ACTIVITIES>
}
}
Non sono sicuro se questo è un buon approccio o se verrà ridimensionato o no! Facendolo in questo modo, i dati memorizzati potrebbero diventare obsoleti, ad esempio se ho visualizzato un articolo CREATED dalla query precedente, l'articolo avrebbe potuto essere aggiornato! Anche se non sono ancora molto preoccupato per quello.