Restituisce in modo asincrono un dato gerarchico usando .NET TPL ... come dovrebbe apparire il mio oggetto "look"?

Question

Restituisce in modo asincrono un dato gerarchico usando .NET TPL ... come dovrebbe apparire il mio oggetto "look"?

#1 da (2 voti)

6

Voglio usare il TPL .NET per fare in modo asincrono un DIR /S e cercare ogni sottodirectory su un disco rigido, e voglio cercare una parola in ogni file ... come dovrebbe essere la mia API?

In questo scenario, so che ogni sottodirectory avrà 0,10000 file o 0 ... 10000 directory. So che l'albero non è bilanciato e desidera restituire i dati (in relazione alla sua posizione nella gerarchia) non appena disponibili. Sono interessato a ottenere i dati il più rapidamente possibile, ma voglio anche aggiornare quel risultato se vengono trovati dati "migliori" (meglio significa più vicino alla radice di c:)

Potrei anche essere interessato a trovare tutte le partite in relazione alla sua posizione nella gerarchia. (simile a un rapporto)

Question:

How should I return data to my caller?

La mia prima ipotesi è che penso di aver bisogno di un oggetto condiviso che manterrà lo "stato" corrente del traversal (avviato | notstarted | complete) e potrebbe basarlo su System.Collections.Concurrent .

Un'altra idea che sto prendendo in considerazione è il modello consumatore / produttore (che può essere gestito da ConcurrentCollections), ma non sono sicuro di come gli oggetti "assomigliano".

Vincolo logico opzionale: l'API non deve occuparsi di questo, ma nel mio progetto "mondo reale", se una directory contiene file, solo un file conterrà mai la parola che sto cercando. Se qualcuno dovesse letteralmente fare un DIR /S come descritto sopra, avrebbe bisogno di tenere conto di più di un file corrispondente per sottodirectory.

Ulteriori informazioni :

Uso le tabelle di Azure per archiviare una gerarchia di dati utilizzando questi metodi di estensione TPL . Un "nodo" è una tabella. Non solo ogni nodo della gerarchia ha una relazione con un numero qualsiasi di nodi, ma è possibile che ogni nodo abbia un collegamento reciproco su qualsiasi altro nodo. Questo potrebbe avere problemi con la ricorsione, ma sto affrontando ciò con un oggetto condiviso nel mio ciclo di ricorsione.

Si noti che ogni "nodo" ha anche la capacità di memorizzare dati locali unici per quel nodo. Sono queste informazioni che sto cercando. In altre parole, sto cercando uno specifico RowKey fisso in una gerarchia di nodi.

Quando cerco il RowKey fisso nella gerarchia, sono interessato a ottenere i risultati VELOCE (primo nodo trovato) ma preferisco i dati che sono "più vicini" al punto di partenza della gerarchia.

Dal momento che molti nodi possono avere il RowKey particolare a cui sono interessato, a volte potrei voler ottenere un report di TUTTI i nodi che contengono questo RowKey.

api async parallel-programming azure

posta random65537 20.11.2012 - 16:32

fonte

1 risposta

Leggi altre domande sui tag api async parallel-programming azure

C'è sempre un tempo ragionevole per far testare i dispositivi di prova nella costruzione del controller MVC3? REST: come memorizzare e riutilizzare le query di chiamata REST

score 2 · Answer 1

Quindi vorrei dividerlo in due fasi: la directory list / traversal e la funzione di ricerca.

L'elenco / attraversamento è un classico nodo del nodo dell'albero e c'è un esempio di esempi per risolvere il problema. Quello che abbiamo fatto per risolvere questo problema è identificare prima gli strati superiori; recuperalo; quindi lavorare sui recuperi all'interno degli strati inferiori. L'approccio si presta bene alla ricorsione e si finisce con un codice ristretto.

Vorrei usare un modello skip / take e prelevare una quantità inferiore per ogni richiesta. Ciò contribuirà a mantenere la richiamata aperta / in attesa mentre è in corso l'attraversamento.

Per una struttura API ... Vorrei esporre una singola funzione per recuperare la struttura. Quella funzione fornirà il callback (s) alla funzione di chiamata e fungerà essenzialmente da buffer per le effettive funzioni di attraversamento. A seconda delle prestazioni dell'elenco, è ora possibile spostarlo facilmente in un modello di attraversamento parallelo e accelerare le cose. .NET 4 e 4.5 hanno alcuni miglioramenti piuttosto chiari per la parallelizzazione.

Il modo in cui si vuole passare indietro la struttura ad albero dipende da cosa si sta utilizzando per l'interfaccia utente. Scegli una struttura dati che giochi bene con i tuoi componenti dell'interfaccia utente.

La funzione di ricerca sarebbe una seconda chiamata, ma dovrebbe essere in grado di fare affidamento su | rispecchiare alcune delle funzioni create con l'elenco delle directory. Dal momento che hai la libertà di scegliere il tuo ordine di ricerca ora (cioè, stai controllando da dove inizia in base alla lista delle directory) puoi cercare preferenzialmente le posizioni più vicine alla radice.

Qui, probabilmente creerei due chiamate nell'API o sovraccaricherei solo uno. Il sovraccarico sarebbe il controllo per ottenere il primo, armadio per l'istanza di root o per ottenerli tutti. Per inciso, considera come vuoi gestire più hit alla stessa profondità da root.

Infine, a seconda di quanto performante è l'elenco, potresti prendere in considerazione una qualche forma di memorizzazione nella cache delle strutture di directory. Non dovrebbe essere così costoso da conservare in memoria, ma dovrebbe risparmiare un po 'di tempo evitando l'IO ridondante.