Added a new table to a database.
It's about 120 columns.
I'll need to store tens of millions of rows.
Disk space is expensive.
Please DB experts, send help!
@rastinza@qoto.org
I'm not really a db expert, but hey, bytes are cheap.
The tens of millions of rows don't really bother me, db engines can do pretty smart stuff when the data is somewhat uniform.
120 columns now that kinda bothers me. Is really 120 the actual dimension of the basis of the space you're modeling?
And also, any chanche of some of those columns being of a more "archivistic" than "search" interest? If so you might transform those into a ugly string, and if there is some value repetition even catalog and deduplicate lotsadata
@lysander so, the 120 columns is data associated to another entity. It's a 1-1 relationship, I just created a new table to separate the ugly stuff.
It is mainly data storage, but search of some of those columns is expected. Not all those columns will be searched, but it is difficult to say which ones will be useful for search and which ones will not, also because what I'm searching depends on the project at hand.
Actually I expect to add maybe another 100 more...
No data duplication, at least not amongst different rows. Some columns are derived from others, but the computation while not really expensive relies on a bunch of other data external to the database which I don't really want to rely on.
Data is mostly numeric and long bit arrays.
I may get and try to find what is actually useful, but I also want to actually use the DB without spending one year tuning it.
I don't know, I'm generally afraid of databases and don't really know how to work with them: this is the first DB I work on with more than a couple tables.
@lysander let's put it this way: all data can readily be recomputed. I'm storing it to save computation time as computing 100 of those rows takes around one minute and that is not feasible every time I need to filter by one parameter.
@rastinza@qoto.org
Passo all'italiano per comodità, ma se preferisci ritorno all'inglese.
Alla fine è sempre un compromesso tra spazio/tempo di computazione, nel tuo caso direi che ricomputare è decisamente scomodo quindi ci si spinge quanto più sullo spazio. Mi ricorda un pochino i libroni di tabelle di logaritmi/probabilità.
Quando dici che non c'è duplicazione di dati sulle diverse righe, intendi considerando l'insieme di tutte le colonne o anche ogni suo sottoinsieme? Se hai le colonne A, B, C, le righeR1: pippo, 1, dehR2: paper, 2, deh
sono distinte, ma C è uguale in entrambe, e se riesci a individuare un insieme di valori che copre C per tutte le righe (e che sia più piccolo di quello banale), allora invece di scriverci il valore effettivo ci metti un id e sposti il valore su un'altra tabella. Non ti togli di mezzo una colonna ma gli id son piccoli e si impaccano molto bene.
Inoltre, potresti esplorare anche un approcio ibrido, diciamo che hai una colonna di float (funziona anche con le colonne di bitarray ma si complica un pochino) con valori da -100 a +100.
Qual'é la loro distribuzione? Se è ragionevolmente uniforme, e lo è anche quella delle ricerche che andresti a fare, puoi mantenerti un catalogo di bande (diciamo 1:[-100 - -50), 2:[-50 - 0), 3:[0 - 50), 4:[50 - 100]) su cui schiacci i valori effettivi, risparmiando un saaaacco di spazio e quando fai le ricerche prima ti orienti su una banda e poi ti ricomputi le righe interessanti al livello di dettaglio necessario.
Considera anche che lo spazio è costoso sì, ma i db sono efficienti. A meno di necessità particolari, in qualche tera ci stanno miliardi di righe su migliaia di tabelle, e qualche tera è alla portata di quasi chiunque
@lysander aspetta aspetta aspetta, questo è molto interessante e non ci avevo mai pensato!
Effettivamente ho dei valori che rientrano in piccoli range, diciamo 0-100 o qualcosa del genere.
Alcuni sono double, molti sono int.
Dici che ho dei vantaggi scambiando un int per una referenza a un'altra tavola? O magari solo mi vale per i double immagino.
Li dovrei mettermi a vedere.
I bitarray pure possono avere duplicati tra le righe, però non so quanti e non so se il gioco vale la candela. Perché ora sto usando un hash di 1024 bit, questo si che serve per cercare; chiaramente essendo un hash ho dei duplicati su grandi numeri. Però li non credo che mi valga la pena spostare a un altra tavola, uso l'hash perché è veloce e probabilmente il merge rallenterebbe troppo le ricerche.
Le ricerche sono sostanzialmente filtri, oltre questo valore, sotto quello. Probabilmente siano sempre le stesse e mi possa salvare il risultato direttamente nel DB, non lo faccio giusto per avere flessibilità sui parametri che posso variare.
Beh ci penserò un po' su. Ho molti alti problemi da risolvere... Dati invalidi che in qualche modo entrano nel DB, inconsistenze tra tavole...
Per farla semplice diciamo che ho una tavola con i miei elementi e due altre una con calcoli da fare l'altra con calcoli effettuati. Il totale delle due dovrebbe essere uguale al numero di elementi. Invece è superiore.
Mi devo mettere a vedere tutto il codice di connessione al database e trovare dove diamine sto aggiungendo cose che non dovrei aggiungere ed eventualmente come rimuovere cose che non dovrebbero esserci.
@GustavinoBevilacqua vogliamo inaugurare il nuovo tag #DBMolecole? Ti prometto molte bestemmie per i mesi a venire. (Ok, ci sto già lavorando da tempo ma il DB l'ho sempre lasciato lì per ultimo che non volevo metterci mano)
@rastinza@qoto.org @GustavinoBevilacqua@mastodon.cisti.org
Dici che ho dei vantaggi scambiando un int per una referenza a un'altra tavola?
Dipende (la risposta preferita dagli informatici).Prendiamo il caso di una colonna A dove mantieni valori int nel range 0-100. Hai 10M colonne. Un int occupa 4 bytes, quindi hai 40 milioni di bytes utilizzati da quella colonna.
MA
Pigeonhole distribuzione uniforme etcetera, hai il valore "42" in 100k righe. Per rappresentare tutti gli int 0-100 ti basta un byte. Diciamo che li metti tutti nel catalogo, e ti servono 100 bytes.
Lo spazio utilizzato per mappare i dati è passato da 40M a 100 bytes.
Certo, devi comunque associare riga della tavolona a riga del catalogo, ma per farlo, dato che il catalogo ha al più 100 righe, ti basta nuovamente un solo byte, quindi la colonna A avrà bisogno di 1 * 10M bytes.
10M (colonna A) + 100 (catalogo) = 10M bytes, un quarto.
Lo stesso vale per i float, forse a maggior ragione perché penso che usiate i double (che occupano otto bytes) per avere più precisione.
Tutto ciò a meno di costanti come lo spazio per i metadati della tabella, chiavi e cosine varie.
---------
Inoltre, in ogni punto in cui puoi dire che (colonna A, colonna B) => colonna C e C è grande e ripetuto, ti conviene spostare via i valori di C su una tabella a parte, e usare una chiave (A, B) per raggiungerli. Se scopri che D => (E, F) ancora meglio, invece di una ti risparmi due colonne!
@rastinza@qoto.org @GustavinoBevilacqua@mastodon.cisti.org
Altro toot perché poi diventava davvero un megapippone.
Sull'hash ti consiglio di fare molta attenzione. Se ti serve per rispondere alla domanda "questa riga esiste già?" valuta la possibilità usare un'indice sulle colonne che utilizzi per calcolarti l'hash. Perdi la visibilità sull'hash, ma i db sono molto furbi nel costruirsi indici leggeri ed efficienti.
Quanto alla spazzatura che entra nel db, ti capisco e posso assicurarti che capita spesso. Vincoli e chiavi sono difficili da scrivere ma una volta fatti stan lì e possono aiutare a ridurre di molto lo schifo che viene inserito
@lysander @GustavinoBevilacqua sicuro che a seguito di certi calcoli l'identificativo univoco che uso per riferirmi alle molecole mi cambia o qualcosa del genere. Dovrò cercare di renderlo più univoco.