Utiliser une base de données uniquement pour le stockage de données revient à appeler Unix une interface pour travailler avec des fichiers. Par conséquent, je tiens à vous rappeler les fonctions de base de données bien connues et peu connues que j'aimerais voir plus souvent dans les applications de combat sur le Web.
tl; dr
Vous trouverez ci-dessous des informations sur l'authentification, les utilisateurs, les droits d'accès, l'intégrité des données, FDW, la journalisation et les statistiques. Rien de nouveau.
Remarques
- Je veux dire Ruby on Rails et Postgres, mais la plupart des références sont bien tolérées dans d'autres langues et SGBD.
- Je ne dirai rien de nouveau, tout cela a longtemps été décrit dans la documentation et les articles. Je veux juste rappeler encore une fois les outils et où ils peuvent être appliqués pour améliorer un peu la vie.
Authentification Peer / Ident
Chose absolument saine, que presque personne n'utilise. Il mappe un utilisateur Unix à un utilisateur de base de données. Dans le premier cas, l'utilisateur local est mappé et dans le second, l'utilisateur distant. Le bénéfice est que vous pouvez supprimer l'hôte, le nom d'utilisateur et le mot de passe de la configuration (et le nom de la base de données peut également être supprimé), mais tout fonctionnera comme avant. De plus, il sera plus pratique d'aller dans la console pour un débogage direct (juste psql depuis le terminal au lieu de tous ces -h -U -W -d et ainsi de suite).
Documentation PG sur peer et ident .
Nuances: adapté si vous n'avez pas seulement root et superutilisateur sur le serveur; et dans le cas d'ident, vous contrôlez le réseau, le matériel et êtes sûr qu'il n'y a pas d'intrus et de saboteurs.
Exemples d'utilisation
La sécurité Vous ne pouvez pas supprimer le mot de passe de la base de données et vous y connecter à partir de l'environnement local ou d'ailleurs. Il n'y a pas de mot de passe et il n'y a rien à faire glisser.
Contrôle d'accès. S'il existe plusieurs rôles d'accès à la production ou à un autre serveur et qu'ils sont déjà divisés au niveau Unix, il est pratique de leur associer des utilisateurs de base de données. Dans ce cas, la même base de code sera connectée sous différents utilisateurs de base de données. Par exemple, le support technique et les développeurs montent dans la même console de rails, mais pour certains, elle est en lecture seule, et pour la seconde, elle est à part entière.
Droits d'accès
Sous Unix, tout le monde pense à eux et ils ont l'air très biaisés de travailler à partir de root ou de 'chmod 777' . Mais dans la base de données, tout est en quelque sorte différent. Superutilisateur et c'est parti. Bien que tout y soit pas moins (et peut-être même plus) cool.
Il y a une hiérarchie d'héritage de rôle (un peu comme un groupe sous Unix), il y a des accès de différents niveaux: à des objets spécifiques (comme les permissions de fichier), à des opérateurs spécifiques (comme les règles dans sudoers ), même à des lignes spécifiques . Bref, tout est là. Utilisez-le.
Domaines d'application
Dans la version minimale, avec le pair / ident ci-dessus, vous pouvez séparer l'utilisateur pour les migrations / déployer et l'utilisateur pour le fonctionnement quotidien de l'application. Cela, au moins, protégera contre les appels DDL lors de l'exécution. Bien sûr, il existe de nombreux cas de modification de la structure de la base de données "à chaud". Il s'agit de déploiements sans interruption de service, de divers correctifs et de reconstructions d'index avec concurence (et parfois sans). Mais, en général, une application DDL ne devrait pas.
Une autre option: si vous avez des "microservices", mais pour une raison quelconque, ils utilisent la même base de données, alors partager clairement l'accès aux objets de la base de données est une très bonne idée. En effet, les interfaces d'interaction doivent être aussi localisées que possible, et l'accès anarchique à toutes les données contribue à l'érosion de la logique et de la responsabilité.
Contrainte d'intégrité
Dans Rails 5, du moins d'une manière ou d'une autre, le travail a commencé avec la référence et l'intégrité des données. Mais, dans le cas général, de nombreux développeurs estiment que la validation dans le modèle ou ses environs est suffisante pour préserver l'état cohérent des données. Hélas, ce n'est pas vrai du tout.
Les validations peuvent être ignorées, vous pouvez aller directement à la base de données et exécuter sql, vous pouvez éponger pendant la migration. En général, beaucoup peut être fait. Par conséquent, tout ce qui repose sur la logique métier doit être cloué par la base de données. C'est le seul moyen de préserver l'intégrité des données et de ne pas avoir de "surprises" lors du prochain déploiement.
Encapsuleur de données étranger
Il s'agit de connecter une base de données à une autre base de données afin d'accéder aux tables distantes comme les leurs. Le principal avantage est que l'application Web ne participe en aucune façon, mais il existe de nombreuses optimisations lorsque deux bases de données identiques fonctionnent (en général, le pushdown concerne différents adaptateurs, mais tout y est compliqué, il est donc plus facile de supposer que le bundle PG-PG fonctionne bien, et tout le reste - comment ça se passe).
Utilisation de FDW
Au lieu de configurer les coordonnées de plusieurs bases de données dans une application Web, il est incomparablement plus facile de laisser une connexion à la base de données et de tout gérer au niveau de la base de données. Là, en soi, la question des droits d'accès et le choix des objets auxquels l'accès est nécessaire seront résolus.
De plus, à l'avenir, vous pouvez remplacer la table externe par une vue matérialisée ou simplement une table, mais ne changez rien dans une application Web.
Et pourtant, vous pouvez vous connecter au type exotique de MS Access et les problèmes de restrictions sur l'utilisation des relations dans les modèles disparaissent. Après tout, si vous avez 2+ connexions, alors vous ne ferez pas la jonction de deux bases au niveau de l'application Web, bien que ORM (en particulier, ActiveRecord) essaiera honnêtement de le faire ... et tombera. Et au niveau de la base de données, cela peut être fait, dans certains cas, presque sans surcharge.
Journalisation
Presque tout le monde le connaît et utilise tout. Mais juste au cas où, permettez-moi de vous rappeler: n'hésitez pas à enregistrer de longues demandes. Hors de la boîte, en PG, c'est éteint. Besoin de piquer log_min_duration_statement . En ce qui concerne sa signification, il existe de nombreux holivars et, peut-être, ils me balbutient, mais pour commencer, mettez quelques secondes. Étant donné que si vous avez une application volumineuse, il est peu probable que vous la lisiez et que vous sachiez quoi faire, mais si elle est petite, vous n'avez pas le temps de gérer les petits freins et seules les choses fatales vous dérangent.
Souvenez-vous également de N + 1. La base de données n'en dira rien. Utilisez des outils tiers. Par exemple, balle et bon sens.
Statistiques
Il faut se rappeler qu'elle l'est et qu'elle peut puer. Au début, tout va bien. Mais au fil du temps, généralement, les résultats suivants: le taux de changement des données est à peu près le même, et la taille du tableau est plus grande. Par conséquent, les tables de vide / analyse commencent à se produire moins fréquemment et à un moment donné, l'ordonnanceur commence à manquer. Dans le meilleur des cas, la demande tombe dans la journalisation ci-dessus, dans le pire - vous souffrez simplement et vous ne comprenez pas pourquoi. En général, regardez dans pg_stat_user_tables et pg_stat_user_tables les dates de vide / analyse avec la charge sur les tables.
Et parfois, vous pouvez utiliser des statistiques pour un count approximatif. Cela est rarement utile, mais tout à fait à propos, car PG n'est pas Oracle et le count pour la table entière ne se fait pas dans O (1), bien que je le veuille vraiment.
La fin
Merci d'avoir lu. Si ce n'est pas difficile, répondez à la question ci-dessous. À la lumière d'un article récent sur GQL, au lieu de SQL, il a commencé à me déranger surtout.