Redis ist ein erweiterter Schlüsselwertspeicher. Tatsächlich ist es der Key-Value-Store Nummer eins und die achtbeliebteste Datenbank der Welt. Es hat einen hohen Durchsatz und wird aus dem Speicher ausgeführt, hat aber auch die Fähigkeit, Daten auf der Festplatte zu speichern. Redis ist eine großartige Caching-Lösung für sehr anspruchsvolle Anwendungen, und es stehen viele Lösungen zur Verfügung, die Ihnen bei der Bereitstellung und Verwaltung von Redis in der Cloud helfen. In diesem Beitrag vergleichen wir die Leistungs- und Verwaltungsfunktionen von ScaleGrid for Redis™ mit denen von Azure Cache for Redis, um Ihnen bei der Auswahl der am besten verwalteten Lösung für Ihre Redis-Bereitstellung zu helfen.
ScaleGrid ist ein DBaaS-Anbieter, der vollständig verwaltetes Hosting nicht nur für Redis™, sondern auch für die MongoDB®-Datenbank, MySQL und PostgreSQL bereitstellt. Der Plan Bring Your Own Cloud (BYOC) hostet den Datenbankserver in Ihrem eigenen AWS-, Azure- oder GCP-Konto.
Azure bietet einen gehosteten Dienst für Redis namens Azure Cache for Redis.
Auf einen Blick – TLDR | ||||||
|---|---|---|---|---|---|---|
|
ScaleGrid for Redis™ vs. Azure Cache for Redis Performance Benchmark
In diesem Benchmark messen wir die Leistung in Durchsatz und Latenz. Der Durchsatz wird in Operationen pro Sekunde (ops/s) und die Latenz in Mikrosekunden gemessen. Sehen Sie sich unseren Abschnitt Benchmark-Konfigurationen später in diesem Beitrag an, um Informationen darüber zu erhalten, wie dieser Leistungsbenchmark konfiguriert wurde.
Wir haben die Leistung von Redis™ mit den folgenden Setups verglichen.
| Anbieter | Plan Size | RAM | Monatliche Kosten |
|---|---|---|---|
| ScaleGrid für Redis™ | Dedicated Hosting Large auf Azure | 7 GB Speicher | $607 |
| Azure Cache for Redis | C3 Standard – Mittlere Netzwerkbandbreite | 6 GB Speicher | $328,50 |
| Azure Cache for Redis | P1 Premium – Mittlere Netzwerkbandbreite | 6 GB Speicher | $404,42 |
| Azure Cache for Redis | P2 Premium – Hohe Netzwerkbandbreite | 13 GB Speicher | $810,30 |
Durchsatzleistung
| Verbindungen | ScaleGrid for Redis™ | Azure Cache C3 Std. 6 GB | Azure Cache P1 6GB | Azure Cache P2 13GB | ScaleGrid-Verbesserung |
|---|---|---|---|---|---|
| 100 | 134.667 | 16.461 | 19.881 | 38.459 | 439 % |
| 200 | 147.551 | 16.246 | 25.361 | 35.459 | 474 % |
| 300 | 152.341 | 15.872 | 25.346 | 35.045 | 499 % |
| 400 | 152.624 | 15.235 | 19.043 | 37.301 | 539 % |
| Wie wir in der obigen Grafik sehen können, erreicht ScaleGrid for Redis™ einen etwa fünfmal höheren Durchsatz im Vergleich zu Azure Cache for Redis bei einem Benchmarking mit 100–400 Verbindungen. Während beispielsweise der Tarif Azure Cache for Redis P2 Premium mit 13 GB rund 36.000 Operationen/Sek. in allen Verbindungsszenarien verwaltet, hat ScaleGrid for Redis™ über 130.000 Operationen/Sek. für alle Szenarien. |
Latenzleistung
| Verbindungen | ScaleGrid for Redis™ | Azure Cache C3 Std. 6 GB | Azure Cache P1 6GB | Azure Cache P2 13GB | ScaleGrid-Verbesserung |
|---|---|---|---|---|---|
| 100 | 744 | 6.809 | 5.896 | 2.497 | -85 % |
| 200 | 1.353 | 10.950 | 8.447 | 5.565 | -84 % |
| 300 | 2.044 | 17.807 | 13.045 | 8.539 | -84 % |
| 400 | 2.609 | 25.126 | 16.999 | 10.716 | -85 % |
| Während die Latenz von Azure Cache for Redis mit zunehmender Anzahl von Verbindungen schnell ansteigt, erreicht ScaleGrid for Redis™ durchgehend eine niedrige Latenz Verbindung zählt. Im Durchschnitt hat ScaleGrid for Redis™ eine um 85 % geringere Latenz als Azure Cache for Redis. Dies macht sich besonders beim Vergleich von Azure Cache for Redis (C3 Standard 6 GB) mit ScaleGrid for Redis™ bemerkbar, wo der Unterschied bis zu -99 % beträgt. |
Benchmark-Zusammenfassung
Wie Sie den obigen Diagrammen entnehmen können, bietet ScaleGrid for Redis™ einen deutlich höheren Durchsatz und eine geringere Latenz. Im Durchschnitt sehen wir etwa den 5-fachen Durchsatz und eine um 85 % niedrigere Latenz im Vergleich zu entsprechenden Größen in Azure Cache. Der ScaleGrid for Redis™ BYOC-Plan beginnt bei 9 $ pro Monat (720 Std. + VM-Kosten) und 18 $ pro Monat (720 Std.) für den Dedicated-Hosting-Plan.
|
Benchmark-Konfiguration
Werfen wir einen Blick auf die Konfigurationen, die wir im Leistungsbenchmark verwendet haben:
| Konfiguration | Details |
|---|---|
| Benchmark-Tool | Memtier-Benchmark |
| Azure-Region für Redis | USA, Osten |
| Azure-Region für Anwendung | USA, Osten |
| Bereitstellungstyp | Master-Slave |
Für jeden Redis™-Server haben wir Benchmarks mit 100, 200, 300 und 400 Verbindungen durchgeführt. Jede Verbindung sendet 10.000 Anfragen mit einer Objektdatengröße von 32 Byte pro Anfrage. Wir verwenden Nicht-SSL-Verbindungen, um Redis™-Server zu verbinden.
ScaleGrid kann nicht nur einen höheren Durchsatz und eine geringere Latenz bieten, es bietet auch viele andere Funktionen wie vollen Administratorzugriff, geplante Sicherungen und SSH-Zugriff. Weitere Informationen zu ScaleGrid for Redis™ auf Azure finden Sie auf unserer Website.
Was ist bei der Auswahl eines Redis™-Dienstes zu beachten?
Was sind also bei so vielen vollständig verwalteten Optionen für Redis™-Dienstanbieter die wichtigsten Funktionen, auf die Sie achten sollten? Hier ist eine Checkliste, die Sie bei der Auswahl des richtigen Redis-Hosting-Dienstes für sich verwenden können:
- Dedizierter Server
- Skalierbarkeit
- Datenpersistenz
- Sicherungen und Wiederherstellungen
- Hoher Durchsatz und niedrige Latenz
Dedizierter Server
Redis ist ein Singlethread-Server, auf dem Daten im Arbeitsspeicher gespeichert werden; Daher ist es in einer Produktionsumgebung sehr wichtig, Redis auf einem dedizierten Server auszuführen. Sie möchten nicht, dass Ihr Redis-Server mit anderen Diensten um CPU- und Speicherressourcen kämpft.
Skalierbarkeit
Unternehmen wachsen und das Gleiche gilt für Ihre Daten. Es ist sehr wichtig, dass Ihr Redis-Dienst in der Lage ist, eine dynamische, direkte Skalierung Ihres Redis-Servers mit wenig oder gar keinen Ausfallzeiten durchzuführen.
Datenpersistenz
Abhängig von Ihren geschäftlichen Anforderungen müssen Sie Ihre Redis-Daten möglicherweise auf einem physischen Speicher speichern. Redis bietet zwei Persistenzoptionen:RDB und AOF.
RDB ist ein Point-in-Time-Snapshot Ihres Datensatzes in festgelegten Intervallen in einer Sicherungsdatei der Redis-Datenbank. Die Datei kann auf andere Redis-Instanzen übertragen werden.
AOF steht für Append Only File. Redis protokolliert jeden Schreibvorgang, der in Ihrem Dataset geändert wurde. Es ist eine sehr zuverlässige Möglichkeit, Ihre Daten zu speichern.
Sowohl RDB als auch AOF können gleichzeitig aktiviert werden und haben unterschiedliche Kompromisse. Weitere Einzelheiten zu ihren Vor- und Nachteilen finden Sie auf der Redis Persistence-Seite auf redis.io.
Ihr Redis-Dienst sollte nicht nur Optionen zum Beibehalten der Daten, sondern auch zum Bereitstellen von Redis im Master-/Replikat- oder Cluster-Modus bieten, um das Risiko eines Datenverlusts zu minimieren.
Sicherungen und Wiederherstellungen
Jede Database as a Service (DBaaS) für Redis sollte auch geplante und On-Demand-Sicherungen bereitstellen, damit Sie sicherstellen können, dass Sie immer einen regelmäßigen Zeitplan für Sicherungen zur Verfügung haben und diese durchführen können nach Bedarf vor einer Bewerbungsveranstaltung. Es sollte auch Optionen zum „Wiederherstellen von Backups“ für vorhandene Datenbanken oder für eine neue Datenbankinstanz bereitstellen.
Hoher Durchsatz und niedrige Latenz
Redis kann schnelles Caching für Anwendungen bereitstellen. Manchmal kann die Netzwerklatenz jedoch den Zugriff auf Daten von Redis behindern. Der Schlüssel liegt darin, physische Distanzierung zwischen Ihrer Anwendung und Redis zu vermeiden. Sie möchten also sicherstellen, dass sowohl die Anwendung als auch Redis in derselben Cloudanbieterregion und in demselben virtuellen Netzwerk gehostet werden. Ihr Redis-Dienstanbieter sollte die Möglichkeit haben, Ihren Redis-Server im virtuellen Netzwerk Ihrer Wahl bereitzustellen.
