Die Verwendung einer Datenbank nur zur Datenspeicherung entspricht dem Aufrufen von Unix als Schnittstelle für die Arbeit mit Dateien. Daher möchte ich Sie an die bekannten und nicht sehr Datenbankfunktionen erinnern, die ich in webbasierten Kampfanwendungen häufiger sehen möchte.
tl; dr
Im Folgenden werden Authentifizierung, Benutzer, Zugriffsrechte, Datenintegrität, FDW, Protokollierung und Statistiken beschrieben. Nichts Neues.
Anmerkungen
- Ich meine Ruby on Rails und Postgres, aber die meisten Referenzen werden in anderen Sprachen und DBMS gut vertragen.
- Ich werde nichts Neues sagen, all dies wurde lange in der Dokumentation und den Artikeln beschrieben. Ich möchte nur noch einmal daran erinnern, wo die Werkzeuge eingesetzt werden können, um das Leben ein wenig besser zu machen.
Peer / Ident-Authentifizierung
Absolut gesunde Sache, die fast niemand benutzt. Es ordnet einen Unix-Benutzer einem Datenbankbenutzer zu. Im ersten Fall wird der lokale Benutzer und im zweiten Fall der Remote-Benutzer zugeordnet. Der Vorteil ist, dass Sie den Host, den Benutzernamen und das Kennwort aus der Konfiguration entfernen können (und der Datenbankname kann auch gelöscht werden), aber alles funktioniert wie zuvor. Außerdem ist es bequemer, zum direkten Debuggen in die Konsole zu gehen (nur psql vom Terminal aus statt all dieser -h -U -W -d usw.).
PG-Dokumentation zu Peer und Ident .
Nuancen: geeignet, wenn Sie nicht nur root und superuser auf dem Server haben; und im Fall von ident steuern Sie das Netzwerk, die Hardware und sind sicher, dass es keine Eindringlinge und Saboteure gibt.
Anwendungsbeispiele
Sicherheit Sie können das Kennwort nicht aus der Datenbank entfernen und von der lokalen Umgebung oder von einer anderen Stelle aus eine Verbindung herstellen. Es gibt kein Passwort und es gibt nichts zu ziehen.
Zugangskontrolle. Wenn es mehrere Zugriffsrollen für die Produktion oder einen anderen Server gibt und diese bereits auf Unix-Ebene aufgeteilt sind, ist es zweckmäßig, Datenbankbenutzer an diese zu binden. In diesem Fall wird dieselbe Codebasis unter verschiedenen Datenbankbenutzern verbunden. Zum Beispiel klettern technischer Support und Entwickler in dieselbe Rails-Konsole, aber für einige ist es schreibgeschützt und für die zweite ist es vollwertig.
Zugangsrechte
In Unix denken alle an sie und sie sehen sehr verzerrt aus 'chmod 777' sie von root oder 'chmod 777' . Aber in der Datenbank ist alles irgendwie anders. Superuser und los. Obwohl alles dort nicht weniger (und vielleicht sogar mehr) cool ist.
Es gibt eine Hierarchie der Rollenvererbung (ein bisschen wie eine Gruppe in Unix), es gibt Zugriffe auf verschiedenen Ebenen: auf bestimmte Objekte (wie Dateiberechtigungen), auf bestimmte Operatoren (wie Regeln in sudoers ), sogar auf bestimmte Zeilen . Kurz gesagt, alles ist da. Verwenden Sie es.
Anwendungsbereiche
In der Mindestversion können Sie zusammen mit dem oben genannten Peer / Ident den Benutzer für Migrationen / Bereitstellung und den Benutzer für den täglichen Betrieb der Anwendung trennen. Dies schützt zumindest zur Laufzeit vor DDL- Aufrufen. Natürlich gibt es viele Fälle, in denen die Datenbankstruktur "on hot" geändert wird. Hierbei handelt es sich um Bereitstellungen ohne Ausfallzeiten und verschiedene Hotfixes sowie um die gleichzeitige (und manchmal auch nicht) Wiederherstellung von Indizes. Im Allgemeinen sollte eine DDL-Anwendung dies jedoch nicht tun.
Eine weitere Option: Wenn Sie über "Microservices" verfügen, diese jedoch aus irgendeinem Grund dieselbe Datenbank verwenden, ist es eine sehr gute Idee, den Zugriff auf die Datenbankobjekte eindeutig zu teilen. In der Tat sollten die Interaktionsschnittstellen so lokal wie möglich sein, und der anarchische Zugriff auf alle Daten trägt zur Erosion von Logik und Verantwortung bei.
Integritätsbeschränkung
In Rails 5 begann die Arbeit zumindest irgendwie mit Referenz und Datenintegrität. Im Allgemeinen glauben viele Entwickler jedoch, dass die Validierung im Modell oder in seiner Umgebung ausreicht, um den konsistenten Status der Daten beizubehalten. Leider ist das überhaupt nicht wahr.
Überprüfungen können übersprungen werden, Sie können direkt zur Datenbank gehen und SQL ausführen, Sie können während der Migration aufwischen. Im Allgemeinen kann viel getan werden. Daher sollte alles, was auf Geschäftslogik beruht, von der Datenbank erfasst werden. Dies ist die einzige Möglichkeit, die Datenintegrität zu erhalten und bei der nächsten Bereitstellung keine "Überraschungen" zu erleben.
Wrapper für fremde Daten
Hier geht es darum, eine Datenbank mit einer anderen Datenbank zu verbinden, um auf eigene Remote-Tabellen zuzugreifen. Der Hauptgewinn besteht darin, dass die Webanwendung in keiner Weise beteiligt ist. Es gibt jedoch viele Optimierungen, wenn zwei identische Datenbanken funktionieren (Pushdown ist im Allgemeinen für verschiedene Adapter vorgesehen, aber dort ist alles kompliziert, sodass leichter davon ausgegangen werden kann, dass das PG-PG-Bundle gut funktioniert. und alles andere - wie es geht).
FDW verwenden
Anstatt mit den Koordinaten mehrerer Datenbanken in einer Webanwendung zu konfigurieren, ist es unvergleichlich einfacher, eine Verbindung zur Datenbank zu belassen und alles auf Datenbankebene zu verwalten. Dort wird das Problem der Zugriffsrechte und der Auswahl der Objekte, auf die zugegriffen werden muss, gelöst.
Außerdem können Sie in Zukunft die externe Tabelle durch eine materialisierte Ansicht oder nur eine Tabelle ersetzen, aber in einer Webanwendung nichts ändern.
Sie können sich jedoch mit dem exotischen Typ von MS Access verbinden, und die Probleme mit Einschränkungen bei der Verwendung von Beziehungen in Modellen verschwinden. Wenn Sie über 2+ Verbindungen verfügen, werden Sie auf Webanwendungsebene keine zwei Basen verbinden, obwohl ORM (insbesondere ActiveRecord) dies ehrlich versucht ... und abfällt. Auf Datenbankebene kann dies in einigen Fällen fast ohne Overhead erfolgen.
Protokollierung
Fast jeder kennt ihn und nutzt alles. Aber nur für den Fall, lassen Sie mich daran erinnern: Zögern Sie nicht, lange Anfragen zu protokollieren. In PG ist es sofort ausgeschaltet. log_min_duration_statement . In Bezug auf seine Bedeutung gibt es viele Holivars und vielleicht stammeln sie mich, aber nehmen Sie sich zunächst ein paar Sekunden Zeit. Wenn Sie eine große Anwendung haben, ist es unwahrscheinlich, dass Sie sie lesen und selbst wissen, was zu tun ist. Wenn sie jedoch klein ist, haben Sie keine Zeit, sich mit kleinen Bremsen zu befassen, und nur tödliche Dinge stören Sie.
Denken Sie auch an N + 1. Die Datenbank sagt nichts darüber aus. Verwenden Sie Tools von Drittanbietern. Zum Beispiel Kugel und gesunder Menschenverstand.
Statistiken
Es muss daran erinnert werden, dass es ist und dass es stinken kann. Zunächst ist alles in Ordnung. Im Laufe der Zeit ergeben sich jedoch normalerweise die folgenden Ergebnisse: Die Änderungsrate der Daten ist ungefähr gleich und die Größe der Tabelle ist größer. Folglich treten die Vakuum- / Analysetabellen seltener auf und irgendwann beginnt der Scheduler zu verfehlen. Im besten Fall fällt die Anfrage in die oben genannte Protokollierung, im schlimmsten Fall - Sie leiden einfach und verstehen nicht warum. Schauen Sie im Allgemeinen in pg_stat_user_tables und korrelieren Sie die Vakuum- / Analysedaten mit der Belastung der Tabellen.
Und manchmal können Sie Statistiken für eine ungefähre count . Es ist selten praktisch, aber sehr treffend, da PG nicht Oracle ist und die count für die gesamte Tabelle nicht in O (1) erfolgt, obwohl ich es wirklich möchte.
Das Ende
Danke fürs Lesen. Wenn es nicht schwierig ist, beantworten Sie die folgende Frage. Angesichts eines kürzlich erschienenen Artikels über GQL anstelle von SQL hat es mich sehr gestört .