2016-08-18 2 views
4

Ich entwerfe eine interne Firmenwebsite, auf der Benutzer Jobs zur Berechnung einreichen können. Ein wichtiger Faktor in meinem Design ist es, den Job in der Warteschlange zu halten, bis er abgeschlossen ist, selbst wenn ein Systemfehler auftritt.Wann ist es sinnvoll, eine Datenbank für eine Jobwarteschlange zu verwenden?

Es scheint, dass das Internet gegen die Idee ist, da es "nicht wirklich der Zweck einer Datenbank" ist und besser für einen Schlüssel/Wertspeicher wie Redis geeignet ist (oder eine Jobwarteschlange, die Redis verwendet, wie Kue for Node). js). Ich denke, dass ich es in dem Sinne verstehe, dass der Zweck dieses Entwurfs darin besteht, die Datenbank nicht mit Lese-/Schreibvorgängen für ziemlich flüchtige Daten zu überlasten, wie sie in einer Jobwarteschlange vorkommen würden. In meinem Anwendungsfall wäre die Datenbanknutzung jedoch ziemlich niedrig und es scheint, dass die Persistenz von Daten, die eine Datenbank bietet, das Schlüsselmerkmal ist, nach dem ich hier suche.

In meiner Lesung habe ich festgestellt, dass einige Schlüssel/Wert speichert, wie Redis, eine persistente Funktion, aber es ist nicht wirklich gebaut, um sicherzustellen, dass alle Daten wiederhergestellt werden können, wenn das System ausfällt.

Fehle ich etwas hier oder klingt das richtig?

+0

Ich würde sagen, dass ich dem Internet darin zustimme, dass dies besser für ein "leichteres" Datenspeichersystem wie "redis" oder sogar "mongo" übrig bleibt. Meine Fragen wären A.) Benutzt das Unternehmen die DB bereits und wie oft? und B.) Wenn Sie es verwenden, wie viel Einfluss haben Sie auf seine Lese-/Schreibzeiten? – Derek

+0

Ich würde auch empfehlen 'rabbitmq'. – sobolevn

+0

Ich benutze Mongo für meine Datenbank, und nein, bis jetzt ist es nur meine Anwendung, die die Datenbank benutzt. Ich bin mir nicht sicher, welchen Einfluss das auf Lese-/Schreibzeiten haben würde. – Leif

Antwort

1

In meiner Lektüre habe ich festgestellt, dass einige Schlüssel/Wert-Speicher, wie Redis, hat eine Funktion bestehen bleiben, aber es ist nicht wirklich gebaut, um sicherzustellen, dass alle Daten erstattungsfähig, falls das System ausfällt.

In Redis werden Daten mit einem Hintergrundthread von Speicher zu Datenträger gespeichert. Tatsächlich wird ein Systemausfall Ihre Datenbank nicht beschädigen, aber das Problem besteht darin, dass ein System vor oder während eines Snapshots auf die Festplatte herunterfahren kann und Sie alle Daten verlieren, die nach dem letzten erfolgreichen Snapshot erstellt wurden.

Wenn Sie sicher sein können, dass Ihr Redis-Server in 99,9% der Fälle aktiv ist, ist dies kein großes Problem, aber das Problem besteht trotzdem.

Am Ende des Tages, mein bester Rat ist, sollten Sie das richtige Werkzeug für den Job verwenden: eine allgemeine Datenbank, entweder NoSQL oder SQL, ist nicht für Job Enqueueing gemacht. Verwenden Sie ein vorhandenes Tool, das es bereits wie RabbitMQ tut.

+0

Ich bin immer noch ein wenig beunruhigt über die Aussicht, JEDE Daten zu verlieren, selbst wenn der Server stabil ist und die Chance gering ist. Menschen in meiner Branche können ziemlich irritiert sein, wenn die Dinge nicht wie geplant laufen. Wäre es eine andere Option, die Job-Queue-Informationen in einer separaten Datenbank (selbst auf einem Remote-Server) zu speichern, damit die "gute" Datenbank mit dauerhaften Informationen, die langfristig zählen, nicht von der Job-Queue belastet wird? – Leif

+0

@Leif Nein, die Lösung verwendet eine zuverlässige Nachrichtenwarteschlange. Ich habe dich auf einen hingewiesen: RabbitMQ. Wenn Sie in Azure sind, ist Azure Service Bus auch sehr leistungsfähig. –

Verwandte Themen