Io ad Hans consiglio di venire a gustarsi i discorsi della migrazione su discord, perché secondo me si gasa tantissimo a vedere quando abbassano il tpc (time per chunk) di 1s
[QUOTE=Kaldais;20778068]Che intendi per indicizzazione? Database o Discourse che si salva i dati per il search? Comunque non è neanche quello il problema.
Il problema è (era, mi auguro) che Discourse ha una struttura dati ben specifica per gestire i quote e reply, praticamente per ogni quote stiamo inserendo una riga 1 a 1 in una tabella a parte in maniera tale da avere la relazione: post → tutti i reply associati, così da poter fare una cosa standard e pulita.
Vien abbastanza naturale capire che più il topic è grande più quote ci sono più aumentano questi dati, nei quali dobbiamo cercare “id del post vecchio” ed “id del post nuovo”, facendo crescere di brutto la time complexity. Dato che son un coglione mi son ricordato che esistono gli hashmap solo ieri ed ora abbiamo abbasato di molto questo tempo 
[/QUOTE]Old but gold
Inviato dal mio SM-G781B utilizzando Tapatalk
[QUOTE=Crius;20778002]
Goran sta testando sia su un ryzen9 con ventordici core, che un ARM su un M1. L’M1 non regge il confronto quindi punteremo sul ryzen[/QUOTE]
Ovvio:
Va fatto su m2 max 
[QUOTE=Kaldais;20778068]Il problema è (era, mi auguro) che Discourse ha una struttura dati ben specifica per gestire i quote e reply, praticamente per ogni quote stiamo inserendo una riga 1 a 1 in una tabella a parte in maniera tale da avere la relazione: post → tutti i reply associati, così da poter fare una cosa standard e pulita. [/QUOTE]
Si che in realtà credo sia una cretinata, perché se le mie competenze non sono lacunose significa che ad ogni query sul post mysql si passa tutte le righe incluse il contenuto. Era molto più efficiente una relazione per id stile vbb, ma tant’è, se lo dici ai dev Discourse sanno tutto loro e te hai sempre torto, quindi bene così :v
[QUOTE=cecio;20778086]Old but gold
https://youtu.be/kVgy1GSDHG8 [/QUOTE]
Ho evitato accuratamente di cominciare a scrivere O(n^2) e O(1) dopo la modifica per evitare queste robe da technical interview , però vedi che alla fine qualcosa serve sapere
[QUOTE=GnR!;20778138]Si che in realtà credo sia una cretinata, perché se le mie competenze non sono lacunose significa che ad ogni query sul post mysql si passa tutte le righe incluse il contenuto. Era molto più efficiente una relazione per id stile vbb, ma tant’è, se lo dici ai dev Discourse sanno tutto loro e te hai sempre torto, quindi bene così :v[/QUOTE]
Mh non so se ho capito, o forse mi son spiegato male io prima, ma un conto è il post, un conto i post_reply, quest’ultima tabella è solo una tabella many-to-many che ha i riferimenti dei reply in base al post. Non è male come concetto, anzi, abbastanza standard. Considera poi che c’è redis sotto quindi è ok dai
[QUOTE=Sergio Baracco!;20778057]I megathread [/QUOTE]
oath 
Grazie per tutto il lavoro 
[QUOTE=Kaldais;20778011]T3mp primo utente ad entrare nel gruppo “cacacazzo plus plus”, grazie[/QUOTE]
eh no! quando hanno chiesto una mano gliel’ho data subito.
Per questo ora la wildcard per rompere il cazzo
[QUOTE=Kaldais;20778068]Che intendi per indicizzazione? Database o Discourse che si salva i dati per il search? Comunque non è neanche quello il problema.
Il problema è (era, mi auguro) che Discourse ha una struttura dati ben specifica per gestire i quote e reply, praticamente per ogni quote stiamo inserendo una riga 1 a 1 in una tabella a parte in maniera tale da avere la relazione: post → tutti i reply associati, così da poter fare una cosa standard e pulita.
Vien abbastanza naturale capire che più il topic è grande più quote ci sono più aumentano questi dati, nei quali dobbiamo cercare “id del post vecchio” ed “id del post nuovo”, facendo crescere di brutto la time complexity. Dato che son un coglione mi son ricordato che esistono gli hashmap solo ieri ed ora abbiamo abbasato di molto questo tempo [/QUOTE]
Immaginavo qualcosa del genere, altrimenti non si spiegava il salto da 8 a 28 gb del database
Per indicizzazione intendevo appunto della trasformazione che Discourse fa del contenuto del DB originale per adattarlo al suo sistema e poi costruire i vari strumenti di search etc
l'indicizzazione non viene fatta in migrazione
c'e' una serie di script che girano ogni tot. e costruiscono indici e cazzi vari
va detto che con una migrazione di, a quanto pare 6-7 ore, ci sta che sti job partano mentre sta ancora inserendo roba ma lo script di per se' non fa indicizzazione, il "cooking" e' il processo per cui la shorthand testuale ": asd :" diventa , o un [tweet ][ /tweet] diventa un iframe, etc etc che normalmente viene effettuata per ogni post al momento del submit, ma ovviamente in una migrazione viene fatta in bulk.
c'e' una serie di script che girano ogni tot. e costruiscono indici e cazzi vari
va detto che con una migrazione di, a quanto pare 6-7 ore, ci sta che sti job partano mentre sta ancora inserendo roba
ma lo script di per se' non fa indicizzazione, il "cooking" e' il processo per cui la shorthand testuale ": asd :" diventa , o un [tweet ][ /tweet] diventa un iframe, etc etc che normalmente viene effettuata per ogni post al momento del submit, ma ovviamente in una migrazione viene fatta in bulk.
mi prendo la colpa dei 14 thread da 40k+ post del 501 
scusate
Ngi Migration Crew se passate per Pordenone avanzate almeno una birra
scusate
Ngi Migration Crew se passate per Pordenone avanzate almeno una birra
Quindi tanti thread più piccoli è meglio che one grosso?
Interessante.
Interessante.
[QUOTE=Hans Win;20778479]Quindi tanti thread più piccoli è meglio che one grosso?
Interessante.[/QUOTE]
noooooooo
[QUOTE=llamazz;20778449]mi prendo la colpa dei 14 thread da 40k+ post del 501 :v
scusate
Ngi Migration Crew se passate per Pordenone avanzate almeno una birra [/QUOTE]Hai fatto tutto da solo 
[QUOTE=Hans Win;20778479]Quindi tanti thread più piccoli è meglio che one grosso?
Interessante.[/QUOTE]
lol
[QUOTE=Hans Win;20778479]Quindi tanti thread più piccoli è meglio che one grosso?
Interessante.[/QUOTE]
[QUOTE=Crius;20778002] L’M1 non regge il confronto quindi punteremo sul ryzen[/QUOTE]
[QUOTE=Goran;20778042]E’ un M1 Max GTTurbo con 32Gb di ram e ci sta mettendo esattamente il doppio
partiti insieme, al momento 42% per il Ryzen9, 24% per l’M1.[/QUOTE]
[QUOTE=Crius;20778516][/QUOTE]