Compartir a través de

Procedimientos almacenados, desencadenadores y funciones definidas por el usuario

  • Se aplica a: ✅ NoSQL

Azure Cosmos DB proporciona una ejecución transaccional integrada en el lenguaje de JavaScript. Al usar la API para NoSQL en Azure Cosmos DB, puede escribir procedimientos almacenados, desencadenadores y funciones definidas por el usuario (UDF) en el lenguaje JavaScript. Puede escribir la lógica en JavaScript que se ejecuta dentro del motor de base de datos. Puede crear y ejecutar desencadenadores, procedimientos almacenados y UDF mediante Azure Portal, la API de consulta integrada del lenguaje JavaScript en Azure Cosmos DB o los SDK de cliente de NoSQL de Azure Cosmos DB.

Ventajas del uso de la programación del lado servidor

Escribir procedimientos almacenados, desencadenadores y funciones definidas por el usuario (UDF) en JavaScript le permite crear aplicaciones enriquecidas y tienen las siguientes ventajas:

  • Lógica de procedimientos: JavaScript es un lenguaje de programación de alto nivel que proporciona una interfaz enriquecida y familiar para expresar la lógica de negocios. Puede realizar una secuencia de operaciones complejas en los datos.

  • Transacciones atómicas: Las operaciones de base de datos de Azure Cosmos DB que se realizan dentro de un único procedimiento almacenado o un desencadenador son atómicas. Esta funcionalidad atómica permite a una aplicación combinar operaciones relacionadas en un solo lote, de modo que todas las operaciones se realicen correctamente o ninguna de ellas se realicen correctamente.

  • Rendimiento: Los datos JSON se asignan intrínsecamente al sistema de tipos de lenguaje JavaScript. Esta asignación permite diversas optimizaciones, como la materialización diferida de documentos JSON en el grupo de búferes, y las pone a disposición a petición para el código en ejecución. Hay otras ventajas de rendimiento asociadas al cambio de lógica de negocios a la base de datos, entre las que se incluyen:

    • Procesamiento por lotes: los desarrolladores pueden agrupar operaciones como inserciones y enviarlas en masa. Los costos de latencia del tráfico de red y la sobrecarga de almacenamiento para crear transacciones independientes se reducen significativamente.

    • Precompilación: Los procedimientos almacenados, los desencadenadores y las UDF se compilan implícitamente previamente en el formato de código de bytes para evitar los costos de compilación en el momento de cada invocación de script. Debido a la precompilación, la invocación de procedimientos almacenados es rápida y tiene un bajo impacto.

    • Secuenciación: A veces, las operaciones necesitan un mecanismo de desencadenamiento que pueda realizar una o más actualizaciones de los datos. Además de la atomicidad, también existen ventajas de rendimiento cuando se ejecuta en el servidor.

  • Encapsulación: Los procedimientos almacenados se pueden usar para agrupar la lógica en un solo lugar. La encapsulación agrega una capa de abstracción sobre los datos, lo que permite evolucionar las aplicaciones independientemente de los datos. Esta capa de abstracción es útil cuando los datos son sin esquema y no es necesario administrar la adición de lógica adicional directamente a la aplicación. La abstracción le permite mantener los datos seguros mediante la optimización del acceso desde los scripts.

Sugerencia

Los procedimientos almacenados son más adecuados para las operaciones que son intensivas en escritura y requieren una transacción en un valor de clave de partición. Al decidir si se deben usar procedimientos almacenados, se optimiza mediante la encapsulación de la cantidad máxima de operaciones de escritura posibles. Por lo general, los procedimientos almacenados no son los medios más eficaces para realizar grandes cantidades de operaciones de lectura o consulta, por lo que el uso de procedimientos almacenados para procesar por lotes un gran número de lecturas para volver al cliente no producirá la ventaja deseada. Para obtener el mejor rendimiento, estas operaciones de lectura intensiva se deben realizar en el lado cliente mediante el SDK de Azure Cosmos DB.

No se sugiere el uso de procedimientos almacenados con coherencia fuerte, ya que las mutaciones son locales.

Nota:

Las características de JavaScript del lado servidor, incluidos los procedimientos almacenados, los desencadenadores y las funciones definidas por el usuario, no admiten la importación de módulos.

Transactions

