come lo vedete un database sqlite gramde più di un gibabyte?
Ho un hosting che mi offre 10G di spazio web, ma di questi posso dedicare solamente un giga a mysql, mentre io ho bisogno di un database più grande. Anzi, per la precisione ho UNA tabella che può superare il giga tra dati e indici
La versione di php installata supporta sqlite così ho pensato di usare quello.
Fortunatamente ho bisogno di performance solamente in lettura, ma sinceramente non ce le vedo bene neanche in lettura le performance.
Che voi sappiate, sqlite li gestisce file così grandi?
E performance?
sqlite da oltre un giga
Moderatore: Staff
Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware, se l'argomento è generale usate il forum Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute.
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware, se l'argomento è generale usate il forum Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute.
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
- ZeroUno
- Staff

- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
sqlite da oltre un giga
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111-
ilmich
- Master

- Messaggi: 1646
- Iscritto il: lun 16 lug 2007, 17:39
- Slackware: 15.0 64bit
- Kernel: 5.15.27
- Desktop: kde
- Località: Roma
Re: sqlite da oltre un giga
http://www.sqlite.org/limits.html
la dimensione massima di un database (con sqlite3) è di 14TB quindi per quello dovresti essere ok.
per quanto riguarda le performance non mi sono mai spinto fino a questo punto pero' mi permetto di suggerirti lo sharding, ovvero la tecnica di definire una regola logica che ti consenta di suddividere i tuoi dati in database piu' piccoli.
eppoi cache per le select piu' complicate ( per quelle banali non ha senso se usi sqlite )
con un po' di pazienza si ottengono risultati notevoli
la dimensione massima di un database (con sqlite3) è di 14TB quindi per quello dovresti essere ok.
per quanto riguarda le performance non mi sono mai spinto fino a questo punto pero' mi permetto di suggerirti lo sharding, ovvero la tecnica di definire una regola logica che ti consenta di suddividere i tuoi dati in database piu' piccoli.
eppoi cache per le select piu' complicate ( per quelle banali non ha senso se usi sqlite )
con un po' di pazienza si ottengono risultati notevoli
- ZeroUno
- Staff

- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
Re: sqlite da oltre un giga
Ho in verità tre tabelle, ma due sono piccole rispetto alla prima.
Il problema è che non c'è una grande organizzazione da fare con i dati che ho.
Ho una tabella con due campi varchar (uno più corto e uno più lungo), e un id per legarla alle prime due, e qualche vagonata di righe.
la ricerca è del tipo campocorto LIKE '%stri%nga%', quindi è una ricerca banale, ma può tirare fuori molti risultati, e a seconda della ricerca può impiegare anche fino a 2 minuti (con mysql). I risultati li cacho perchè li devo mostrare da browser e se superano i 20 elementi li devo mostrare in più pagine e con la chache mi evito di rifare ogni volta la query.
Mi vengono in mente ora un paio di ottimizzazioni.
La prima forse mi consentirebbe di fare tutto con mysql:
1) dal momento che la ricerca avviene esclusivamente su campocorto e campolungo è solo l'output, potrei pensare di inserire il secondo campo zippato
2) faccio due tabelle, legate uno ad uno, la prima contiene solo campocorto e la seconda solo campolungo, poi faccio la ricerca sulla prima tabella, prelevo gli id e li cerco nella seconda tabella
Il problema è che non c'è una grande organizzazione da fare con i dati che ho.
Ho una tabella con due campi varchar (uno più corto e uno più lungo), e un id per legarla alle prime due, e qualche vagonata di righe.
la ricerca è del tipo campocorto LIKE '%stri%nga%', quindi è una ricerca banale, ma può tirare fuori molti risultati, e a seconda della ricerca può impiegare anche fino a 2 minuti (con mysql). I risultati li cacho perchè li devo mostrare da browser e se superano i 20 elementi li devo mostrare in più pagine e con la chache mi evito di rifare ogni volta la query.
Mi vengono in mente ora un paio di ottimizzazioni.
La prima forse mi consentirebbe di fare tutto con mysql:
1) dal momento che la ricerca avviene esclusivamente su campocorto e campolungo è solo l'output, potrei pensare di inserire il secondo campo zippato
2) faccio due tabelle, legate uno ad uno, la prima contiene solo campocorto e la seconda solo campolungo, poi faccio la ricerca sulla prima tabella, prelevo gli id e li cerco nella seconda tabella
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111-
ilmich
- Master

- Messaggi: 1646
- Iscritto il: lun 16 lug 2007, 17:39
- Slackware: 15.0 64bit
- Kernel: 5.15.27
- Desktop: kde
- Località: Roma
Re: sqlite da oltre un giga
in realtà è proprio con tabelle tipo le tue che lo sharding ha la sua piu' semplice applicazione.
una volta che hai un insieme di id, come recuperi il dato sta alla tua immaginazione
ti suggerisco un paio di idee:
- puoi andare a pescare direttamente da filesystem oggetti php serializzati(magari organizzandoli in sottocartelle).
- puoi usare sqlite suddividendo i database in base a dei range di id (1-100) primo database (101-200) secondo database e via dicendo (questo è lo sharding)
denormalizzandolo in questo modo infatti, il tuo database ha una tabella di lookup fatta con mysql/sqlite, con tutti i soliti vantaggi in termini di ricerca e efficienza.ZeroUno ha scritto:2) faccio due tabelle, legate uno ad uno, la prima contiene solo campocorto e la seconda solo campolungo, poi faccio la ricerca sulla prima tabella, prelevo gli id e li cerco nella seconda tabella
una volta che hai un insieme di id, come recuperi il dato sta alla tua immaginazione
ti suggerisco un paio di idee:
- puoi andare a pescare direttamente da filesystem oggetti php serializzati(magari organizzandoli in sottocartelle).
- puoi usare sqlite suddividendo i database in base a dei range di id (1-100) primo database (101-200) secondo database e via dicendo (questo è lo sharding)