Come per alimentare in modo efficiente FAST ESP con gigabyte di dati con .NET

Question

Questa sarà una domanda difficile, ma cercherò comunque: il nostro compito è quello di alimentare Microsoft FAST ESP con gigabyte di dati. L'importo finale dei dati indicizzati è da qualche parte nel quartiere di 50-60GB.

ha VELOCE un'API NET ma componenti principali sono scritti in Python (pipeline di elaborazione per indicizzare). La sfida è comunicare in modo affidabile sul sistema mentre alimentandola gigabyte di dati per l'indicizzazione.

I problemi che si presentano con il veloce qui sono:

1. il sistema è eccentrico quando è alimentato troppi dati contemporaneamente come vuole reindicizzare i dati durante il quale il sistema rimane irraggiungibile per ore. Inaccettabile.

2. non è un'opzione per la coda di tutti i dati e in serie alimentare una voce in un momento in quanto questo ci vorrà troppo tempo (diversi giorni).

3. quando un prodotto non può essere indicizzato da FAST il cliente deve ri-alimentare il articolo. Per questo al lavoro, il sistema dovrebbe chiamare un callback metodo per informare il cliente circa il fallimento. Tuttavia, ogni volta che il sistema viene interrotto il client di alimentazione è in grado di reagire al timeout perché quel callback non viene mai chiamato. Da qui il cliente sta morendo di fame. I dati si trova nella coda, ma non può essere passato insieme al sistema. Il coda crolla. I dati vengono persi. Si ottiene l'idea.

Note:

1. alimentano un elemento può richiedere secondi per un piccolo elemento e fino a 5-8 ore per un singolo elemento di grandi dimensioni.
2. gli elementi indicizzati si basano sia binari e di testo.
3. l'obiettivo è per la piena indicizzazione di prendere "solo" 48-72h, vale a dire che deve accadere durante il fine settimana.
4. Le tubazioni di elaborazione dei documenti VELOCE (codice Python) qui hanno circa 30 fasi ciascuno. Ci sono un totale di 27 condutture a partire da questa scrittura.

In sintesi:

La sfida principale è quello di alimentare il sistema con oggetti, grandi e piccoli, alla giusta velocità (non troppo veloce perché potrebbe crollare o correre in problemi di memoria; non troppo lento perché questo richiederà troppo tempo), contemporaneamente, in modo parallelo come fili asincrono in esecuzione. Nel mio parere ci deve essere un algoritmo che decide quando mangime quali elementi e quanti in una sola volta. Programmazione parallela viene in mente.

Ci potrebbe essere anche più "code" in cui ogni coda (processo) è dedicato alla alcune dimensioni elementi che vengono caricati in una coda e poi alimentati uno alla volta (in thread di lavoro).

Sono curioso di sapere se qualcuno ha mai fatto niente di simile, o come come si dovrebbe fare per un problema come questo.

EDIT: Anche in questo caso, non sto cercando di "fissare" FAST ESP o migliorare il suo interno lavorazioni. La sfida è quella di utilizzare efficacemente!

Answer 1

Sembra che si sta lavorando con una serie di problemi più di un problema specifico C # velocità di alimentazione.

Alcune domande sulla parte anteriore - è questi dati 60GB che da mangiare tutti i fine settimana o è un riempimento iniziale del sistema? Fa i dati esistono come voci del filesystem locale al ESP installare o elseware? Si tratta di una singola distribuzione ESP interna o una soluzione che stai cercando di replicare in più luoghi? nodo singolo installare o multipla (o meglio ... quanti - tetto unico nodo è 20 docprocs)?

prestazioni

??ESP è di solito limitata dal numero di documenti da trattare più rispetto al numero di file. Assumendo che l'intervalli di dati tra la dimensione dei dati di posta elettronica 35k e 350k dimensione del filesystem dati 60GB rappresentano tra il 180k documenti e documenti 1.8mil, per così feed che oltre 48 ore è necessario alimentazione tra il 3750 e il 37500 documenti all'ora. Non un target molto elevato su hardware moderno (se avete installato questo su una macchina virtuale ... beh ... tutte le scommesse sono spenti, sarebbe meglio su un computer portatile).

