Quale DBMS è utile per letture superveloci e una struttura dati semplice?

Sto sviluppando un prodotto che, come parte del suo funzionamento, deve tenere traccia di un gran numero di file / directory. L'idea è quella di memorizzare le informazioni sulle statistiche in un database, quindi, all'avvio, creare watch per ogni file. I file che cambiano verranno messi in coda (nel database) per una sincronizzazione di gruppo con un database remoto. Verranno sincronizzati in ordine di priorità, un numero compreso tra 1 e 10.

Informazioni sul database:

• <100.000 voci di informazioni statistiche
• Intero database letto all'avvio, è necessario solo il percorso del file
• I file in coda avranno un campo prioritario (non è necessario cercare altro)
• Le inserzioni possono essere lente

Ho trovato un paio di database che penso funzioneranno, ma non sono sicuro di quale sarebbe il migliore:

• Redis - memorizza il percorso del file come chiave, i dati delle statistiche come valore; la coda sarebbe un elenco
• MongoDB : più opzioni di query rispetto a Redis, ma comunque veloce

Sto pensando che un database NoSQL sarebbe la soluzione migliore qui, poiché non c'è troppa logica relazionale in atto e la dimensione totale dei dati non è troppo grande (qualcosa come <100 mb, più vicino a <30 mb). Ho esaminato SQLite perché sembra essere abbastanza semplice da incorporare in un'applicazione installabile.

Poiché si tratta di un'applicazione distribuita per utenti finali e non di un server con carico elevato, il database non deve supportare molti utenti simultanei. La priorità principale qui è trovare un database il cui modello abbia più senso.

Quindi la domanda, quale database sarebbe più applicabile per questa situazione?

Inoltre, ci sono altri database che avrebbero più senso per un'applicazione come questa?

La prima cosa che mi viene in mente è un RDBMS particolare che mi è familiare. Riconosco, tuttavia, che potrebbe non essere il migliore per questa applicazione.

Quindi, il mio consiglio è di andare con un database che ti è familiare. Se hai familiarità con Redis o MongoDB, scegli uno di quelli. Se hai più familiarità con SQLite, scegli quello.

Su un database di queste dimensioni, sarà tutto abbastanza veloce. Anche i database che sono più pesanti del disco useranno una sorta di memorizzazione nella cache in modo che la velocità del disco non sia di grande preoccupazione.

Se non sei così interessato alla logica relazionale, vuoi una velocità di lettura davvero elevata e sei disposto a lavorare con un RDBMS, mi permetto di dire pregiudizievolmente di dire MySQL. Perché ???

Il motore di archiviazione MyISAM ha un'opzione che consente di aumentare la struttura fisica della tabella per migliorare le prestazioni. Cos'è questa opzione? L'opzione ALTER TABLE ROW_FORMAT.

Ad esempio, il libro MySQL Database Design and Tuning consiglia di utilizzare ROW_FORMAT = FIXED alle pagine 72,73. Ciò convertirà internamente tutti i campi VARCHAR in CHAR. Renderà la tabella MyISAM più grande, ma i SELECT eseguiti su di essa saranno molto più veloci. Posso attestarlo personalmente. Una volta avevo un tavolo da 1,9 GB. Ho cambiato il formato con ALTER TABLE tblname ROW_FORMAT = FIXED. Il tavolo è finito 3,7 GB. La velocità dei SELECT contro di essa era del 20-25% più veloce senza migliorare o cambiare nient'altro.

Cosa succede se si dispone già di una tabella MyISAM popolata di dati? È possibile ottenere metriche per le definizioni di colonna consigliate in base ai dati presenti nella tabella MyISAM. Quale query presenta queste metriche?

SELECT * FROM tblname PROCEDURE ANALYSE();

PROCEDURA ANALISI () Questo non visualizzerà i dati. Leggerà il valore di ogni colonna e raccomanderà le definizioni delle colonne. Esempio, se hai una colonna di tipo i cui valori sono 1-4, suggerirebbe di usare un ENUM di quei 4 valori. È quindi possibile scegliere di utilizzare TINYINT o CHAR (1) poiché occupano la stessa quantità di spazio (1 byte).

Ecco qualcos'altro da considerare: da quando pensavi di usare un DB NoSQL, hai mai pensato di usare MyISAM in maniera NoSQL? Questo è del tutto possibile.La pagina 175 dello stesso libro che ho citato suggerisce di usare le strutture HANDLER per leggere un tavolo senza il bagaglio relazionale . In effetti, la pagina 175 fornisce questo esempio:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

Questa tabella contiene milioni di righe. Supponiamo di dover creare un'applicazione per l'analisi dei dati che abbia i seguenti requisiti:

• Deve recuperare blocchi di informazioni il più rapidamente possibile.
• In base all'input dell'utente o ad altri fattori, probabilmente "salterà" nella tabella.
• Non si occupa di concorrenza o altri problemi di integrità dei dati.
• Non è richiesto il blocco della tabella tra applicazioni.

Questi comandi consentono letture rapide e sporche dalla tabella:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

Spero che questo dia spunti di riflessione. Per favore, guardaci dentro.

AVVERTIMENTO

Ciò che è molto ironico su di me quando scrivo questo particolare post è che ho scritto un post precedente su HANDLER usato nei binari di Percona Server e pensando che usarlo non fosse aggiornato . Da quel post precedente, non ho mai pensato di scrivere qualcosa a sostegno delle strutture HANDLER. Ora sto corretto.