Was ist der Sinn mehrerer Redis-Datenbanken?

Also bin ich an einen Ort gekommen, an dem ich die in redis gespeicherten Daten in separate Datenbanken segmentieren wollte, da ich manchmal den Befehl keys für eine bestimmte Art von Daten verwenden muss, und ihn trennen wollte, um dies zu beschleunigen .

Wenn ich in mehrere Datenbanken segmentiere, ist immer noch alles Single-Threaded und ich kann immer noch nur einen Kern verwenden. Wenn ich nur eine weitere Instanz von Redis auf derselben Box starte, kann ich einen zusätzlichen Kern verwenden. Darüber hinaus kann ich Redis-Datenbanken nicht benennen oder ihnen eine logischere Kennung geben. Warum / wann sollte ich nach alledem jemals mehrere Redis-Datenbanken verwenden wollen, anstatt nur eine zusätzliche Redis-Instanz für jede zusätzliche Datenbank zu starten, die ich möchte? Und warum versucht Redis nicht, für jede zusätzliche Datenbank, die ich hinzufüge, einen zusätzlichen Kern zu verwenden? Was ist der Vorteil eines Single-Threads über Datenbanken hinweg?

Im Prinzip unterscheiden sich Redis-Datenbanken auf derselben Instanz nicht von Schemas in RDBMS-Datenbankinstanzen.

Warum / wann sollte ich nach alledem jemals mehrere Redis-Datenbanken verwenden wollen, anstatt nur eine zusätzliche Redis-Instanz für jede zusätzliche Datenbank zu starten, die ich möchte?

Es gibt einen klaren Vorteil, Redis-Datenbanken in derselben Redis-Instanz zu verwenden, und das ist die Verwaltung. Wenn Sie für jede Anwendung eine separate Instanz starten und beispielsweise 3 Apps haben, sind dies 3 separate Redis-Instanzen, von denen jede wahrscheinlich einen Slave für HA in der Produktion benötigt. Das sind also insgesamt 6 Instanzen. Vom Management-Standpunkt aus wird dies sehr schnell chaotisch, da Sie alle überwachen, Upgrades / Patches usw. durchführen müssen. Wenn Sie nicht vorhaben, Redis mit hoher E / A zu überladen, ist eine einzelne Instanz mit einem Slave einfacher und einfacher Einfacher zu verwalten, sofern es Ihrem SLA entspricht.

Sie möchten nicht mehrere Datenbanken in einer einzigen Redis-Instanz verwenden. Es ist veraltet und wie Sie bereits bemerkt haben, können Sie mit mehreren Instanzen mehrere Kerne nutzen. Wenn Sie die Datenbankauswahl verwenden, müssen Sie beim Upgrade eine Umgestaltung vornehmen. Das Überwachen und Verwalten mehrerer Instanzen ist weder schwierig noch schmerzhaft.

In der Tat würden Sie durch Trennung nach Instanz weitaus bessere Metriken für jede Datenbank erhalten. Jede Instanz würde Statistiken haben, die dieses Datensegment widerspiegeln, was eine bessere Abstimmung und eine reaktionsschnellere und genauere Überwachung ermöglichen kann. Verwenden Sie eine aktuelle Version und trennen Sie Ihre Daten nach Instanzen.

Verwenden Sie nicht den Befehl keys, wie Jonaton sagte. Sie erzielen eine weitaus bessere Leistung, wenn Sie einfach einen Schlüsselindex erstellen. Fügen Sie beim Hinzufügen eines Schlüssels den Schlüsselnamen zu einem Satz hinzu. Der Befehl keys ist nach dem Skalieren nicht besonders nützlich, da die Rückkehr einige Zeit in Anspruch nimmt.

Lassen Sie das Zugriffsmuster bestimmen, wie Sie Ihre Daten strukturieren, anstatt sie so zu speichern, wie Sie denken, und arbeiten Sie dann daran, wie Sie später darauf zugreifen und sie zerkleinern können. Sie werden eine weitaus bessere Leistung feststellen und feststellen, dass der datenverbrauchende Code häufig viel sauberer und einfacher ist.

Beachten Sie bei Single Threaded, dass Redis auf Geschwindigkeit und Atomizität ausgelegt ist. Sicher, dass Aktionen, die Daten in einer Datenbank ändern, nicht auf eine andere Datenbank warten müssen, aber was ist, wenn diese Aktion in der Speicherauszugsdatei gespeichert oder Transaktionen auf Slaves verarbeitet werden? An diesem Punkt beginnen Sie mit dem Unkraut der Parallelitätsprogrammierung.

Durch die Verwendung mehrerer Instanzen verwandeln Sie die Komplexität von Multithreading in ein einfacheres System zur Weitergabe von Nachrichten.

Selbst Salvatore Sanfilippo (Erfinder von Redis) hält es für eine schlechte Idee, mehrere DBs in Redis zu verwenden. Siehe seinen Kommentar hier:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

