Usar una base de datos solo para almacenamiento de datos es lo mismo que llamar a Unix como una interfaz para trabajar con archivos. Por lo tanto, quiero recordarles las funciones de base de datos conocidas y no muy conocidas que me gustaría ver con más frecuencia en las aplicaciones de combate basadas en la web.
tl; dr
A continuación se tratará sobre autenticación, usuarios, derechos de acceso, integridad de datos, FDW, registro y estadísticas. Nada nuevo
Notas
- Me referiré a Ruby on Rails y Postgres, pero la mayoría de las referencias son bien toleradas en otros idiomas y DBMS.
- No diré nada nuevo, todo esto ha sido descrito en la documentación y los artículos. Solo quiero recordar una vez más las herramientas y dónde se pueden aplicar para mejorar un poco la vida.
Autenticación de igual / ident
Cosa absolutamente saludable, que casi nadie usa. Asigna un usuario de Unix a un usuario de la base de datos. En el primer caso, se asigna el usuario local y, en el segundo, el usuario remoto. El beneficio es que puede eliminar el host, el nombre de usuario y la contraseña de la configuración (y el nombre de la base de datos también se puede eliminar), pero todo funcionará como antes. Además, será más conveniente ingresar a la consola para la depuración directa (solo psql desde el terminal en lugar de todos estos -h -U -W -d y así sucesivamente).
Documentación de PG sobre pares e ident .
Matices: adecuado si no solo tiene root y superusuario en el servidor; y en el caso de ident, usted controla la red, el hardware y está seguro de que no hay intrusos ni saboteadores.
Ejemplos de uso
Seguridad No puede eliminar la contraseña de la base de datos y conectarse desde el entorno local o desde otro lugar. No hay contraseña y no hay nada que arrastrar.
Control de acceso. Si hay varios roles de acceso a la producción u otro servidor y ya están divididos en el nivel de Unix, entonces es conveniente vincularlos con los usuarios de la base de datos. En este caso, la misma base de código se conectará con diferentes usuarios de la base de datos. Por ejemplo, el soporte técnico y los desarrolladores se suben a la misma consola de rieles, pero para algunos es de solo lectura, y para el segundo es de pleno derecho.
Derechos de acceso
En Unix, todos piensan en ellos y se ven muy sesgados al trabajar desde la raíz o en 'chmod 777' . Pero en la base de datos todo es de alguna manera diferente. Superusuario y listo. Aunque todo lo que hay no es menos (y tal vez incluso más) genial.
Hay una jerarquía de herencia de roles (un poco como grupo en Unix), hay accesos de diferentes niveles: a objetos específicos (como permisos de archivos), a operadores específicos (como reglas en sudoers ), incluso a líneas específicas . En resumen, todo está ahí. Úsalo.
Áreas de aplicación
En la versión mínima, junto con el par / ident anterior, puede separar el usuario para las migraciones / implementación y el usuario para el funcionamiento diario de la aplicación. Esto, al menos, protegerá contra llamadas DDL en tiempo de ejecución. Por supuesto, hay muchos casos de modificación de la estructura de la base de datos "en caliente". Estos son despliegues de tiempo de inactividad cero, y varias revisiones, y reconstrucciones de índices con precisión (y a veces sin). Pero, en general, una aplicación DDL no debería.
Otra opción: si tiene "microservicios", pero por alguna razón, usan la misma base de datos, entonces compartir claramente el acceso a los objetos de la base de datos es una muy buena idea. De hecho, las interfaces de interacción deben estar lo más localizadas posible, y el acceso anárquico a todos los datos contribuye a la erosión de la lógica y la responsabilidad.
Restricción de integridad
En Rails 5, al menos de alguna manera, el trabajo comenzó con referencias e integridad de datos. Pero, en el caso general, muchos desarrolladores creen que la validación en el modelo o sus alrededores es suficiente para preservar el estado consistente de los datos. Por desgracia, esto no es del todo cierto.
Se pueden omitir las validaciones, puede ir directamente a la base de datos y ejecutar sql, puede limpiar durante la migración. En general, se puede hacer mucho. Por lo tanto, todo lo que se basa en la lógica de negocios debe ser clavado por la base de datos. Esta es la única forma de preservar la integridad de los datos y no obtener "sorpresas" en la próxima implementación.
Contenedor de datos foráneos
Se trata de conectar una base de datos a otra para acceder a tablas remotas como propias. El beneficio principal es que la aplicación web no participa aquí, pero hay muchas optimizaciones cuando funcionan dos bases de datos idénticas (en general, el pushdown es para adaptadores diferentes, pero todo es complicado allí, por lo que es más fácil suponer que el paquete PG-PG funciona bien, y todo lo demás, cómo va).
Usando FDW
En lugar de configuraciones con las coordenadas de varias bases de datos en una aplicación web, es incomparablemente más fácil dejar una conexión a la base de datos y administrar todo a nivel de base de datos. Allí, por sí mismo, se resolverá la cuestión de los derechos de acceso y la elección de los objetos a los que se necesita acceso.
Además, en el futuro, puede reemplazar la tabla externa con una vista materializada o simplemente una tabla, pero no cambie nada en una aplicación web.
Y, sin embargo, puede conectarse al tipo exótico de MS Access y desaparecen los problemas con las restricciones en el uso de las relaciones en los modelos. Después de todo, si tiene más de 2 conexiones, no podrá unir dos bases a nivel de aplicación web, aunque ORM (en particular, ActiveRecord) honestamente intentará hacer esto ... y se caerá. Y a nivel de la base de datos, esto se puede hacer, en algunos casos, casi sin una sobrecarga.
Registro
Casi todos lo conocen y lo usan todo. Pero por si acaso, permíteme recordarte: no dudes en registrar solicitudes largas. Fuera de la caja, en PG, está apagado. Necesito log_min_duration_statement . En cuanto a su significado, hay muchos holivars y, tal vez, me tartamudean, pero para empezar, pon un par de segundos. Dado que si tiene una aplicación grande, es poco probable que la lea y usted mismo sepa qué hacer, pero si es pequeña, entonces no tiene tiempo para lidiar con frenos pequeños y solo las cosas fatales lo molestan.
También recuerda sobre N + 1. La base de datos no dirá nada al respecto. Utiliza herramientas de terceros. Por ejemplo, bala y sentido común.
Estadísticas
Debe recordarse que es así y que puede apestar. Al principio, todo está bien. Pero con el tiempo, generalmente, los siguientes resultados: la tasa de cambio de datos es aproximadamente la misma, y el tamaño de la tabla es mayor. En consecuencia, las tablas de vacío / análisis comienzan a ocurrir con menos frecuencia y en algún momento el programador comienza a fallar. En el mejor de los casos, la solicitud cae en el registro anterior, en el peor de los casos: simplemente sufre y no entiende por qué. En general, mire en pg_stat_user_tables y correlacione las fechas de vacío / análisis con la carga en las tablas.
Y a veces puedes usar estadísticas para un count aproximado. Raramente resulta útil, pero de manera bastante acertada, porque PG no es Oracle y el count de toda la tabla no se realiza en O (1), aunque realmente quiero hacerlo.
El final
Gracias por leer Si no es difícil, responda la siguiente pregunta. A la luz de un artículo reciente sobre GQL, en lugar de SQL, comenzó a molestarme mucho.