La transacción en una base de datos típica se puede definir como una secuencia de operaciones realizadas como una sola unidad lógica de trabajo. Cada transacción proporciona garantías de propiedad ACID. ACID es un acrónimo conocido que significa: Atomicidad, Consistencia, Aislamiento, y Durabilidad.

  • La atomicidad garantiza que todas las operaciones realizadas dentro de una transacción se consideran como una única unidad y se confirman todas o ninguna.

  • La coherencia garantiza que los datos estén siempre en un estado válido entre las transacciones.

  • El aislamiento garantiza que ninguna transacción interfiera entre sí: muchos sistemas comerciales proporcionan varios niveles de aislamiento que se pueden usar en función de las necesidades de la aplicación.

  • La durabilidad garantiza que cualquier cambio confirmado en una base de datos siempre estará presente.

En Azure Cosmos DB, el entorno de ejecución de JavaScript se hospeda dentro del motor de base de datos. Por lo tanto, las solicitudes realizadas en los procedimientos almacenados y los desencadenadores se ejecutan en el mismo ámbito que la sesión de base de datos. Esta característica permite a Azure Cosmos DB garantizar propiedades ACID para todas las operaciones que forman parte de un procedimiento almacenado o un desencadenador. Para obtener ejemplos, consulte el artículo sobre cómo implementar transacciones .

Sugerencia

Para obtener compatibilidad con transacciones en Azure Cosmos DB for NoSQL, también puede implementar un lote transaccional mediante el SDK de cliente preferido. Para más información, consulte Operaciones por lotes transaccionales en Azure Cosmos DB para NoSQL.

Ámbito de una transacción

Los procedimientos almacenados están asociados a un contenedor de Azure Cosmos DB y la ejecución de procedimientos almacenados tiene como ámbito una clave de partición lógica. Los procedimientos almacenados deben incluir un valor de clave de partición lógica durante la ejecución que defina la partición lógica para el ámbito de la transacción. Para más información, consulte el artículo Creación de particiones de Azure Cosmos DB .

Confirmación y reversión

Las transacciones se integran de forma nativa en el modelo de programación de JavaScript de Azure Cosmos DB. Dentro de una función de JavaScript, todas las operaciones se encapsulan automáticamente en una sola transacción. Si la lógica de JavaScript de un procedimiento almacenado se completa sin ninguna excepción, todas las operaciones dentro de la transacción se confirman en la base de datos. Las instrucciones como BEGIN TRANSACTION y COMMIT TRANSACTION (conocidas para las bases de datos relacionales) están implícitas en Azure Cosmos DB. Si hay alguna excepción del script, el entorno de ejecución de JavaScript de Azure Cosmos DB revertirá toda la transacción. Por lo tanto, lanzar una excepción es eficazmente equivalente a un ROLLBACK TRANSACTION en Azure Cosmos DB.

Coherencia de datos

Los procedimientos almacenados y desencadenadores siempre se ejecutan en la réplica principal de un contenedor de Azure Cosmos DB. Esta característica garantiza que las lecturas de los procedimientos almacenados ofrecen una coherencia fuerte. Las consultas que usan funciones definidas por el usuario se pueden ejecutar en la réplica principal o en cualquier réplica secundaria. Los procedimientos almacenados y los desencadenadores están diseñados para brindar soporte a las escrituras de transacciones. La lógica de solo lectura se implementa mejor como lógica del lado de la aplicación y las consultas con los SDK de Azure Cosmos DB for NoSQL le ayudarán a saturar el rendimiento de la base de datos.

Sugerencia

Es posible que las consultas ejecutadas dentro de un procedimiento almacenado o desencadenador no vean los cambios realizados en los elementos realizados por la misma transacción de script. Esta instrucción se aplica tanto a consultas SQL, como getContent().getCollection().queryDocuments(), como consultas de lenguaje integradas, como getContext().getCollection().filter().

Ejecución acotada

Todas las operaciones de Azure Cosmos DB deben finalizar dentro de la duración de tiempo de espera especificada. Los procedimientos almacenados tienen un límite de tiempo de espera de 5 segundos. Esta restricción se aplica a las funciones de JavaScript: procedimientos almacenados, desencadenadores y funciones definidas por el usuario. Si una operación no se completa dentro de ese límite de tiempo, la transacción se revierte.