Ich verstehe, wie nützlich dies sein kann, aber leider betrachte ich Redis mehrere Datenbankfehler als meine schlimmste Entscheidung im Redis-Design überhaupt ... ohne wirklichen Gewinn macht es die Interna viel komplexer. Die Realität ist, dass Datenbanken aus einer Reihe von Gründen nicht gut skaliert werden können, z. B. durch aktives Ablaufen von Schlüsseln und VM. Wenn die DB-Auswahl mit einer Zeichenfolge durchgeführt werden kann, kann ich sehen, dass diese Funktion als skalierbare O (1) -Wörterbuchschicht verwendet wird, dies ist jedoch nicht der Fall.

Mit DB-Nummern, mit einem Standardwert von einigen DBs, können wir besser kommunizieren, was diese Funktion ist und wie sie verwendet werden kann. Ich hoffe, dass wir irgendwann die Unterstützung für mehrere DBs überhaupt einstellen können, aber ich denke, es ist wahrscheinlich zu spät, da sich einige Leute bei ihrer Arbeit auf diese Funktion verlassen.

1. Ich kenne keine wirklichen Vorteile, wenn mehrere Datenbanken in einer einzigen Instanz vorhanden sind. Ich denke, es ist nützlich, wenn mehrere Dienste denselben Datenbankserver verwenden, um Schlüsselkollisionen zu vermeiden.

2. Ich würde nicht empfehlen, mit dem KEYSBefehl herum aufzubauen , da es O (n) ist und das nicht gut skaliert. Wofür verwenden Sie es, das Sie auf andere Weise erreichen können? Vielleicht passt Redis nicht am besten zu Ihnen, wenn Funktionen wie diese von KEYSentscheidender Bedeutung sind.

3. Ich denke, sie erwähnen die Vorteile eines einzelnen Thread-Servers in ihren FAQ, aber die Hauptsache ist die Einfachheit - Sie müssen sich nicht wirklich mit Parallelität beschäftigen. Jede Aktion wird blockiert, sodass keine zwei Dinge gleichzeitig die Datenbank ändern können. Idealerweise haben Sie eine (oder mehrere) Instanzen pro Kern jedes Servers und verwenden einen konsistenten Hashing-Algorithmus (oder einen Proxy), um die Schlüssel unter ihnen aufzuteilen. Natürlich verlieren Sie einige Funktionen - Piping funktioniert nur für Dinge auf demselben Server, Sortierungen werden schwieriger usw.

Ich verwende Redis zum Implementieren einer Blacklist mit E-Mail-Adressen, und ich habe unterschiedliche TTL-Werte für unterschiedliche Blacklisting-Ebenen. Daher hilft es mir sehr, unterschiedliche DBs auf derselben Instanz zu haben.

Redis-Datenbanken können in den seltenen Fällen der Bereitstellung einer neuen Version der Anwendung verwendet werden, in denen die neue Version die Arbeit mit verschiedenen Entitäten erfordert.

Die Verwendung mehrerer Datenbanken in einer einzelnen Instanz kann im folgenden Szenario hilfreich sein:

Verschiedene Kopien derselben Datenbank können für die Produktion, Entwicklung oder das Testen unter Verwendung von Echtzeitdaten verwendet werden. Benutzer können Replikate verwenden, um eine Redis-Instanz zu klonen, um denselben Zweck zu erreichen. Der erstere Ansatz ist jedoch für vorhandene laufende Programme einfacher, nur die richtige Datenbank auszuwählen, um in den beabsichtigten Modus zu wechseln.

Ich weiß, dass diese Frage Jahre alt ist, aber es gibt noch einen weiteren Grund, warum mehrere Datenbanken nützlich sein können.

Wenn Sie einen "Cloud Redis" von Ihrem bevorzugten Cloud-Anbieter verwenden, haben Sie wahrscheinlich eine minimale Speichergröße und zahlen für das, was Sie zuweisen. Wenn Ihr Datensatz jedoch kleiner ist, verschwenden Sie ein wenig von der Zuordnung und damit ein bisschen Geld.

Mithilfe von Datenbanken können Sie dieselbe Redis-Cloud-Instanz verwenden, um Dienste für (z. B.) Entwickler, UAT und Produktion oder für mehrere Instanzen Ihrer Anwendung oder was auch immer bereitzustellen. Wirksam.

Ein Anwendungsfall, den ich betrachte, enthält mehrere Instanzen einer Anwendung, die jeweils 200 bis 300 KB verwenden. Die Mindestzuweisung für meinen Cloud-Anbieter beträgt jedoch 1 Million. Wir können 10 Instanzen auf einem einzelnen Redis konsolidieren, ohne wirklich irgendwelche Einschränkungen vorzunehmen, und so etwa 90% der Redis-Hosting-Kosten einsparen. Ich schätze, dass dieser Ansatz Einschränkungen und Probleme aufweist, hielt ihn jedoch für erwähnenswert.