Lo que se pro / contras de push / pull modelos de flujo de datos?

Question

he estado desarrollando una aplicación DSP en la casa (Java w / ganchos para Groovy / Jython / JRuby, plugins a través de OSGi, un montón de JNI para dar la vuelta) en el estilo del diagrama de flujo de datos /, similar a los datos puros y Simulink . Mi diseño actual es un modelo de inserción. El usuario interactúa con algún componente fuente haciendo que se empuje datos en el siguiente componente y así sucesivamente hasta que un bloque de extremo (típicamente una pantalla o escritor de archivo). Hay algunos desafíos únicos con este diseño específicamente cuando un componente se muere de hambre para la entrada. No hay una manera fácil de solicitar más de entrada. He mitiated parte de este flujo con control de retroalimentación, ex un bloque FFT puede difundir que necesita más datos para el bloque fuente de su cadena. He contemplado la adición de soporte para los componentes a ser o bien de empuje / tracción / ambos.

Estoy buscando respuestas con respecto a los méritos de empuje vs vs tirón tanto / híbrido. ¿Has hecho esto antes? ¿Cuáles son algunas de las "trampas"? ¿Cómo las manejas? ¿Hay una mejor solución para este problema?

Answer 1

Algunos experiencia con un enfoque de "mayoría-pull" en un producto de gran escala:

Modelo: Nodos construir una relación 1: N árbol, es decir, cada componente (excepto la raíz) tiene 1 padre y 1..n niños. Los datos fluyen casi exclusivamente de padres a hijos. Cambiar las notificaciones se pueden originar desde cualquier nodo en el árbol.

Implementación: Todas las hojas son notificados con el ID del nodo emisor y un contador de "generación". Hojas saben qué camino nodo que dependen, para que sepan si necesitan actualizar. (Cualquier otro algoritmo de actualización de nodo hijo podría hacer, también, y podría haber sido mejor en retrospectiva).

Hojas sus padres su búsqueda para los datos actuales, la consulta se propaga hacia arriba de forma recursiva. El contador de generación se incluye, por lo que la burbuja de arriba se detiene en el nodo de origen.

Ventajas:

• nodos padres no necesitan mucha / alguna información acerca de sus hijos. Los datos pueden ser consumidos por cualquier persona - esto permitió un enfoque genérico para implementar algunas funciones no-UI (inicialmente no se espera) en la parte superior de los datos utilizados para exposiciones
nodos
• Niños pueden agregar y actualizaciones de retardo (evitando vuelve a dibujar mejor que estar de pintura rápida)
• hojas inactivas causan ningún tráfico de datos en absoluto

Desventajas

• Las actualizaciones incrementales son caros, como se publica datos completa. La aplicación permite en realidad para diferentes paquetes de datos a ser solicitados (y el contador de generación podría prevenir el tráfico de datos innecesario), pero los paquetes de datos diseñados inicialmente son muy grandes. Cortándolas fue una idea de último momento, pero funciona bien.
• Es necesario un verdadero buen mecanismo de generación. El uno inicialmente implementado chocado con cambios iniciales (que necesitan un manejo especial - ver "actualizaciones incrementales") y la agregación de cambios
• la necesidad de que los datos que viajan a el árbol fue subestimado en gran medida.
• publicar es barato sólo cuando el nodo ofrece acceso a los datos actuales de sólo lectura. Esto podría requerir la sincronización de actualización adicional, aunque
• a veces quieres nodos intermedios para actualizar, incluso cuando todas las hojas están inactivos
• algunas hojas terminaron la implementación de votación, algunos nodos de base terminaron confiar en eso. feo.

---

Generalmente:

Data-pull "se siente" más originaria de mí cuando los datos y la capa de procesamiento deben saber nada acerca de la interfaz de usuario. Sin embargo, se requiere un cambio complejo notificatin mecanismo para evitar "Actualización del universo".

Los datos push-simplifica las actualizaciones incrementales, pero sólo si el remitente conoce íntimamente el receptor.

No tengo experiencia de escala similar usando otros modelos, por lo que no puedo hacer una recomendación. Mirando hacia atrás, veo que he utilizado en su mayoría de extracción, que era menos de una molestia. Sería interesante ver las experiencias de otras personas.

Answer 2

Yo trabajo en una biblioteca de procesamiento de imagen pura-pull. Es más orientado a las operaciones de tipo de lote, si no tenemos que lidiar con las entradas dinámicas y por eso parece que funciona muy bien. Tire funciona especialmente bien para grandes conjuntos de datos y para el roscado:. Escalamos linealmente a al menos 32 CPUs (dependiendo de la gráfica que se está evaluando, por supuesto, je)

Tenemos una interfaz gráfica de usuario que permite a las hojas sean fuentes de datos dinámicos (por ejemplo, una cámara de vídeo entrega de marcos) y que son manejados por tirar y reconstruir las partes pertinentes de la gráfica de un cambio. Esta es barato en nuestro caso, así que la pérdida no es tan alto.