[C/C++] Esiste un database cosi?

[sottovento]

Ciao a tutti,
dovrei fare il porting di una applicazione, la quale ha bisogno di memorizzare una mole piuttosto consistente (ma non esagerata) di dati, relativi alla produzione in serie di un prodotto.
Questi dati saranno poi "dimenticati" (leggi: cancellati/sovrascritti) nel caso il prodotto, al controllo di qualita', si riveli realizzato correttamente. In caso contrario, un operatore provvedera' al loro salvataggio in un database "storico".

La soluzione attuale utilizza un database "realtime", il quale ha tutte le tabelle di dimensione fissa. (E' ovviamente la soluzione migliore). Essendo tutti i record di dimensione fissa (soluzione accettabile) e' piuttosto facile da realizzare.
Vista la semplicita', risulta anche essere estremamente veloce: ogni tabella e' contenuta in un file, per cui una seek e via.
Quando la tabella e' piena, la scrittura successiva sovrascrivera' l'elemento piu' vecchio.

Purtroppo, nonostante la semplicita', questo database e' pieno di bug, alcuni anche piuttosto gravi.

Domanda: esiste qualcosa del genere? Oppure... esiste un'alternativa?

Avevo anche pensato di prendere un db tradizionale (es. MySQL) e caricarlo in una RAMDisk per motivi di velocita'. Siccome la dimensione massima e' nota, la soluzione faceva senso.

Purtroppo i file indice crescerebbero ad ogni inserimento, obbligandomi periodicamente a fermare la produzione per "ricompattare" il database, eventualmente ricreando gli indici.

Dimenticavo: al database accedono diversi processi/thread contemporaneamente.

Qualcuno ha qualche idea?

Grazie mille
Sottovento

[mad_hhatter]

scusa, forse non ho ben afferrato il problema, ma se i record sono parecchi una soluzione che sfrutti un indice è più veloce di una ricerca semplice su file, credo... inoltre se i dati li cancelli quando non più necessari perchè l'indice cresce?

[sottovento]

Originariamente inviato da mad_hhatter

scusa, forse non ho ben afferrato il problema, ma se i record sono parecchi una soluzione che sfrutti un indice è più veloce di una ricerca semplice su file, credo... inoltre se i dati li cancelli quando non più necessari perchè l'indice cresce?

Scusa, forse non mi sono spiegato bene io, oppure parto da ipotesi errate.

Cmq in generale i file di indice, come hai scritto, servono per rendere veloci le ricerche.
Questo e' un beneficio poiche' normalmente, in un database, si effettuano molte piu' ricerche che inserimenti.
Purtroppo il beneficio delle prestazioni in ricerca lo paghi negli inserimenti, visto che devi aggiornare, oltre ai record, i relativi indici.
Tutti gli aggiornamenti risultano appesantiti.

Ho fatto delle prove con MySql (senza la pretesa di essere esaustivo).
Ho creato una tabella ed ho provato a gestirla "circolarmente", facendo in modo che, una volta raggiunto il numero massimo prefissato di record, un nuovo inserimento andasse a riscrivere il record piu' vecchio.

Risultato: Il file di database (quello che contiene i dati) non cresceva. (Perfetto!).
Purtroppo il file di indice cresceva ad ogni "inserimento".

Ovviamente posso fermare l'applicazione e "ricompattarlo" (ci sono istruzioni sql a riguardo).

Se non ci fosse questo problema, la soluzione sarebbe ottimale: mi creo un bel disco RAM e ci carico il file di database...

Pero' e' tutto un po' strano: chiunque debba fare dei controlli di qualita', o acquisire dei dati automaticamente da macchinari/dispositivi di vario genere ha il mio stesso problema.

Mi sembra impossibile che non ci sia qualcosa di gia' pronto....

Grazie per l'aiuto
Sottovento

[mad_hhatter]

si ho capito il tuo problema... non conosco mysql, ma da quel che ho sentito dire è tra i piu veloci, quindi dovrebbe essere il migliore per le tue necessità. non è che per caso si può configurare in modo che non crei l'indice?

[mad_hhatter]

oppure perchè invece che inserire un nuovo elemento non MODIFICHI quello già esistente?

[sottovento]

Originariamente inviato da mad_hhatter

si ho capito il tuo problema... non conosco mysql, ma da quel che ho sentito dire è tra i piu veloci, quindi dovrebbe essere il migliore per le tue necessità. non è che per caso si può configurare in modo che non crei l'indice?

Originariamente inviato da mad_hhatter

oppure perchè invece che inserire un nuovo elemento non MODIFICHI quello già esistente?

Prima di tutto, grazie mille per l'aiuto.
Per quanto riguarda mysql, e' il primo database che mi e' venuto in mente di provare.
Tutto sommato, come sempre, la velocita' e' relativa: sono intenzionato a provare una soluzione basata su un disco RAM. Facendo un rapido conto mi sono accorto che e' ragionevole.
Questa soluzione dovrebbe risolvere il problema della velocita', dandomi ancora un certo respiro. A questo punto, potrei provare ad utilizzare anche qualche altro db, ma non ho idea quale.

Sulla creazione degli indici, hai perfettamente ragione. Purtroppo pero' MySql crea uno o piu' indici per le chiavi primarie, e se non piglio errore non e' possibile evitare questo.
Potrei ovviamente non utilizzare chiavi primarie oppure utilizzarne una fittizia (per esempio, un ID che va da 1 al numero massimo dei record). Pero' mi dispiacerebbe rinunciare ad un aiuto cosi' prezioso sulla congruenza dei miei dati...
Questo si collega anche al secondo post: ho provato a sovrascrivere, ma il nuovo prodotto ha un nuovo ID, ed il file indice collegato alla chiave primaria incrementa la sua dimensione.
Non ho provato facendo il campo primario "ID" di cui ti parlavo prima, ma non vorrei usare questa soluzione...

Conosci qualche altro database che potrei testare?

Grazie ancora
Sottovento

[mad_hhatter]

conosco postgresql, ma non abbastanza da avere info prestazionali (e cmq credo sia piu veloce mysql). però so che permette tabelle prive di chiave primaria... però non ho idea di come (e se) si possa disabilitare la creazione dell'indice.

però, potresti mettere come chiave primaria un campo contatore fittizio: in tal modo aggiornando il record, non dovresti preoccuparti di aggiornare la chiave. però se a te serve per forza che la chiave sia l'ID del prodotto allora non se ne fa niente.

[mad_hhatter]

che scemo, non ti ho chiesto la piattaforma... postgres ha da poco la versione per win, ma non so se è pronta per ambienti di produzione. quindi postgres è principalmente per linux. se sei sotto win prova a testare "sql server", ma è commerciale. in ogni caso non ho idea delle prestazioni.

però prova a cercare con google, magari un dbms più scarno ma piu veloce salta fuori

[sottovento]

Originariamente inviato da mad_hhatter

che scemo, non ti ho chiesto la piattaforma... postgres ha da poco la versione per win, ma non so se è pronta per ambienti di produzione. quindi postgres è principalmente per linux. se sei sotto win prova a testare "sql server", ma è commerciale. in ogni caso non ho idea delle prestazioni.

però prova a cercare con google, magari un dbms più scarno ma piu veloce salta fuori

La colpa e' mia, non l'ho specificata. Purtroppo e' win e questo taglia fuori molte possibilita'.

Ad ogni modo, parlando di dbms "scarno" hai perfettamente centrato il problema: non ho bisogno di fare trattamenti particolari o query sofisticate...

Ho gia' provato a googlare (prima di scrivere) ma sono stato un po' sfortunato. L'importante e' perseverare

Grazie
Sottovento

[mad_hhatter]

a questo punto, se hai bisogno di poco supporto dal dbms e se non hai troppi vincoli di integrità referenziale potresti addirittura optare per una soluzione ad hoc creando una mini applicazione che si prende carico di gestire una collezione di file e di rispondere alle tue query, una sorta di dbms fatto in casa altamente personalizzato e ottimizzato (cosa che lo renderebbe perfetto per un utilizzo realtime)

mi dispiace, ma non so dirti di più.

in bocca al lupo