¡El procedimiento almacenado es muy bueno, aquellos que no lo usan bien tienen pocas habilidades y no aceptan refutaciones! He tenido esta idea, pero para las bases de datos distribuidas, prefiero usar menos o ningún procedimiento almacenado.
1 Vengo de la era C/S
Los kits de desarrollo más populares al final de la era de la arquitectura C/S son las bases de datos PowerBuilder y Sybase:
- Herramienta de desarrollo visual PowerBuilder, como VB, el programa desarrollado se ejecuta en la terminal de PC del usuario y se conecta a la base de datos remota a través del controlador
- Sybase estaba compitiendo con Oracle por el encabezado de la base de datos en ese momento y tenía una relación profunda con SQL Server, y los dos eran muy similares en arquitectura y lenguaje.
En esta arquitectura C/S, la base de datos no solo realiza funciones informáticas y de almacenamiento de datos, sino que también ejecuta una lógica de negocios pesada, lo que equivale a que la base de datos realice la mayoría de las funciones del servidor de aplicaciones (Application Server). El soporte técnico de estas lógicas comerciales es el procedimiento almacenado. Por lo tanto, ya sea Sybase u Oracle, sus procedimientos almacenados son muy poderosos.
Se descartan 2 activadores
Al ingresar a B/S, la comprensión de la base de datos por parte de todos ha cambiado y el servidor de aplicaciones lleva la lógica comercial principal del servidor, entonces, ¿todavía usa procedimientos almacenados? Mismo problema que hoy. La opinión general en ese momento era que los procedimientos almacenados aún tenían valor, pero sus disparadores hermanos se abandonaron por completo.
Los disparadores son funciones personalizadas como los procedimientos almacenados, pero:
- No se llama explícitamente, sino que se activa pasivamente cuando se opera la tabla de datos, es decir, cuando se ejecutan insertar, actualizar y eliminar.
- También puede elegir si el tiempo de disparo es antes o después de la operación, es decir, la semántica de antes y después
Suena potente, un poco de programación orientada a eventos. Pero después de mantener la lógica de activación, descubrí que este es un gran pozo. A medida que el negocio se desarrolla y cambia, la lógica del disparador se vuelve más y más compleja. Alguien manipulará otra tabla en la lógica del disparador, y hay otros disparadores en esa tabla que implican a otras tablas, formando un skynet. Un pequeño paso en falso, tras una serie de reacciones en cadena, se convierte en una catástrofe. Por lo tanto, el gatillo se ha retirado del escenario de la historia. (Todavía siento que no hay demasiadas restricciones, lo que lleva al abuso)
3 ventajas de los procedimientos almacenados
La llamada es clara y no hay problema de disparo. Las ventajas son obvias, la lógica se ejecuta en la base de datos y no hay sobrecarga de datos de transmisión de red, por lo que la ventaja de rendimiento es sobresaliente cuando se realizan operaciones con uso intensivo de datos.
En ese momento, era necesario desarrollar funciones y rastrear la relación de influencia entre las entidades comerciales, por ejemplo, A afecta a B y B afecta a C. Esta función es usar A como entrada para averiguar tanto B como C. Por supuesto, la relación de influencia no se limita a tres capas y debe rastrearse hasta todas las entidades afectadas.
Las consultas relacionales típicas son adecuadas para bases de datos de gráficos. Pero en ese momento, no había una base de datos de gráficos disponible y este problema debía resolverse en Oracle. Un colega más joven que yo escribió una pieza de código Java para lograr esta función, supongo que no ha experimentado la era C/S. Después de que se ejecuta el programa, el servidor de aplicaciones accede continuamente a esta tabla para procesar la relación de asociación de cada registro. El rendimiento se puede imaginar: en un entorno de prueba con una pequeña cantidad de datos, el programa se ejecutó durante 30 minutos completos. Esto está mucho más allá de la tolerancia del usuario y debe optimizarse.
Cambié a un procedimiento almacenado para lograr la misma lógica, porque no se requiere transmisión de red y el rendimiento mejoró considerablemente. Al final, el procedimiento almacenado tardó unos veinte segundos en obtener el mismo resultado. ¡Bien hecho! .
4 Problemas con los procedimientos almacenados
Más tarde se descubrió que este programa era poco trasplantable. Los productos desarrollados se implementarán en el entorno del cliente, sujetos a las limitaciones del software básico correspondiente.
Una vez sucedió que el cliente no usaba Oracle, por lo que otros colegas tradujeron la lógica que escribí a la base de datos utilizada por el cliente. El procedimiento almacenado que se puede trasplantar a TDB no puede salir sin ningún resultado. Después de rastrear este código, finalmente descubrí que el problema no está en la lógica en sí, sino en la base de datos. Utilicé un algoritmo recursivo en esta lógica, porque Oracle admite un nivel recursivo profundo, por lo que no hay problemas de ejecución; mientras que TDB solo admite un nivel recursivo limitado y había muchas asociaciones de datos en ese momento, por lo que el programa informó un error y salió después de un corto período de tiempo. .
Esta experiencia ha sacudido un poco mi confianza en los procedimientos almacenados. Los procedimientos almacenados tienen una gran dependencia del entorno, y este entorno no es un entorno abierto que sigue un estándar unificado y tiene una gran cantidad de información técnica, como el sistema operativo y la máquina virtual Java, sino una caja negra que no es tan estándar. como la base de datos.
Sin embargo, los problemas con los procedimientos almacenados no terminan ahí. Cuando estaba desarrollando bajo la arquitectura C/S, me encontré con el problema de que el procedimiento almacenado era difícil de depurar, pero en ese momento todos pensaban que ese era el precio que había que pagar. Sin embargo, con la llegada de la arquitectura B/S y el desarrollo continuo de la tecnología de prueba y desarrollo de código Java, el problema de la depuración difícil de los procedimientos almacenados se ha vuelto más prominente. Hoy en día, el desarrollo ágil se está volviendo cada vez más popular, la cadena de herramientas DevOps se está desarrollando rápidamente y el procedimiento almacenado sigue siendo "independiente".
Habiendo dicho tanto, lo que espero que entienda es que los procedimientos almacenados de hoy y los disparadores de ese año enfrentan esencialmente el mismo problema: una tecnología debe coincidir con el nivel de ingeniería de la época e integrarse con toda la ecología de la tecnología, de lo contrario, saldrá. la mayoría de los escenarios de aplicación .
Verá, en el "Manual de desarrollo de Java de Alibaba", también está escrito de manera impresionante que "el uso de procedimientos almacenados está prohibido. Los procedimientos almacenados son difíciles de depurar y expandir, y no son portátiles". mentalidad para mí.
5 Soporte de bases de datos distribuidas
La mayoría de las bases de datos distribuidas de NewSQL aún no admiten procedimientos almacenados. La excepción es OceanBase, que agregó compatibilidad con los procedimientos almacenados de Oracle en la versión 2.2. Creo que esto es producto de su compatibilidad general con la política de Oracle. Sin embargo, la declaración oficial de OceanBase es muy clara en cuanto a que la función del procedimiento almacenado no cumple con los requisitos de producción en la actualidad.
La compatibilidad con los sistemas heredados puede ser la mayor importancia de los procedimientos almacenados en la actualidad. Para aquellos sistemas que migran de MySQL a bases de datos distribuidas, este atractivo puede no ser tan fuerte, porque estos sistemas no dependen tanto de los procedimientos almacenados. Debido a que MySQL solo proporciona procedimientos almacenados en una versión posterior y las funciones no son tan poderosas como las de Oracle, la dependencia del usuario es mucho menor. Los procedimientos almacenados no son ampliamente compatibles con NewSQL, pero también debido a dificultades arquitectónicas.
Vea lo que la industria está intentando.
Google lanzó un nuevo documento F1 " F1 Query: Declarative Querying at Scale " en VLDB en 2018 . Se propone admitir funciones personalizadas, a saber, procedimientos almacenados, a través de un servidor UDF independiente. En esta arquitectura, debido a que F1 es completamente independiente del almacenamiento de datos, el servidor UDF se extrae naturalmente. A juzgar por los datos de prueba proporcionados en el documento, este diseño mantiene un alto rendimiento, pero creo que esto tiene mucho que ver con las potentes instalaciones de red de Google. Es difícil decir si se puede aplicar en las condiciones normales de la red empresarial.
Diseño de Servidor UDF
- UDF se da cuenta del soporte para lenguaje general, además de SQL, también es compatible con C ++, Java, Go y otras implementaciones de lenguaje. De esta forma, no depende del dialecto SQL de la base de datos y la versatilidad de la expresión lógica es mejor.
- Las UDF no están acopladas a la capa de almacenamiento. Esto significa que su contexto puede ser más abierto.
Esto significa que la depuración de procedimientos almacenados puede mejorarse significativamente, lo que hace posible la interfaz con el sistema DevOps.
VoltDB anterior también ha reformado los procedimientos almacenados. VoltDB es una base de datos distribuida basada en memoria desarrollada por el legendario Michael Stonebraker en el campo de las bases de datos. VoltDB utiliza procedimientos almacenados como principal modo de operación y admite la escritura en el lenguaje Java. Los desarrolladores pueden heredar la clase principal (VoltProcedure) proporcionada por el sistema para desarrollar sus propios procedimientos almacenados:
import org.voltdb.*;
public class LeastPopulated extends VoltProcedure {
//待执行的SQL语句
public final SQLStmt getLeast = new SQLStmt(
" SELECT TOP 1 county, abbreviation, population "
+ " FROM people, states WHERE people.state_num=?"
+ " AND people.state_num=states.state_num"
+ " ORDER BY population ASC;" );
//执行入口
public VoltTable[] run(int state_num)
throws VoltAbortException {
//赋输入参数
voltQueueSQL( getLeast, state_num );
//SQL执行函数
return voltExecuteSQL();
}
}
Primero defina SQL, donde "state_num=?" es una posición de parámetro reservada, y luego asigne y ejecute parámetros en la función de entrada run().
El concepto de diseño de VoltDB es diferente y otorga gran importancia a la eficiencia del uso de la CPU. Analizaron las bases de datos tradicionales y creyeron que solo el 12 % del tiempo de CPU de las bases de datos ordinarias se usa para operaciones de datos significativas, por lo que muchos de sus diseños giran en torno al uso completo de los recursos de la CPU.
El procedimiento almacenado es esencialmente una transacción predefinida y no hay un proceso de interacción manual, lo que evita la espera de la CPU. Al mismo tiempo, debido a que el contenido del procedimiento almacenado es predecible, los datos se pueden cargar en la memoria lo antes posible, lo que reduce aún más la espera de la CPU causada por la red y la E/S del disco.
Debido al uso de procedimientos almacenados y memoria, VoltDB logra un buen rendimiento incluso en el modelo de un solo subproceso. Por el contrario, el subproceso único en sí mismo simplifica el control de transacciones, evita la sobrecarga de la gestión de bloqueo tradicional y la espera de la CPU, y mejora el rendimiento de VoltDB.
En comparación con otras bases de datos, los procedimientos almacenados tienen significados completamente diferentes a los de VoltDB.
6 Resumen
- La portabilidad del procedimiento almacenado es deficiente. Altamente dependiente del entorno de la base de datos, y el entorno de la base de datos no sigue un estándar unificado como el sistema operativo o la máquina virtual. Por la misma razón, la depuración de procedimientos almacenados también es muy complicada y no se ha mantenido al ritmo del desarrollo ágil y no cumple con los requisitos de ingeniería actuales. Es precisamente por estas dos razones de ingeniería que los procedimientos almacenados no se usan o se usan menos.
- Desde la perspectiva de las bases de datos distribuidas, la mayoría de los NewSQL aún no soportan procedimientos almacenados, OceanBase, como única excepción, ya soporta procedimientos almacenados de Oracle, pero aún no ha alcanzado el nivel de producción.
- El documento de F1 propuso la idea de un servidor UDF independiente, que es un esquema de implementación para procedimientos almacenados en una arquitectura distribuida, pero aún está por verse si puede ser adecuado para entornos de red empresarial ordinarios. Sin embargo, en esta solución, el lenguaje de implementación del procedimiento almacenado no se limita al dialecto SQL, sino que se extiende a una variedad de lenguajes principales, compatibles con los estándares y tiene una mejor apertura. Esto plantea la posibilidad de la integración de la tecnología de procedimientos almacenados con DevOps.
- Como base de datos distribuida en memoria, VoltDB utiliza procedimientos almacenados como el principal método de definición de operaciones y es compatible con el desarrollo del lenguaje Java. Incluso se puede decir que la base de VoltDB es el método de transacción predefinido de los procedimientos almacenados. Los procedimientos almacenados, el almacenamiento en memoria y el hilo único interactúan entre sí, lo que hace que VoltDB tenga un rendimiento excelente.
Para cualquier programador, debe ser una decisión difícil renunciar a una tecnología que ha sido dominada y ejecutada de manera eficiente. Pero hoy en día, para los grandes sistemas de software, los requisitos de ingeniería son mucho más importantes que una determinada tecnología en sí misma. Las tecnologías que no pueden cooperar con todo el ecosistema tecnológico eventualmente no podrán evitar el destino de ser marginadas. Antes de aprender una nueva tecnología, ya sea una base de datos distribuida o un microservicio, le sugiero que preste atención a si se puede adaptar a la ecología circundante, porque la tecnología que se ajusta a la tendencia tiene la oportunidad de mejorar, pero también lo es. nicho La tecnología contiene mayor incertidumbre.
referencia
- Bart Samwel: Consulta F1: consulta declarativa a escala
7 preguntas frecuentes
La idea de diseño de VoltDB es muy especial, además de ser de un solo hilo, usar una gran cantidad de memoria y almacenar procedimientos para soportar el lenguaje Java, su diseño en la replicación de datos también es ingenioso, no es ni el protocolo Paxos de NewSQL ni la replicación maestro-esclavo de PGXC, os podéis imaginar ¿Cómo está diseñado? Existe una cierta relación entre el mecanismo de replicación y el procedimiento almacenado.
1. El código comercial y el código técnico deben estar separados. Necesitamos asegurarnos de que la traducción de la lógica comercial al código comercial sea simple y pura. Esto no es solo para reducir el acoplamiento a tecnologías específicas en la etapa de implementación, sino también para garantizar la capacidad de prueba del código comercial y la simplicidad y cohesión del código comercial.
2. Las características de tecnologías específicas (como los procedimientos almacenados) a menudo pueden lograr un rendimiento sobresaliente. Pero esto también aumenta la complejidad de la fase de implementación, y la complejidad significa un mantenimiento difícil, lo que significa costo y riesgo. Si bien se realiza el valor de comportamiento del software, la salud de la calidad arquitectónica se ve comprometida. Por lo tanto, en escenarios con estrictos requisitos de rendimiento, es comprensible utilizar algunas funciones de tecnologías específicas, pero debemos permanecer atentos y reconocer que se trata de un arma de doble filo. No actúes imprudentemente sobre la base de tu propia "habilidad profunda".
3. No haber experimentado la era de c/s. Sin embargo, en los libros relevantes sobre diseño basado en modelos de datos, podemos ver cómo el procedimiento almacenado fue tan popular al principio. Pero ahora, cuando una serie de métodos como los procedimientos almacenados se vuelven cosa del pasado, el diseño basado en modelos de datos comienza a volverse muy "anémico". Básicamente, solo quedan el modelo de entidad-relación y los elementos de datos, que es una capacidad de transmisión de información débil, que ya no es adecuada para impulsar el diseño de software comercial complejo.
4. Ponga su propia implementación del controlador del modelo de datos para la comunicación: https://github.com/Jxin-Cai/mdd/tree/master/data-model/mini-faas
La replicación de fragmentos de VoltDB es similar al servidor de nombres de RocketMq. Al realizar operaciones en todas las réplicas en paralelo, se evita la complejidad de llegar a un consenso entre las réplicas.
OceanBase no tiene más remedio que admitir los procedimientos almacenados de Oracle, porque determina si puede "invadir" el campo de clientes tradicional de Oracle: las grandes empresas y el sector financiero, que es puramente comercial. Los productos ERP de Oracle utilizan una gran cantidad de procedimientos almacenados para implementar la lógica comercial. El código fuente de la lógica comercial más compleja se imprime en decenas de páginas. Creo que las herramientas de OceanBase no pueden manejar un procedimiento almacenado tan complicado a la perfección (transplantado a OB), pero para licitar y cosas por el estilo. Si no es compatible con muchas características de Oracle, no tiene la oportunidad de participar en absoluto.
VoltDB utiliza el mecanismo de seguridad K para resolver el problema de la replicación de datos. De hecho, es un mecanismo de copia N + 1. Cuando VoltDB escribe datos, ejecutará la declaración en cada copia, para garantizar que los datos sean correctos. insertado en cada copia. Todas las copias N+1 pueden proporcionar acceso al mismo tiempo y, al mismo tiempo, se permite la pérdida de hasta N copias (fallo de partición). Cuando las copias N+1 no están disponibles, VoltDB detendrá el servicio para su reparación.
El "Manual de desarrollo Java de Alibaba" prohíbe el uso de procedimientos almacenados, que son difíciles de depurar y expandir, y no tienen portabilidad. "Se sospecha que es engañoso. El procedimiento almacenado aquí está dirigido a MySQL, y es realmente difícil de depurar y replicar. En productos de la misma época, los procedimientos almacenados están escritos en PL/SQL de Oracle y T-SQL del servidor SQL. siguen siendo muy ventajosos Tanto DB2 como Oracle admiten PL/SQL, donde PL/SQL es portátil, y este procedimiento almacenado se llama en el estándar SQL (SQL/PSM (SQL/Persistent Stored Modules) https://en.wikipedia. org/wiki/SQL/PSM).
Esta sugerencia en el manual de desarrollo de Ali no se refiere específicamente a MySQL, puede estar incluida en el capítulo de MySQL porque MySQL se usa ampliamente en Ali y es una base de datos representativa. ¿Podría ser que estén deshabilitando los procedimientos almacenados de MySQL mientras secretamente utilizan felizmente los procedimientos almacenados de Oracle? Parece poco probable.
A lo largo del desarrollo de los estándares SQL y el desarrollo de Oracle, el soporte de los procedimientos almacenados también tiene un proceso de desarrollo.El rendimiento y la eficiencia de desarrollo de los procedimientos almacenados siguen siendo bastante altos. En la era de los grandes datos, la gente habla de la separación del almacenamiento, el almacenamiento pertenece al almacenamiento y el cálculo pertenece al cálculo. Sobre la base del hardware y el equilibrio de costos, la potencia informática aumenta a través de la expansión horizontal, y la función del proceso de almacenamiento es no está desarrollado temporalmente o es difícil de desarrollar, pero Apache Hive es El procedimiento almacenado compatible se llama hpsql.
Además, el estándar SQL es solo una referencia para todas las bases de datos.Diferentes bases de datos tienen diferentes longitudes en tipos de datos, variables globales, funciones e incluso nombres de procedimientos almacenados. Ninguna base de datos es idéntica a menos que se adapte específicamente. Es por eso que se dice que la base de datos de conmutación del sistema es un gran problema.
Los representantes típicos de las bases de datos distribuidas son TiDB y CockroachDB. Son algo diferentes en compatibilidad de sintaxis y soporte para procedimientos almacenados. ¿CuckroachDB admite procedimientos almacenados en sintaxis pg (pg es similar a PL/SQL)?
Después de comprender estas diferencias, algunos estudiantes aún pueden sentir que esto no es un problema, tan fácil. Para los individuos, si es difícil o fácil es un juicio muy subjetivo, la clave está en si tu equipo puede usar esta tecnología por mucho tiempo y a bajo costo.
Dado que todos los procedimientos almacenados son compatibles con JAVA, la replicación de datos debería poder aprender de TCC, que se implementa directamente en la capa de código, que es equivalente a la "capa de servicio", y se basa en la memoria, y el costo de volver a intentarlo es bajo, usando código directamente para escribir en el nodo ¿Entendido?
Todos se basan en la memoria, pero a diferencia de Redis, no deberían requerir un rendimiento tan alto y usar directamente el grupo de subprocesos para escribir datos en los nodos de datos al mismo tiempo.
Los procedimientos almacenados son un producto insustituible de la era de las bases de datos independientes. Cuando era programador, los procedimientos almacenados eran la mejor herramienta para resolver la separación de los códigos front-end y back-end. ¿Se puede completar una operación de revisión por lotes de 100,000 pedidos en unos minutos llamando al procedimiento almacenado, y se ejecuta el código VB front-end, y el resultado no se puede obtener por una hora?
Sí, los procedimientos almacenados son definitivamente una herramienta poderosa para la informática con uso intensivo de datos.
La vista materializada de clickhouse es en realidad un disparador ¿Desde qué ángulo debe ser analizado?
Desde un punto de vista mecánico, la vista materializada (MaterializedView) en ClickHouse puede considerarse como un activador.
- ángulo funcional
La función de la vista materializada es precalcular una tabla básica y mantener los resultados de la consulta SELECT en tiempo real, lo que es funcionalmente equivalente a crear una vista en caché que se actualiza en tiempo real. Esto es similar a cómo los disparadores pueden realizar automáticamente acciones preestablecidas cuando cambian los datos.
- Perspectiva del mecanismo de implementación
ClickHouse crea una vista materializada a través del motor, y cuando hay un cambio de datos en la tabla subyacente, activará automáticamente la actualización de la vista materializada. Esto aprovecha el mecanismo de activación del motor para lograr vistas materializadas en tiempo real.
- usar ángulo de escena
Las vistas materializadas se pueden usar en el análisis de datos, el tablero y otros escenarios que requieren un acceso rápido a los resultados agregados, reemplazando las consultas repetidas, que es similar al uso de disparadores.
- perspectiva de desempeño
Las vistas materializadas mejoran el rendimiento de lectura a través del almacenamiento en caché, pero aumentan la carga de escritura. Debe sopesar la proporción de lectura y escritura para decidir si usarla. Esto también refleja las características de compensación de rendimiento de los disparadores.
- ángulo límite
Las vistas materializadas tienen varias restricciones en las consultas, y estas restricciones también son factores que los disparadores generalmente deben tener en cuenta.
En resumen, desde múltiples perspectivas, la vista materializada de ClickHouse se puede considerar como un disparador especial, que es útil para comprender y utilizar las vistas materializadas. Esto me dio un nuevo ángulo para analizar varios mecanismos de automatización en la base de datos.