Concorso Twitter ~ salvataggio di tweet (PHP e MySQL)

Question

Sto creando un'applicazione per aiutare il nostro team a gestire una competizione su Twitter. Finora sono riuscito a interagire con l'API e a restituire una serie di tweet di cui ho bisogno.

Non riesco a stabilire il modo migliore per gestire l'archiviazione dei tweet nel database, con quale frequenza controllare e come garantire che non vi siano sovrapposizioni o lacune.

È possibile ottenere un numero massimo di 100 tweet per pagina. Al momento, la mia idea attuale è quella di eseguire uno script cron che dice, una volta ogni 5 minuti o giù di lì e catturare 100 tweet alla volta, e scorrere attraverso di loro guardando nel db per vedere se riesco a trovarli, prima di aggiungerli .

Questo ha l'ovvio inconveniente di eseguire 100 query sul db ogni 5 minuti, e comunque ci sono anche molte INSERT. Quale davvero non mi piace. Inoltre, preferirei avere qualcosa in più in tempo reale. Poiché Twitter è un servizio in diretta, è ovvio che dovremmo aggiornare la nostra lista di partecipanti non appena entrano.

Questo ripropone di nuovo l'inconveniente di dover ripetutamente sondare Twitter, che, anche se potrebbe essere necessario, non sono sicuro di voler battere le loro API in questo modo.

Qualcuno ha qualche idea su una soluzione elegante? Devo assicurarmi di catturare tutti i tweet e di non lasciare nessuno fuori, e di mantenere l'utente db unico. Anche se ho considerato di aggiungere tutto e quindi di raggruppare la tabella risultante per nome utente, ma non è in ordine.

Sono contento di occuparmi del lato display delle cose separatamente in quanto si tratta solo di un pull di mysql e display. Ma il design del backend mi sta facendo venire il mal di testa perché non riesco a vedere un modo efficiente per farlo scorrere senza battere né l'api né il db.

Answer 1

L'API di Twitter offre un'API streaming che è probabilmente quello che si vuole fare per assicurarsi di catturare tutto: http://dev.twitter.com/pages/streaming_api_methods

Se ho capito quello che stai cercando, probabilmente si vorrà un statuses/filter, utilizzando il parametro track con qualsiasi caratteristica distintiva (hashtag, parole, frasi, posizioni, utenti) che stai cercando.

Molte librerie API di Twitter hanno questo integrato, ma fondamentalmente si mantiene aperta una connessione HTTP e Twitter invia continuamente tweet mentre accadono. Vedi lo streaming API overview per i dettagli su questo. Se la tua biblioteca non lo fa per te, dovrai verificare la presenza di connessioni interrotte e riconnettersi, controllare i codici di errore, ecc. - è tutto nella panoramica. Ma aggiungerli appena entrati ti permetterà di eliminare completamente i duplicati in primo luogo (a meno che tu non permetta solo una voce per utente - ma questa è una restrizione sul lato del client di cui ti occuperai in seguito).

Per non rovinare il tuo DB, una volta che Twitter ti ha inviato solo materiale, hai il controllo sulla tua parte - potresti facilmente avere il client che memorizza nella cache i tweet appena arrivano, e poi scriverli in il db a un dato intervallo di tempo o di conteggio - scrivi qualsiasi cosa abbia raccolto ogni 5 minuti, o scrivi una volta che ha 100 tweet o entrambi (ovviamente questi numeri sono solo segnaposto). Questo è il momento in cui è possibile verificare la presenza di nomi utente esistenti, se necessario: la scrittura di un elenco memorizzato nella cache ti consentirebbe la migliore possibilità di rendere le cose efficienti come preferisci.

Aggiornamento: La mia soluzione di cui sopra è probabilmente il modo migliore per farlo se si desidera ottenere risultati in tempo reale (che sembra come si fa).Ma come menzionato in un'altra risposta, potrebbe essere possibile usare semplicemente lo Search API per raccogliere le voci dopo che il concorso è finito, e non preoccuparti di memorizzarle affatto - puoi specificare le pagine quando chiedi i risultati (come delineato nel Cerca collegamento API), ma ci sono dei limiti sul numero di risultati che è possibile recuperare in generale, il che potrebbe causare la perdita di alcune voci. Qual è la soluzione che funziona meglio per la tua applicazione dipende da te.

Answer 2

Ho letto la tua domanda e mi sembra che tu voglia duplicare i dati già memorizzati da Twitter. Senza ulteriori dettagli sulla competizione in corso, come gli utenti inseriscono, ad esempio, la quantità stimata di voci; è impossibile sapere se memorizzare o meno queste informazioni localmente su un database è il modo migliore per affrontare questo problema.

Potrebbe essere una soluzione migliore, saltare la memorizzazione dei dati duplicati a livello locale e trascinare i partecipanti direttamente da Twitter, cioè quando si tenta di trovare un vincitore. È possibile eliminare le voci duplicate al volo mentre il codice è in esecuzione. Dovresti solo chiamare "la prossima pagina" una volta terminata l'elaborazione delle 100 voci già recuperate. Sebbene, non sono sicuro che ciò sia possibile direttamente tramite l'API di Twitter.

Answer 3

100 query in 5 minuti non sono nulla. Tanto più che un tweet ha essenzialmente solo 3 pezzi di dati associati: ID utente, data e ora, tweet, tweet ID - per esempio, circa 170 caratteri di dati per tweet. A meno che non stiate eseguendo il vostro database su un 4.88 MHz 8088, il vostro database non batterà mai in quel tipo di "carico"

Answer 4

Penso che eseguire un cron ogni X minuti e basandolo fuori dalla data di creazione dei tweet possa funzionare . Puoi interrogare il tuo database per trovare l'ultima data/ora dell'ultimo tweet registrato, quindi eseguire solo seleziona se vi sono tempi corrispondenti per evitare duplicati. Quindi, quando si inseriscono i propri inserimenti nel database, utilizzare una o due istruzioni di inserimento contenenti tutte le voci che si desidera registrare per mantenere alto il rendimento.

INSERT INTO `tweets` (id, date, ...) VALUES (..., ..., ...), (..., ..., ...), ...; 

Questo non sembra troppo intenso ... dipende anche dal numero di tweet che si prevede di registrare. Assicurati anche di indicizzare correttamente la tabella.