it-swarm.com.de

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

Ich entwickle ein Produkt, das als Teil seines Betriebs eine große Anzahl von Dateien/Verzeichnissen verfolgen muss. Die Idee ist, Statistikinformationen in einer Datenbank zu speichern und beim Booten Uhren für jede Datei zu erstellen. Dateien, die sich ändern, werden (in der Datenbank) für eine Gruppensynchronisierung mit einer entfernten Datenbank in die 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
  • Beim Lesen der gesamten Datenbank wird nur der Dateipfad benötigt
  • Dateien in der Warteschlange 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 beste wäre:

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

Ich denke, eine NoSQL-Datenbank wäre hier die beste Lösung, da nicht zu viel relationale Logik vorhanden ist und die Gesamtdatengröße nicht zu groß ist (etwa <100 MB, näher an <30 MB). Ich habe mir SQLite angesehen, weil es einfach genug zu sein scheint, um es in eine installierbare Anwendung einzubetten.

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 für diese Situation am besten geeignet wäre?

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

16
beatgammit

Das erste, was mir in den Sinn kommt, ist ein bestimmtes RDBMS, das mir vertraut ist. Ich erkenne jedoch, dass es für diese Anwendung möglicherweise nicht das Beste ist.

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

In einer Datenbank dieser Größe wird alles ziemlich schnell gehen. Sogar Datenbanken mit höherer Festplattenlast verwenden eine Art Caching, damit die Festplattengeschwindigkeit keine allzu große Rolle spielt.

9
Richard

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 nachteilig wagen, MySQL zu sagen. Warum ???

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

In dem Buch MySQL Database Design and Tuning wird beispielsweise empfohlen, ROW_FORMAT = FIXED auf den Seiten 72, 73 zu verwenden. Dadurch werden alle VARCHAR-Felder intern in CHAR konvertiert. Dadurch wird die MyISAM-Tabelle größer, aber ausgeführte SELECTs dagegen werden viel schneller ausgeführt. Das kann ich persönlich bezeugen. Ich hatte einmal einen Tisch mit 1,9 GB. Ich habe das Format mit ALTER TABLE geändert. Tblname ROW_FORMAT = FIXED. Die Tabelle endete mit 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 basierend auf den in der MyISAM-Tabelle enthaltenen Daten abrufen. Welche Abfrage präsentiert diese Metriken?

SELECT * FROM tblname PROCEDURE ANALYSE();

PROCEDURE ANALYZE () Dies zeigt keine Daten an. Es liest den Wert jeder Spalte und empfiehlt Spaltendefinitionen. Wenn Sie beispielsweise eine Typspalte mit den Werten 1 bis 4 haben, wird empfohlen, eine ENUM dieser 4 Werte zu verwenden. Sie können dann TINYINT oder CHAR (1) verwenden, da diese dieselbe Menge an Speicherplatz (1 Byte) beanspruchen.

Folgendes ist noch zu beachten: Haben Sie jemals darüber nachgedacht, MyISAM auf NoSQL-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ähnt habe 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 Datenanalyseanwendung erstellen, für die die folgenden Anforderungen gelten:

  • Es muss Informationsblöcke so schnell wie möglich abrufen.
  • Basierend auf Benutzereingaben oder anderen Faktoren wird es wahrscheinlich in der Tabelle "herumspringen".
  • Es geht nicht um Parallelität oder andere Datenintegritätsprobleme.
  • Eine anwendungsübergreifende Tabellensperre 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, wenn ich diesen speziellen Beitrag schreibe, ist, dass ich einen früheren Beitrag über die Verwendung von HANDLER in Percona Server-Binärdateien geschrieben habe und dachte, dass die Verwendung veraltet ist . 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.

12
RolandoMySQLDBA