MapReduce utilizzando SQL Server come origine dati

Question

Attualmente sto studiando la possibilità di utilizzare MapReduce per conservare build di visualizzazioni incrementali in SQL Server.

In pratica, utilizzare MapReduce per creare viste materializzate.

Sono un po 'bloccato. pensando a come partizionare le mie uscite map. Ora, in realtà non ho una situazione BigData, con circa 50 GB al massimo ma ho un sacco di complessità e problemi di prestazioni implicite. Voglio vedere se questo mio approccio MapReduce/NoSQL potrebbe emergere.

La cosa su MapReduce I problemi con cui sto attualmente avendo a che fare con il partizionamento. Dato che sto usando SQL Server come origine dati, la localizzazione dei dati non è davvero un mio problema e quindi non ho bisogno di inviare dati ovunque, piuttosto, ogni lavoratore dovrebbe essere in grado di recuperare una partizione dei dati base sulla definizione map.

ho intenzione di mappare completamente i dati attraverso l'uso di LINQ e forse qualcosa di simile Entity Framework, solo per fornire un'interfaccia familiare, questo è un po oltre il punto, ma è il percorso corrente che sto esplorando.

Ora, come divido i miei dati? Ho una chiave primaria, ho le definizioni map e reduce in termini di alberi di espressione (AST, se non hai familiarità con LINQ).

• In primo luogo, come faccio a trovare un modo per me di dividere l'intero input e partizionamento il problema iniziale (sto pensando dovrei essere in grado di sfruttare gli aggregati delle finestre in SQL Server come ROW_NUMBER e TILE).

• In secondo luogo e, cosa più importante, come faccio ad assicurarmi di farlo in modo incrementale? Cioè, se aggiungo, o apporto una modifica al problema originale, come faccio a garantire in modo efficace che io riduca al minimo la quantità di re-computazioni che devono essere eseguite?

Sono stato a guardare CouchDB per l'ispirazione e che sembrano avere un modo per fare questo, ma come faccio a sfruttare alcuni di quella bontà utilizzo di SQL Server?

Answer 1

Sono di fronte a qualcosa di simile. Penso che dovresti dimenticare le funzioni di windowing in quanto rende serializzato il tuo processo. In altre parole, tutti i lavoratori saranno in attesa della richiesta.

Quello che abbiamo testato e 'funzionante' è quello di partizionare i dati in più tabelle (ogni mese ha le sue tabelle x) ed eseguire thread analitici separati su tali partizioni. Contrassegnare i dati elaborati/non elaborati/eventualmente negativi/ecc. Dopo Riduzione.

Prove con una tabella partizionata portato in problemi di blocco di escalation ..

Avrete sicuramente aggiungere un po 'di più la complessità alla soluzione attuale.