Per voi l'alimentazione hanno una scelta tra la codifica più veloce e più controllo sia con la gestione dei lotti alimentati da soli o utilizzando il framework DocumentFeeder nella api che astrae un sacco di logica batch. Se hai intenzione di 37.5k docs / hr mi piacerebbe risparmiare le spese generali e basta usare DocumentFeeder - anche se prendersi cura nelle sue params di configurazione. alimentatore di documenti vi permetterà di trattare i contenuti su una base per il documento, invece di creare i lotti da soli, sarà anche consentire una certa misura di ritentare automaticamente in base a config. obiettivo generale dovrebbe essere per un massimo di 50 MB di contenuti per batch o 100 documenti, quello che viene prima. Documenti più grandi dovrebbero essere inviati in lotti più piccoli ... quindi se avete un file di 50 MB, si dovrebbe idealmente essere inviato da sola, ecc Si potrebbe effettivamente perdere il controllo dei lotti formati da alimentatore di documenti ... quindi la logica là è un pò un massimo sforzo da parte del codice.

Utilizzare i callback per monitorare quanto bene il contenuto sta rendendo nel sistema. Impostare i limiti su quanti documenti sono stati alimentati che non hai ricevuto i richiami finali per ancora. Obiettivo dovrebbe essere per X lotti da presentare in qualsiasi momento oppure Y Mb, pausa alle due taglio. X dovrebbe essere di circa 20 + # di processori documento, Y dovrebbe essere nella zona di 500-1000Mb. Con alimentatore di documenti è solo un pass / fail per doc, con il sistema tradizionale è più dettagliato. aspettare solo per il 'assicurato' richiamata ... che è stato elaborato e sarà indicizzato dice ... in attesa che sia ricercabile è inutile.

Set alcuni limiti sui tuoi contenuti ... in generale ESP si rompe con file molto grandi, c'è un limite rigido a 2gb dal momento che è ancora a 32 bit procs, ma in realtà qualcosa di più di 50MB dovrebbe avere solo i metadati alimentato. Inoltre ... dati di log di alimentazione, evitare, sarà schiacciare le strutture interne, uccidendo perf se non erroring fuori. Le cose possono essere fatte in cantiere per modificare ciò che è ricercabile per alleviare il dolore di alcuni dati di log.

Anche bisogno di assicurarsi che il proprio indice è configurato per bene, almeno 6 partizioni con una particolare attenzione per mantenere quelle di ordine inferiore abbastanza vuoto. Difficile andare nei dettagli di quello senza sapere di più sulla distribuzione. Il config gasdotto può avere un grande impatto così ... nessun documento dovrebbe mai prendere 5-8 ore. Assicurarsi di sostituire eventuali fasi searchexport o htmlexport essere utilizzato con le istanze personalizzate con un timeout sana (30-60 sec.) - di default è nessun timeout

Ultimo punto ... le probabilità sono che non importa come la vostra alimentazione è configurato, il gasdotto errore fuori su alcuni documenti. Avrete bisogno di essere preparati per accettare che o Inserire di nuovo nell'alimentatore solo i metadati (ci sono altre opzioni, ma un pò al di fuori del campo di applicazione qui).

buona fortuna.

Answer 2

Prima di tutto, è necessario utilizzare i compiti per tale problema.
Possono essere avviati sync, async, nel pool di thread, ecc, e molto altro ancora più conveniente su memoria rispetto ai modelli con filo-bloccaggio.

Credo che, le Task.ContinueWith si adatta perfettamente per il vostro problema .

algoritmo simile a:

1. Raccogliere una coda con i dati è necessario pubblicare.
2. avviare un'attività (o compiti, se si è a rischio :) che prende l'oggetto più pesante dalla coda. (E il più piccolo oggetto dal lato opposto), e iniziare a caricarlo.
3. Creazione di un metodo per la fine del caricamento, che prenderà il via nuovo compito per il nuovo elemento della coda.
4. È possibile utilizzare cancellazione gettoni per i timeout.
5. Ogni volta che si può definire su quale oggetto l'errore di sistema get.

Answer 3

Si può semplicemente utilizzare BULK INSERT direttamente sul database? In caso contrario, io suggerisco di lavorare con il fornitore del prodotto di terze parti in modo che insieme si può formulare una soluzione praticabile.

Answer 4

La banca dati, come si potrebbe descriverli è inutilizzabile . Si potrebbe trovare un po 'di ricettivita' di lavoro, ma si verificheranno problemi di grandi simili in futuro. ~ 10GB prendere un giorno di trasferimento e suoni casuali reindicizzazione assurdo.

Il mio consiglio sarebbe quello di uno domanda proprio fornitore di ottenere il database in uno stato utilizzabile (correggere i bug), o che ti danno un estratto dei dati e si effettua il proprio databse.