Wir stellen einen (AJAX - basierten) Instant Messenger zur Verfügung, der von einem Comet Server bedient wird. Wir haben die Anforderung, die gesendeten Nachrichten für langfristige Archivierungszwecke in einer Datenbank zu speichern, um die gesetzlichen Aufbewahrungspflichten zu erfüllen.
Welche DB-Engine bietet die beste Leistung in dieser einmal schreibenden, nie gelesenen (mit seltenen Ausnahmen) Anforderung?
Wir brauchen mindestens 5000 Insert / Sec. Ich nehme weder MySQL noch PostgreSQL an kann diese Anforderungen erfüllen.
Irgendwelche Vorschläge für eine leistungsfähigere Lösung? HamsterDB, SQLite, MongoDB ...?
Wenn Sie die Daten niemals abfragen, würde ich sie nicht in einer Datenbank speichern. Sie werden niemals die Leistung übertreffen, wenn Sie sie einfach in eine flache Datei schreiben.
Was Sie beachten sollten, sind die Skalierungsprobleme, was passiert, wenn es zu langsam ist, um die Daten in eine flache Datei zu schreiben, werden Sie in schnellere Festplatten oder etwas anderes investieren.
Sie sollten auch überlegen, wie Sie den Dienst skalieren können, damit Sie weitere Server hinzufügen können, ohne die Protokolle jedes Servers koordinieren und manuell zusammenführen zu müssen.
edit: Sie haben geschrieben, dass Sie es in einer Datenbank haben wollen, und dann würde ich auch Sicherheitsprobleme bei der Online-Datenverwaltung berücksichtigen, was passiert, wenn Ihr Dienst kompromittiert wird, wollen Sie, dass Ihre Angreifer in der Lage sind, Änderungen vorzunehmen die Geschichte von dem, was gesagt wurde?
Es könnte schlauer sein, es temporär in einer Datei zu speichern und es dann an einen externen Ort zu speichern, auf den nicht zugegriffen werden kann, wenn Ihre Internet-Fronten gehackt werden.
Bitte ignorieren Sie den obigen Benchmark, in dem wir einen Bug hatten.
Wir haben 1M Datensätze mit folgenden Spalten eingefügt: ID (int), Status (int), Nachricht (140 Zeichen, zufällig). Alle Tests wurden mit C ++ Treiber auf einem Desktop PC i5 mit 500 GB Sata Disk durchgeführt.
Benchmark mit MongoDB :
1M Datensätze Fügen Sie ohne Index
ein %Vor%1M-Datensätze Fügen Sie mit Index in die ID
ein %Vor%Als nächstes fügen wir 1M Datensätze zu derselben Tabelle mit Index- und 1M-Datensätzen hinzu
%Vor%das alles ergibt fast 4 GB Dateien auf fs.
Benchmark mit MySQL :
1M Datensätze Fügen Sie ohne Index
ein %Vor%1M Datensätze Fügen Sie mit Index
ein %Vor%Als nächstes fügen wir 1M Datensätze zu derselben Tabelle mit Index- und 1M-Datensätzen hinzu
%Vor%genau die gleiche Leistung, kein Verlust auf MySQL auf das Wachstum
Wir sehen, dass Mongo während dieses Tests 384 MB Ram verbraucht hat und 3 Kerne der CPU geladen hat, MySQL war glücklich mit 14 MB und lädt nur 1 Kern.
Edorian war mit seinem Vorschlag auf dem richtigen Weg, ich werde noch mehr Benchmark machen und ich bin mir sicher, dass wir auf einem 2x Quad Core Server 50K Inserts / sec erreichen können.
Ich denke, MySQL wird der richtige Weg sein.
es wird nur aus rechtlichen Gründen gespeichert.
Und was ist mit den detaillierten Anforderungen? Sie erwähnen die NoSQL-Lösungen, aber diese können nicht versprechen, dass die Daten wirklich auf der Festplatte gespeichert sind. In PostgreSQL ist alles transaktionssicher, so dass Sie 100% sicher sind, dass die Daten auf dem Datenträger sind und verfügbar sind. (nur nicht fsync)
Geschwindigkeit hat viel mit Ihrer Hardware, Ihrer Konfiguration und Ihrer Anwendung zu tun. PostgreSQL kann Tausende von Datensätzen pro Sekunde auf guter Hardware und mit einer korrekten Konfiguration einfügen, es kann mühsam langsam sein, die gleiche Hardware zu verwenden, aber eine einfache dumme Konfiguration und / oder den falschen Ansatz in Ihrer Anwendung zu verwenden. Ein einzelnes INSERT ist langsam, viele INSERTs in einer einzigen Transaktion sind viel schneller, vorbereitete Anweisungen noch schneller und COPY macht Magie, wenn Sie Geschwindigkeit brauchen. Es liegt an dir.
Ich weiß nicht, warum Sie MySQL ausschließen würden. Es könnte hohe Einsätze pro Sekunde verarbeiten. Wenn Sie wirklich hohe Einfügungen wünschen, verwenden Sie den Tabellentyp BLACK HOLE mit Replikation. Es wird im Wesentlichen in eine Protokolldatei geschrieben, die schließlich in eine reguläre Datenbanktabelle repliziert wird. Sie können den Slave sogar abfragen, ohne die Geschwindigkeit des Einlegens zu beeinflussen.
Abhängig von Ihrer Systemeinstellung kann MySql problemlos über 50.000 Einsätze pro Sekunde verarbeiten.
Für Tests an einem aktuellen System, an dem ich gerade arbeite, kamen wir auf über 200.000 Einsätze pro Sekunde. mit 100 gleichzeitigen Verbindungen auf 10 Tabellen (nur einige Werte).
Ich sage nicht, dass dies die beste Wahl ist, da andere Systeme wie Couch die Replikation / Backups / Skalierung einfacher machen können, aber mysql nur aufgrund der Tatsache ablehnen, dass es nicht so geringe Datenmengen verarbeiten kann. p>
Ich denke, es gibt bessere Lösungen (lesen: billiger, einfacher zu verwalten) Lösungen da draußen.
Firebird kann problemlos 5000 Insert / sec verarbeiten, wenn die Tabelle keine Indizes hat.
Ich würde die Protokolldatei dafür verwenden, aber wenn Sie eine Datenbank verwenden müssen, empfehle ich Firebird . Ich habe gerade die Geschwindigkeit getestet, es fügt ungefähr 10.000 Datensätze pro Sekunde auf ziemlich durchschnittlicher Hardware ein (3 Jahre alter Desktop-Computer). Die Tabelle hat einen zusammengesetzten Index, also würde es ohne es noch schneller funktionieren:
%Vor%Firebird ist Open Source und auch für kommerzielle Projekte völlig kostenlos.
Ich glaube, dass die Antwort auch vom Festplatten-Typ (SSD oder nicht) und der Größe der Daten abhängt, die Sie einfügen. Ich habe ein einzelnes Feld Daten in MongoDB auf einem Dual-Core-Ubuntu-Rechner und schlug über 100 Datensätze pro Sekunde. Ich habe einige ziemlich große Daten in ein Feld eingeführt und es fiel auf ungefähr 9ps und die CPU lief bei ungefähr 175%! Die Box hat keine SSD und ich frage mich, ob ich damit besser geworden wäre.
Ich habe auch MySQL ausgeführt und es dauerte 50 Sekunden, um 50 Datensätze in eine Tabelle mit 20 Mio. Datensätzen einzufügen (mit etwa 4 anständigen Indizes), so wie bei MySQL hängt es auch davon ab, wie viele Indizes Sie haben.
Tags und Links mysql sqlite postgresql mongodb