Nicht sicher, ob es ein DBS gibt, und ob das tatsächlich ein nützliches Feature ist, aber: Es gibt eine Menge Vorschläge, wie DB-Operationen durch die Optimierung der Puffergrößen beschleunigt werden können. Ein Beispiel ist das Importieren von Open Street Map-Daten (die Planet-Datei) in eine Postgres-Instanz. Zu diesem Zweck gibt es ein Tool namens osm2pgsql (http://wiki.openstreetmap.org/wiki/Osm2pgsql) und eine Anleitung, die vorschlägt, spezifische Pufferparameter für diesen Zweck anzupassen. Im letzten Schritt des Imports erstellt die Datenbank Indizes und würde (nach meinem Verständnis beim Lesen der Dokumente) von einem großen maintenance_work_mem profitieren, während dies im normalen Betrieb nicht so nützlich wäre. Dieser Thread http://www.mail-archive.com/[email protected]/msg119245.html im Gegenteil schlägt vor, eine große Maintenance_work_mem würde nicht zu viel Sinn bei der endgültigen Indexerstellung machen. Idealerweise (imo) sollte der DBS am besten wissen, welche Puffergrößenkombination bei einer begrenzten Größe des gesamten Pufferspeichers am meisten profitieren könnte. Gibt es also gute Gründe, warum es keine integrierte Heuristik gibt, die die Puffergrößen automatisch an die aktuelle Aufgabe anpassen kann?Warum passt DBS seine Puffergrößen nicht automatisch an?
Antwort
Das Problem ist das gleiche wie bei jeder Prognosesoftware. Nur weil etwas historisch passiert, heißt das nicht, dass es wieder passieren wird. Außerdem müssen Sie eine Aufgabe ausführen, um vollständig zu analysieren, wie Sie effizienter arbeiten sollten. Das Problem ist, dass die nächste Aufgabe nicht unbedingt die zuvor abgeschlossene Aufgabe ist. Wenn Ihre Importroutine zum Beenden 8 GB Speicher benötigt, wäre es dann sinnvoll, jedem schreibgeschützten Benutzer 8 GB Speicher zuzuweisen? Umgekehrt würde es auch nicht gut gehen.
Wenn man diese Entscheidung dem Menschen überlässt, wird die Datenbank Leistungsmerkmale aufweisen, die nicht für alle Fälle optimal sind, aber im Gegenzug lassen wir (die Menschen) jeden Fall individuell optimieren (wenn gewünscht).
Ein weiterer wichtiger Aspekt ist, dass die meisten Menschen/Unternehmen zuverlässige und stabile Werte über unterschiedliche, aber potenziell bessere Niveaus schätzen. Hohe Kosten zu haben ist nicht so wichtig, wie große Kostenschwankungen. Dies ist natürlich nicht immer der Fall, da ganze Unternehmen darauf basieren, dass sie ab und zu 1% erreicht haben.
Moderne Datenbanken bemühen sich bereits, sich an die gestellten Aufgaben anzupassen, z. B. zunehmend leistungsfähigere Abfrageoptimierer.Zumindest hat Oracle die Möglichkeit, einige der Maßnahmen zu verfolgen, die die Entscheidungen des Optimierers beeinflussen (Kosten für das Lesen einzelner Blöcke, die mit der aktuellen Auslastung variieren).
Meine erraten wäre es furchtbar schwer, die Knöpfe durch adaptive Mittel richtig zu bekommen. Zuerst müssen Sie die Maschine nach vielen Unbekannten abfragen, wie viel RAM es zur Verfügung hat - aber auch das Unbekannte "was erwarten Sie, dass es auf der Maschine läuft".
dass Sperre, durch einen max_mem_usage Parametereinstellung nur, das Problem ist, wie man ein System zu machen, die
- gut passt sich die meisten typischen Belastungen.
- Keine seltsamen pathologischen Probleme mit einigen Lasten.
- ist einigermaßen verständlichen Code ohne Fehler.
Für postgresql jedoch die Antwort auch
- Niemand schrieb es noch, weil andere Dinge als wichtiger angesehen werden könnte.
- Sie hat es noch nicht geschrieben.