MySQL GROUP BY intelligente per flussi di attività

Question

Sto costruendo un flusso di attività per il nostro sito e ho fatto alcuni progressi decenti con qualcosa che funziona abbastanza bene.

E 'alimentato da due tabelle:

flusso:

• id - Unico flusso Voce ID
• user_id - ID dell'utente che ha creato l'oggetto flusso
• object_type - Tipo di oggetto (attualmente "venditore" o "prodotto")
• object_id - ID interno dell'oggetto (attualmente l'ID venditore o l'ID del prodotto)
• action_name - L'azione intrapresa contro l'oggetto (attualmente o 'acquistare' o 'cuore')
• stream_date - Timestamp che l'azione era creato.
• hidden - Booleano di se l'utente ha scelto di nascondere l'elemento.

segue:

• id - Unico Segui ID
• user_id - L'ID utente della persona l'azione 'seguire'.
• following_user - L'ID dell'utente che viene seguito.
• followed - Timestamp che l'azione seguente è stata eseguita.

Attualmente sto utilizzando la seguente query per estrarre il contenuto dal database:

Query:

SELECT stream.*, 
    COUNT(stream.id) AS rows_in_group, 
    GROUP_CONCAT(stream.id) AS in_collection 
FROM stream 
INNER JOIN follows ON stream.user_id = follows.following_user 
WHERE follows.user_id = '1' 
    AND stream.hidden = '0' 
GROUP BY stream.user_id, 
    stream.action_name, 
    stream.object_type, 
    date(stream.stream_date) 
ORDER BY stream.stream_date DESC; 

Questa query effettivamente funziona abbastanza bene, e con un po 'di PHP per analizzare i dati restituiti da MySQL possono creare un buon flusso di attività con azioni dello stesso tipo da parte dello stesso utente che viene raggruppato insieme se il tempo tra le azioni non è troppo grande (vedi sotto l'esempio).

La mia domanda è, come faccio a fare questo più intelligente? Attualmente raggruppa per asse, l'attività "utente", quando ci sono più elementi di un particolare utente entro un certo periodo di tempo, MySQL sa raggrupparli.

Come posso rendere questo ancora più intelligente e raggruppare da un altro asse, come "object_id" quindi se ci sono più azioni per lo stesso oggetto in sequenza questi elementi sono raggruppati, ma mantenere la logica di raggruppamento che abbiamo attualmente per le azioni di raggruppamento/oggetti per utente. E l'implementazione di questo senza duplicazione dei dati?

Esempio di più oggetti che appaiono in sequenza:

Capisco soluzioni a problemi come questo può diventare molto complessa, molto rapidamente, ma mi chiedo se c'è un elegante e abbastanza semplice soluzione questo (si spera) in MySQL.

Answer 1

La mia impressione è che devi raggruppare per utente, come fai tu, ma anche, dopo quel raggruppamento, per azione.

Sembra a me come avete bisogno di una sottoquery come questo:

SELECT *, -- or whatever columns 
    SUM(actions_in_group) AS total_rows_in_group, 
    GROUP_CONCAT(in_collection) AS complete_collection 
    FROM 
    (SELECT stream.*, -- or whatever columns 
      COUNT(stream.id) AS actions_in_user_group, 
      GROUP_CONCAT(stream.id) AS actions_in_user_collection 
     FROM stream 
     INNER JOIN follows 
     ON stream.user_id = follows.following_user 
     WHERE follows.user_id = '1' 
     AND stream.hidden = '0' 
     GROUP BY stream.user_id, 
      date(stream.stream_date) 
    ) 
    GROUP BY object_id, 
      date(stream.stream_date) 
    ORDER BY stream.stream_date DESC; 

vostra query iniziale (ora quella interna) gruppi per utente, ma poi i gruppi di utenti vengono raggruppati da azioni identiche - cioè, prodotti identici acquistati o vendite da un venditore sarebbero messi insieme.

Answer 2

Alcune osservazioni circa i risultati desiderati:

Alcuni degli articoli sono aggregati (Jack Sprat Hearted sette venditori) e altri sono dettagliati (Lord Nelson ha noleggiato la Golden Hind). Probabilmente hai bisogno di avere UNION nella tua query che riunisca queste due classi di elementi da due subquery separate.

È possibile utilizzare una funzione di timestamp near-town piuttosto approssimativa per raggruppare gli articoli ... DATE(). Si consiglia di utilizzare lo schema di più sofisticato e tweakable ... così, forse

GROUP BY TIMESTAMPDIFF(HOUR,CURRENT_TIME(),stream_date) DIV hourchunk 

Questo vi permetterà di roba gruppo da pezzi di età. Ad esempio, se utilizzi 48 per hourchunk, raggrupperai elementi che vanno da 0 a 48 ore fa insieme. Man mano che aggiungi traffico e azioni al tuo sistema, potresti voler ridurre il valore hourchunk.

Answer 3

Oltre a Fashiolista abbiamo aperto il nostro approccio alla costruzione di sistemi di alimentazione. https://github.com/tschellenbach/Feedly Attualmente è la più grande libreria open source per risolvere questo problema. (ma scritto in Python)

Lo stesso team che ha creato Feedly offre anche un'API ospitata, che gestisce la complessità per voi. Dai uno sguardo a getstream.io Ci sono client per PHP, Node, Ruby e Python. https://github.com/tbarbugli/stream-php Offre anche il supporto per le aggregazioni definite personalizzate, che si sta cercando.

Inoltre un'occhiata a questo post elevata scalabilità erano spiegare alcune delle decisioni di progettazione coinvolti: http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html

This tutorial vi aiuterà a configurare un sistema come il Feed di Pinterest utilizzando Redis. È abbastanza facile iniziare.

Per saperne di più sul design di alimentazione mi raccomando di leggere alcuni degli articoli che abbiamo basato Feedly on:

• Yahoo Research Paper
• Twitter 2013 Redis based, con fallback
• Cassandra at Instagram
• Etsy feed scaling
• Facebook history
• Django project, con buone convenzioni di denominazione. (Ma database solo)
• http://activitystrea.ms/specs/atom/1.0/ (attore, verb, oggetto, bersaglio)
• Quora post on best practises
• Quora scaling a social network feed
• Redis ruby example
• FriendFeed approach
• Thoonk setup
• Twitter's Approach

Answer 4

Abbiamo risolto un problema simile usando l'approccio 'vista materializzata' - stiamo usando una tabella dedicata che viene aggiornata sull'evento insert/update/delete. Tutte le attività dell'utente sono registrate in questa tabella e preparate per la selezione e il rendering semplici.

Il vantaggio è una selezione semplice e rapida, lo svantaggio è un po 'più lento inserimento/aggiornamento/eliminazione poiché la tabella del registro deve essere aggiornata.

Se questo sistema è ben progettato, è una soluzione vincente.

Questo è abbastanza facile da implementare se si utilizza ORM con il post di inserimento/aggiornamento/eliminare gli eventi (come Dottrina)