Manera eficiente de generar números secuenciales en SQL Azure Federations

Question

Considerando que las federaciones de SQL Azure no admiten la propiedad o las secuencias de identidad, ¿cuál sería una forma eficiente de generar números secuenciales al insertar registros?

Por ejemplo, dada una tabla con estas columnas:

CREATE TABLE [dbo].[Orders] (
    [TenantId] [uniqueidentifier] NOT NULL,
    [OrderId] [uniqueidentifier] NOT NULL,
    [OrderNumber] [int] NOT NULL
    CONSTRAINT [PK_Orders] PRIMARY KEY CLUSTERED (
        [TenantId] ASC,
        [OrderId] ASC
    )
) FEDERATED ON ([FederationKey] = [TenantId])

Para cada orden insertado para un inquilino determinado, el orden izquierdo debe ser incrementado. Por ejemplo, para que Tentant un ordenado sería 1, 2, 3 ... y para el inquilino B ordenado también sería 1, 2, 3 ... en una secuencia independiente. Idealmente, no debería haber brechas.

tenantid y ordenados son componentes de la clave principal. Sus valores están establecidos por la solicitud y no están relacionados con el problema de generar secuencias; Solo PDERID tiene el número secuencial con el significado comercial. Además, Tenantid es la clave de distribución de la Federación.

este artículo de blog de msdn describe en la opción 1 un enfoque de tener una tabla que sujeta las secuencias y utilizando un procedimiento almacenado en una transacción segregada para incrementar las secuencias. Cada inquilino tendría un registro en esta tabla con el último valor utilizado de la secuencia.

¿Sería ese enfoque óptimo considerando escalabilidad, contención, bloqueo de recursos? ¿Algún otro trucos útiles, considerando las limitaciones de las federaciones de SQL Azure?

Answer 1

Aquí hay 2 ideas adicionales.

Un enfoque sería tener una actualización de proceso separada de ese campo para hacer esto asíncrono, si eso es posible para el escenario de su negocio. Necesitaría que el campo de los numeros acepte los valores nulos para este enfoque. Para saber qué orden llegó primero, para que obtenga el número de pedido correcto, también agregaría un campo INSERTEDDATE. El procesamiento de ASYNC se vuelve más complejo si tiene varios roles de trabajadores que realizan este deber de redundancia, en cuyo caso deberá tener cada proceso asignarse a sí mismo los registros en la que está trabajando (por lo que también necesita un campo de propiedad), agregue una prueba de concurrencia durante La actualización para garantizar que cada proceso se esté ejecutando en sus propios registros y haga que la asignación de los registros caduque (para que también necesite un campo de asignación) si el proceso se bloquea para que no deje los huérfanos. No es realmente trivial ...

y luego tienes el enfoque del hombre pobre ... que cuando las estrellas se alinean lo suficientemente bien, pueden ser todo lo que necesitas. Si está dispuesto a tener un enfoque de concurrencia optimista, intente usar el siguiente número durante el inserto (seleccione el número de orden máximo primero para un tenantid y orden determinado), luego realice el inserto. Si el inserto falla (porque agregó un índice único en Tenantid, anderado para ese propósito), solo agregue 1 al número de pedido. El problema real aquí es la frecuencia de los reintentos y la probabilidad de este enfoque que falla. Si tiene un proceso de negocio relativamente aerodinámico, esto puede, en realidad, nunca puede fallar; Sin embargo, si tiene órdenes agregadas constantemente de múltiples avenidas, este puede ser un enfoque inaceptable.

Answer 2

No estoy seguro de cuánto esfuerzo se requerirá para que se ajuste a su escenario, pero eche un vistazo a esto y vea si puede modificarlo: Snowmaker - Un generador de identificación único para Azure(o cualquier otro entorno de alojamiento en la nube)