Puede asegurarse de que las funciones de JavaScript finalicen dentro del límite de tiempo o implemente un modelo de continuación para ejecutar en lotes o reanudar la ejecución. Para simplificar el desarrollo de procedimientos almacenados y desencadenadores para controlar los límites de tiempo, todas las funciones del contenedor de Azure Cosmos DB (por ejemplo, crear, leer, actualizar y eliminar elementos) devuelven un valor booleano que representa si esa operación se completará. Si este valor es false, es una indicación de que el procedimiento debe encapsular la ejecución porque el script consume más tiempo o rendimiento aprovisionado que el valor configurado. Se garantiza que las operaciones en cola antes de la primera operación de almacén no aceptadas finalicen si el procedimiento almacenado se completa a tiempo y no pone en cola más solicitudes. Por lo tanto, las operaciones deben ponerse en cola una a una mediante la convención de devolución de llamada de JavaScript para administrar el flujo de control del script. Dado que los scripts se ejecutan en un entorno del lado servidor, se rigen estrictamente. Los scripts que infringen repetidamente los límites de ejecución se pueden marcar como inactivos y no se pueden ejecutar, y se deben volver a crear para respetar los límites de ejecución.

Las funciones de JavaScript también están sujetas a la capacidad de rendimiento aprovisionada. Las funciones de JavaScript podrían acabar usando un gran número de unidades de solicitud en un breve período de tiempo y pueden estar limitadas a la velocidad si se alcanza el límite de capacidad de rendimiento aprovisionado. Es importante tener en cuenta que los scripts consumen rendimiento adicional además del rendimiento dedicado a la ejecución de operaciones de base de datos, aunque estas operaciones de base de datos son ligeramente menos costosas que las mismas operaciones ejecutadas desde el cliente.

Desencadenadores

Azure Cosmos DB admite dos tipos de desencadenadores:

Desencadenadores previos

Azure Cosmos DB proporciona desencadenadores que se pueden invocar realizando una operación en un elemento de Azure Cosmos DB. Por ejemplo, puede especificar un desencadenador previo al crear un elemento. En este caso, el desencadenador previo se ejecutará antes de crear el elemento. Los desencadenadores previos no pueden tener parámetros de entrada. Si es necesario, el objeto de solicitud se puede usar para actualizar el cuerpo del documento de la solicitud original. Cuando se registran desencadenadores, los usuarios pueden especificar las operaciones con las que se puede ejecutar. Si se creó un desencadenador con TriggerOperation.Create, esto significa que no se permitirá el uso del desencadenador en una operación de reemplazo. Para obtener ejemplos, consulte el artículo Sobre cómo escribir desencadenadores .

Desencadenadores posteriores

De forma similar a los desencadenadores previos, los desencadenadores posteriores también están asociados a una operación en un elemento de Azure Cosmos DB y no requieren ningún parámetro de entrada. Se ejecutan una vez completada la operación y tienen acceso al mensaje de respuesta que se envía al cliente. Para obtener ejemplos, consulte el artículo Sobre cómo escribir desencadenadores .

Nota:

Los desencadenadores registrados no se ejecutan automáticamente cuando se producen sus operaciones correspondientes (crear, eliminar, reemplazar o actualizar). Deben ser llamados explícitamente al ejecutar estas operaciones. Para más información, consulte el artículo sobre cómo ejecutar desencadenadores .

Funciones definidas por el usuario

Las funciones definidas por el usuario (UDF) se usan para ampliar la sintaxis del lenguaje de consulta NoSQL de la API e implementar fácilmente la lógica de negocios personalizada. Solo se pueden llamar dentro de las consultas. Las UDF no tienen acceso al objeto de contexto y están diseñadas para usarse como JavaScript de solo cálculo. Por lo tanto, se pueden ejecutar los UDF en réplicas secundarias.

API de consulta integrada en lenguaje JavaScript

Además de emitir consultas mediante la sintaxis de consulta de API para NoSQL, el SDK del lado servidor permite realizar consultas mediante una interfaz de JavaScript sin ningún conocimiento de SQL. La API de consulta de JavaScript permite compilar consultas mediante programación pasando funciones de predicado a una secuencia de llamadas de función. El tiempo de ejecución de JavaScript analiza las consultas, que luego se ejecutan de forma eficaz en Azure Cosmos DB. Para más información sobre la compatibilidad con la API de consulta de JavaScript, consulte el artículo Trabajar con la API de consulta integrada del lenguaje JavaScript . Para obtener ejemplos, consulte el artículo Sobre cómo escribir procedimientos almacenados y desencadenadores mediante la API de consulta de JavaScript .

Pasos siguientes

Aprenda a escribir y usar procedimientos almacenados, desencadenadores y funciones definidas por el usuario en Azure Cosmos DB con los siguientes artículos:

¿Está intentando hacer la planificación de capacidad para una migración a Azure Cosmos DB? Puede utilizar información sobre su clúster de bases de datos existente para la planificación de capacidad.

  • Last updated on