Datenbankdesign für schreibintensive Webanwendungen

Question

Viele der LOB-Anwendungen, die wir unseren Kunden zur Verfügung stellen, haben einen Marketing-/Werbecharakter (Gewinnspiele, Veranstaltungsregistrierung, etc.). Die meisten dieser Anwendungen sind zwar sehr einfach, stellen aber sehr hohe Anforderungen an die Datenbank. Stellen Sie sich eine Website vom Typ "Registrierung" als Hintergrund für einen Werbespot vor, der beispielsweise während des Superbowls ausgestrahlt wird (ja, wir hatten schon mehrere).

Obwohl wir bei der Optimierung des Codes unserer Webanwendungen sehr gut geworden sind, bleibt die Datenbank immer ein Problem, obwohl die Anwendung relativ einfach ist. Der Ablauf ist typischerweise in etwa so:

1. Aus der Datenbank lesen, um vorhandene Datensätze zu erkennen
2. In die Datenbank schreiben, wenn der Datensatz neu ist

In vielen Fällen ist dies der einzige Datenzugriff, den unsere Anwendung durchführen muss. Da dies jedoch der einzige Zweck der Anwendung ist, ist es sehr wichtig, dass dieser einfache Prozess stark optimiert wird.

Für die Zwecke dieser Frage haben wir einen einzelnen Server mit einem Raid-5-Platten-Array für die Datendateien und einem weiteren Raid-5-Array für die Protokolle. Das Betriebssystem ist zur Zeit Windows 2003 Standard 32bit und der Server hat 4 GB Speicher. Einige Anwendungen verwenden SQL 2005 Standard, während andere MySQL 5.1 verwenden. Ich bin sehr bewusst Ich weiß, dass bestimmte Betriebssystem- und Hardware-Optimierungen hier möglich sind, aber ich möchte meine Bedürfnisse zuerst von der Software-Seite her angehen. Ausführliches Profiling hat uns gelehrt, dass Festplatten-IO ist im Allgemeinen der größte Engpass .

Nachdem ich all das gesagt habe und weiß, dass Caching nicht viel helfen wird, da die meisten Lesevorgänge einmalig sind und nur sehr wenige Daten zurückgeben (oft nur ein bisschen, das angibt, ob ein Datensatz existiert oder nicht), überlege ich, einen Sprung in den Bereich der In-Memory-Datenbanken als eine Art Schreib-Cache-Schicht für die echte Datenbank zu machen. Dies scheint eine gute Lösung zu sein, da der Großteil unseres hohen Datenaufkommens sporadischer Natur ist und sich nicht über mehrere Stunden hinzieht. Außerdem wäre der mögliche Verlust von ein paar Minuten an Daten aufgrund eines Serverabsturzes in den meisten Fällen akzeptabel.

In der einfachsten Form würde ich eine typische Registrierungsanwendung so ändern, dass sie Folgendes tut:

1. Abfrage der Festplatten-DB und der Speicher-DB nach vorhandenen Datensätzen
2. Wenn nicht, werden Daten in den Speicher-DB geschrieben und zurückgegeben
3. Regelmäßiges Flushen der Speicher-DB auf die Festplatten-DB

Meine Frage lautet Was sind meine Optionen für diese In-Memory-Datenbank? Ich habe mit In-Memory-Hashtabellen, Datentabellen und dergleichen experimentiert, aber ich bin auf der Suche nach anderen Optionen oder sogar Vorschläge für einen völlig anderen Ansatz.

Answer 1

Wenn Sie nicht wissen müssen, ob ein Datensatz in Echtzeit vorhanden ist (d. h. es ist wichtig, dass der Datensatz dort hinkommt, aber Sie müssen dem Benutzer nicht mitteilen, ob er neu oder vorhanden ist), können Sie Ihre Datenbank so strukturieren, dass extrem schnelle Schreibzeiten möglich sind, ohne dass eine In-Memory-Datenbank erforderlich ist, die eine Menge potenzieller Probleme mit sich bringt, wenn Server ausfallen oder Arbeitsprozesse neu starten.

Erstellen Sie in Ihrer Datenbank zwei Tabellen für jede Tabelle, die an diesem schreibintensiven Fluss beteiligt ist. Eine Tabelle sollte Ihre "Live"-Tabelle sein und so weit wie möglich schreiboptimiert sein (d.h. keine Indizes und es wird nie aus ihr gelesen, außer beim Wechsel zur Lesetabelle). Die andere Tabelle sollte Ihre leseoptimierte Tabelle sein - indiziert, wie es für die Berichterstattung erforderlich ist, usw.

Wenn Sie in Ihre Live-Tabelle schreiben, ignorieren Sie alles, was damit zu tun hat, ob ein Datensatz neu oder vorhanden ist, oder alles, was darüber hinausgeht, die Daten so schnell wie möglich in die Tabelle zu bringen und aus der DB zu entfernen. Richten Sie einen geplanten Job ein, der Datensätze aus der Live-Tabelle in die leseoptimierte Tabelle verschiebt, und kümmern Sie sich um den Abgleich der vorhandenen Datensätze. Idealerweise sollte dies zu Zeiten geschehen, in denen es keine Spitzenlast gibt, aber andernfalls sollten Sie eine dritte Staging-Tabelle in Betracht ziehen, damit die Live-Tabelle zu keiner Zeit belastet wird.

Answer 2

Machen Sie sich das neue Konzept "Alles ist eine Nachricht, die Datenbank ist die Sicherung" zu eigen. Wenn Sie etwas zu speichern haben, erstellen Sie eine Nachricht und senden Sie diese über XMPP an eine Blackbox (wie eJabberD). Lassen Sie die Blackbox Ihre Datenbank nach ihrem eigenen Zeitplan aktualisieren. So funktionieren Websites wie Twitter.

Schauen Sie sich diese Diashow an: http://www.slideshare.net/kellan/beyond-rest

Answer 3

Hier ist eine seltsame Idee: Verwenden Sie keine Datenbank für die Ersterfassung. Entwerfen Sie zwei oder drei rasend schnelle indizierte Dateien, deren Format sich nicht sehr oft ändern muss. Erfassen Sie die Daten in diesen Dateien.

Schreiben Sie eine Software, die in geeigneter Weise ausgelöst wird und die erfassten Daten in eine Datenbank kopiert, aber den interaktiven Benutzer nicht aufhält. Markieren Sie die kopierten Daten, um doppelte Kopien zu verhindern und Speicherplatz in der Datei zu recyceln.

Jetzt können Sie die Datenbank mit der Idee der gemeinsamen Nutzung von Daten für verschiedene Zwecke entwerfen, anstatt mit der Idee, mit dem Erfassungsprozess Schritt zu halten. Schließlich ist die gemeinsame Nutzung von Daten das, was Datenbanken wirklich auszeichnet.

Answer 4

Hat zwar nichts mit Programmieren zu tun, würde aber auf jeden Fall helfen: Besorgen Sie sich einige der neueren Solid State Disks.

Ja, sie sind teuer für die Größe, aber da die Festplatten-IO der Engpass ist, würde ein Austausch der aktuellen HDDs gegen SSDs die Leistung erheblich verbessern.

Answer 5

SQLite hat eine im Gedächtnis Betriebsart. Dies würde funktionieren, wenn Sie einen persistenten Serverprozess hinter Ihrem Page Hits Handler haben.

Andernfalls können reguläre dateibasierte DBs dazu verleitet werden, ihre Dateien in ein Speicher-Dateisystem zu schreiben, wie tmpfs .