Welches DBMS eignet sich für superschnelle Lesevorgänge und eine einfache Datenstruktur?

Ich entwickle ein Produkt, das im Rahmen seines Betriebs eine große Anzahl von Dateien / Verzeichnissen nachverfolgen muss. Die Idee ist, stat-Informationen in einer Datenbank zu speichern und beim Booten Watches für jede Datei zu erstellen. Dateien, die sich ändern, werden (in der Datenbank) für eine Gruppensynchronisierung mit einer entfernten Datenbank in eine Warteschlange gestellt. Sie werden in der Reihenfolge ihrer Priorität synchronisiert, eine Zahl zwischen 1 und 10.

Informationen zur Datenbank:

• <100.000 Einträge von stat info
• Gesamte Datenbank wird beim Booten gelesen, nur der Dateipfad wird benötigt
• In die Warteschlange gestellte Dateien haben ein Prioritätsfeld (nichts anderes muss durchsucht werden)
• Einfügungen können langsam sein

Ich habe ein paar Datenbanken gefunden, von denen ich denke, dass sie funktionieren werden, aber ich bin mir nicht sicher, welche die besten wären:

• Redis - Dateipfad als Schlüssel speichern, Statistikdaten als Wert; Warteschlange wäre eine Liste
• MongoDB - mehr Abfrageoptionen als Redis, aber immer noch schnell

Ich denke, eine NoSQL-Datenbank wäre die beste Lösung, da hier nicht zu viel relationale Logik abläuft und die Gesamtdatenmenge nicht zu groß ist (etwa <100 MB, näher an <30 MB). Ich habe mir SQLite angesehen, weil es so einfach zu sein scheint, dass es in eine installierbare Anwendung eingebettet werden kann.

Da dies eine verteilte Anwendung für Endbenutzer und kein Hochlastserver ist, muss die Datenbank nicht viele gleichzeitige Benutzer unterstützen. Die Hauptpriorität besteht darin, eine Datenbank zu finden, deren Modell am sinnvollsten ist.

Also die Frage, welche Datenbank wäre für diese Situation am besten geeignet?

Gibt es auch andere Datenbanken, die für eine solche Anwendung sinnvoller wären?

Das erste, was mir einfällt, ist ein bestimmtes RDBMS, das mir vertraut ist. Ich erkenne jedoch, dass es möglicherweise nicht das Beste für diese Anwendung ist.

Mein Rat ist also, eine Datenbank zu verwenden, die Ihnen vertraut ist. Wenn Sie mit Redis oder MongoDB vertraut sind, sollten Sie eines dieser Programme wählen. Wenn Sie mit SQLite besser vertraut sind, wählen Sie diese Option.

Bei einer Datenbank dieser Größe wird alles ziemlich schnell gehen. Sogar Datenbanken, die mehr Speicherplatz benötigen, verwenden eine Art Zwischenspeicher, damit die Speichergeschwindigkeit nicht zu sehr ins Gewicht fällt.

Wenn Sie sich nicht so sehr mit relationaler Logik beschäftigen, eine wirklich schnelle Lesegeschwindigkeit wünschen und bereit sind, mit einem RDBMS zu arbeiten, würde ich es voreingenommen wagen, MySQL zu sagen. Warum ???

Die MyISAM-Speicher-Engine verfügt über eine Option, mit der die physische Struktur der Tabelle erweitert werden kann, um eine bessere Leistung zu erzielen. Was ist das für eine Option? Die ALTER TABLE-Option ROW_FORMAT.

In dem Buch MySQL Database Design and Tuning wird beispielsweise die Verwendung von ROW_FORMAT = FIXED auf den Seiten 72, 73 empfohlen. Dadurch werden alle VARCHAR-Felder intern in CHAR konvertiert. Dadurch wird die MyISAM-Tabelle größer, aber die Ausführung von SELECTs ist viel schneller. Das kann ich persönlich bestätigen. Ich hatte einmal einen Tisch mit 1,9 GB. Ich habe das Format mit ALTER TABLE tblname ROW_FORMAT = FIXED geändert. Die Tabelle endete 3,7 GB. Die Geschwindigkeit der SELECTs dagegen war 20-25% schneller, ohne etwas anderes zu verbessern oder zu ändern.

Was ist, wenn Sie bereits eine MyISAM-Tabelle haben, die mit Daten gefüllt ist? Sie können Metriken für empfohlene Spaltendefinitionen abrufen, die auf den Daten in der MyISAM-Tabelle basieren. Welche Abfrage zeigt diese Metriken an?

SELECT * FROM tblname PROCEDURE ANALYSE();

PROCEDURE ANALYZE () Hiermit werden keine Daten angezeigt. Es liest den Wert jeder Spalte und empfiehlt Spaltendefinitionen. Beispiel: Wenn Sie eine Typenspalte mit den Werten 1 bis 4 haben, wird die Verwendung einer ENUM dieser 4 Werte empfohlen. Sie können dann TINYINT oder CHAR (1) verwenden, da diese den gleichen Platz (1 Byte) beanspruchen.

Folgendes gilt es zu beachten: Haben Sie jemals darüber nachgedacht, MyISAM auf NoSQL-Art und Weise zu verwenden, seit Sie über die Verwendung einer NoSQL-Datenbank nachgedacht haben? Das ist durchaus möglich. Seite 175 des gleichen Buches, das ich erwähnte, schlägt vor, HANDLER-Strukturen zu verwenden, um eine Tabelle ohne das relationale Gepäck zu lesen . In der Tat gibt Seite 175 dieses Beispiel:

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;

Diese Tabelle enthält Millionen von Zeilen. Angenommen, Sie müssen eine Datenanalyse-Anwendung erstellen, die die folgenden Anforderungen erfüllt:

• Es muss so schnell wie möglich Informationsblöcke abrufen.
• Aufgrund von Benutzereingaben oder anderen Faktoren wird es wahrscheinlich in der Tabelle "herumspringen".
• Es geht nicht um Parallelität oder andere Datenintegritätsprobleme.
• Anwendungsübergreifende Tabellensperrung ist nicht erforderlich.

Diese Befehle ermöglichen schnelle und fehlerhafte Lesevorgänge aus der Tabelle:

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;

Ich hoffe das gibt Anlass zum Nachdenken. Bitte schauen Sie hinein.

VORBEHALT

Was sehr ironisch an mir ist, ist, dass ich einen früheren Beitrag über HANDLER geschrieben habe, der in Percona Server-Binärdateien verwendet wird, und dachte, dass seine Verwendung veraltet sei . Seit diesem älteren Beitrag hätte ich nie gedacht, dass ich jemals etwas zur Unterstützung von HANDLER-Strukturen schreiben würde. Ich stehe jetzt korrigiert.