Was gefällt Ihnen nicht? YugabyteDB?
Aktuelle Herausforderungen und Einschränkungen
Wir listen unten die kritischsten Probleme und Einschränkungen auf, die derzeit unsere YugabyteDB-Bereitstellung für die Iris-Anwendung beeinflussen:
1. DDL-Atomizität und -Konkurrenz
Gleichzeitige DDL auf verschiedenen Objekten schlägt oft fehl oder verursacht Schema-Mismatch-Fehler.
2. Truncate-Verhalten
Truncate-Operationen behalten alte Tablets bei, was zu Ressourcenverschwendung (CPU, Festplatte) führt.
3. Langsame Aggregationen / Analytische Abfragen
Aggregatfunktionen (z.B. COUNT, SUM, GROUP BY) haben eine schlechte Leistung bei großen Tabellen.
4. Große Abfragefehler
Abfragen schlagen mit RPC-Nachrichtengrößenfehlern fehl; Workarounds erfordern nicht-triviale gflag-Anpassungen.
5. Herausforderungen bei der Indexerstellung
Die Indexerstellung auf großen Tabellen ist langsam (kann Stunden dauern) und instabil, wenn DMLs ausgeführt werden.
Das Scheitern gleichzeitiger DDLs kann zu Anwendungsstillstand oder veralteten Ansichten führen.
6. Intermittierende Anwendungsträgheit
Während hoher Ingestionsfenster (z.B. Spark + C#-Clients) steigt die CPU-Auslastung auf 80–85%.
7. Langsame Abfragen trotz Indizierung
Schlechte Leistung, selbst bei korrekt gestalteten Indizes.
8. DR-Einschränkungen
DR erfordert symmetrischen 3-Knoten-Cluster und repliziert keine DDL—dies erhöht den manuellen Aufwand.
9. Knotenabstürze
Gelegentliche Abstürze aufgrund des pg_client_use_shared_memory-Bugs.
10. Ressourcennutzung
Maximal 1800 gleichzeitige Verbindungen über 6 Knoten (300/Knoten).
Hohe CPU-Auslastung (80%+) bei 5500 OPS und 1500+ Verbindungen.
11. PITR-Festplattennutzung
PITR mit 2-tägiger Aufbewahrung verbraucht 1–2 TB Festplattenspeicher.
Erwartetes Verhalten, aber der Speicheraufwand ist erheblich.
12. Audit-Logging
pgaudit verursacht Abstürze und es fehlt an zentralem Log-Management.
Bevorzugt werden Audit-Logs als abfragbare Tabellen gespeichert.
13. Tablet-Neuausgleich
Neuausgleich dauert 2–3 Stunden nach Knotenfehlern.
14. Schema-Name-Änderung nicht in der Benutzeroberfläche reflektiert
15. Abfrageleistungsüberwachung
Kein zentrales Abfragemetrik-Dashboard über Knoten hinweg.
pg_stat_statements ist pro Knoten; erfordert benutzerdefinierte Datenaggregation.
16. Mangel an ORM-Unterstützung
Prisma ORM fehlt native Yugabyte-Unterstützung.
Klarer Zeitplan für eine intelligente Treiberintegration wird noch benötigt.
17. Andere Probleme
Tote Tupel verursachen Transaktionsfehler.
Tserver-Abstürze aufgrund von Uhrzeitabweichungen.
Falsche Gesundheitsprüfungen führen zu Tabellenlöschvorfällen.
Backup auf S3 schlug aufgrund von Endpunktfehlkonfiguration fehl.
Empfehlungen & Erwartungen
Top-Prioritäten für kommende Releases:
Volle Unterstützung für gleichzeitige DDL/DML
Verbesserte Join- und Aggregationsleistung
Zentrales Abfragedashboard über das Universum
Audit-Log-Auslagerung und Zentralisierung
Intelligente Tablet-Neuausbalancierung und tabellenbezogene Wiederherstellung
Vereinfachte Backup/Restore-UX (insbesondere für S3)
Dokumentation und Benutzerfreundlichkeit:
Bessere Standards für leistungsbezogene gflags.
Klare Anleitung zu Best Practices für DDL-Koordination und Hochdurchsatz-Ingestion.
Support & Schulung:
Strukturiertere Schulung zur Abfrageoptimierung und Ressourcentuning
Roadmap-Transparenz für kritische Funktionen (z.B. Prisma ORM-Unterstützung)
Abschließende Gedanken
Wir schätzen die fortgesetzte Partnerschaft und Reaktionsfähigkeit von Yugabyte bei Problemen. Die Plattform zeigt großes Potenzial für OLTP-Workloads und geschäftskritische Bereitstellungen, aber es gibt klare Lücken—insbesondere bei den betrieblichen Werkzeugen, der Unterstützung analytischer Abfragen und der DDL-Konkurrenz—die wir hoffen, in der kurzfristigen Roadmap adressiert zu sehen.
Unser Team bleibt engagiert, mit Yugabyte zusammenzuarbeiten, um das Produkt zu verbessern, und freut sich auf weitere Leistungs- und Zuverlässigkeitsverbesserungen. Bewertung gesammelt von und auf G2.com gehostet.