Antecedentes:de publicación/suscripción patrón en SQL
Tenemos una mesa grande (más de 15 millones de dólares) de los artículos que se actualiza con frecuencia durante el día (promedio 300K cambios diarios). Los cambios pendientes se almacenan en una tabla de etapas y un trabajo se ejecuta a lo largo del día para leer los cambios de esta tabla, realizar las actualizaciones y marcar los cambios como procesados.
Muchas otras aplicaciones usan los datos de la tabla de elementos para realizar diversas tareas. A menudo, estas tareas son programadas e intensivas, ya que implican la comparación de datos en tiempo real con instantáneas antiguas y la actualización de otros sistemas en consecuencia. Por ejemplo, enumeramos los artículos en eBay y comparamos los datos de los artículos en vivo con nuestros listados existentes para ver si necesitamos insertar cualquier nueva lista de eBay, eliminar los artículos que hemos vendido, cantidades de actualización, etc. Debido a que los datos son tan grandes, la mayoría de estas aplicaciones se ejecutan con poca frecuencia, dejando cosas desactualizadas la mayor parte del tiempo.
Mi Pregunta:
Estamos considerando la implementación de un modelo de editor/suscriptor mediante el Service Broker. El objetivo sería publicar un mensaje cuando un artículo cambie, al cual otros sistemas (como nuestra aplicación eBay) pueden suscribirse. Esto nos permitiría hacer actualizaciones más granulares más cerca de tiempo real, en lugar de actualizaciones grandes e infrecuentes que implican consultar todos los datos, no solo lo que ha cambiado. Sin embargo, después de usar Google, no parece que este sea un patrón de base de datos común, y eso levanta banderas rojas. ¿No es esto un uso válido de Service Broker (aunque encontré una pequeña sección en Pro Sql Server 2008 Service Broker al hacer Pub/Sub)? ¿Cómo se resuelve este problema normalmente? Parece un problema bastante común.
TL; DR:
Objetivo: Actualizar varios sistemas de una manera dinámica, débilmente acoplado cuando los elementos individuales cambian.
Pregunta: ¿Se ha implementado una solución de estilo pub/sub con Service Broker como una solución viable en una configuración de alto volumen?
Dos preguntas: ¿por qué esas aplicaciones usan datos en la tabla de elementos principales en lugar de procesar los cambios pendientes en la tabla de etapas? Segundo: ¿necesita absolutamente SQL Server para mantener y publicar los elementos? –
Eche un vistazo a la replicación SQL integrada, es lo suficientemente flexible como para acomodar una amplia gama de escenarios. – alexm
@KubaWyrostek ese fue nuestro primer pensamiento, y lo que nos llevó a considerar el enfoque basado en mensajes. En lugar de leer de esa tabla de vez en cuando, ¿por qué no utilizarla como fuente de mensajes 'Elemento modificado'? Tal vez una capa innecesaria de abstracción, pero como la tabla de etapas se borra periódicamente de las actualizaciones procesadas, el pensamiento más seguro y más flexible sería Service Broker – Bort