MapReduce usando SQL Server como fuente de datos

Question

Actualmente estoy investigando la posibilidad de utilizar MapReduce para mantener construcciones de vistas incrementales en SQL Server.

Básicamente, use MapReduce para crear vistas materializadas.

Estoy un poco atascado atm. pensando en cómo particionar mis salidas map. Ahora, realmente no tengo una situación BigData, con aproximadamente 50 GB siendo el máximo, pero tengo una gran complejidad y una especie de problemas de rendimiento implícitos. Quiero ver si este enfoque mío MapReduce/NoSQL podría funcionar.

Lo que pasa con MapReduce por el que estoy teniendo problemas es el particionamiento. Como utilizo SQL Server como fuente de datos, la ubicación de los datos no es realmente un problema mío y, por lo tanto, no necesito enviar datos por todos lados, sino que cada trabajador debería poder recuperar una partición de los datos. base en la definición map.

Tengo la intención de mapear completamente los datos mediante el uso de LINQ y tal vez algo como Entity Framework, solo para proporcionar una interfaz familiar, esto es algo más que el punto, pero es la ruta actual que estoy explorando.

Ahora, ¿cómo puedo dividir mis datos? Tengo una clave principal, tengo map y reduce definiciones en términos de árboles de expresión (AST, si no está familiarizado con LINQ).

• En primer lugar, ¿cómo puedo encontrar una manera para mí para dividir la entrada completa y dividir el problema inicial (estoy pensando que debería ser capaz de aprovechar los agregados ventana en SQL Server como ROW_NUMBER y TILE).

• En segundo lugar, y más importante aún, ¿cómo me aseguro de hacerlo de forma incremental? Es decir, si agrego o realizo un cambio al problema original, ¿cómo me aseguro efectivamente de que minimizo la cantidad de recalculaciones que deben realizarse?

He estado buscando en CouchDB para la inspiración y que parecen tener una manera de hacer esto, pero ¿cómo puedo aprovechar algunos de que la bondad utilizando SQL Server?

Answer 1

Me enfrento a algo similar. Creo que debes olvidarte de las funciones de ventana ya que hace que tu proceso sea serializado. En otras palabras, todos los trabajadores estarán esperando la consulta.

Lo que hemos probado y está 'funcionando' es dividir los datos en más tablas (cada mes tiene sus tablas x) y ejecutar subprocesos analíticos separados en dichas particiones. Marcar datos procesados ​​/ no procesados ​​/ posiblemente malos/etc. después de Reducir.

Las pruebas con una tabla con particiones trajo como problemas de escalas de bloqueo ..

Definitivamente, usted agrega un poco más de complejidad a la solución actual.