¿Cómo/Puedo usar linq a xml para consultar archivos xml enormes con un consumo de memoria razonable?

Question

No he hecho mucho con linq a xml, pero todos los ejemplos que he visto cargan todo el documento XML en la memoria.

¿Qué pasa si el archivo XML es, digamos, 8GB, y realmente no tiene la opción?

Mi primer pensamiento es utilizar el XElement.Load Method (TextReader) en combinación con una instancia del FileStream Class.

PREGUNTA: ¿Esto funcionará, y es esta la manera correcta de abordar el problema de buscar un archivo XML muy grande?

Nota: no se requiere un alto rendimiento ... estoy tratando de obtener linq a xml para básicamente hacer el trabajo del programa que podría escribir que recorre cada línea de mi archivo grande y se reúne, pero desde linq es "loop centric" Espero que esto sea posible ...

Answer 1

Al usar XElement.Load se cargará todo el archivo en la memoria. En su lugar, use XmlReader con la función XNode.ReadFrom, donde puede cargar selectivamente las notas encontradas por XmlReader con XElement para un procesamiento posterior, si es necesario. MSDN tiene un muy buen ejemplo haciendo precisamente eso: http://msdn.microsoft.com/en-us/library/system.xml.linq.xnode.readfrom.aspx

Si tan solo necesita buscar el documento xml, será suficiente con XmlReader y no cargará todo el documento en la memoria.

Answer 2

Gabriel,

Tío, esto no responde exactamente a su pregunta real (Cómo leer grandes documentos XML utilizando LINQ ), pero es posible que desee pago my vieja pregunta What's the best way to parse big XML documents in C-Sharp. La última "respuesta" (en el tiempo) fue una "nota para sí mismo" sobre lo que realmente funcionó. Resulta que un documento híbrido-XmlReader & doclet-XmlSerializer es rápido (suficiente) Y flexible.

PERO tenga en cuenta que estaba tratando con documentos de hasta 150 MB. Si REALMENTE tiene que manejar documentos tan grandes como 8GB? entonces supongo que es probable que encuentres todo tipo de problemas; incluyendo problemas con el manejo de LARGE_FILE (> 2GB) de O/S ... en cuyo caso le sugiero encarecidamente que mantenga las cosas lo más primitivas posible ... y XmlReader sea lo más primitivo posible (y EL más rápido según mis pruebas) XML-parser disponible en el espacio de nombres de Microsoft.

También: Acabo de notar un comentario tardío en mi viejo hilo sugiriendo que eche un vistazo a VTD-XML ... lo eché un vistazo rápido ahora ... parece "prometedor", incluso si el autor parece haber contraído un caso terminal de FIGJAM. Él afirma que manejará documentos de hasta 256 GB; a lo que respondo "Sí, ¿lo has probado? ¿En qué entorno?" Aunque parece que debería funcionar ... He utilizado esta misma técnica para implementar "hipervínculos" en un sistema de ayuda textual; de vuelta antes de HTML.

De todos modos buena suerte con esto, y su proyecto en general. Aclamaciones. Keith.

Answer 3

Me doy cuenta de que esta respuesta podría considerarse no receptiva y posiblemente molesta, pero diría que si tiene un archivo XML de 8GB, entonces al menos algo de lo que intenta hacer en XML debería hacerse por el sistema de archivos o la base de datos.

Si tiene trozos grandes de texto en ese archivo, puede almacenarlos como archivos individuales y almacenar los metadatos y los nombres de archivo por separado. Si no lo hace, debe tener muchos niveles de datos estructurados, probablemente con mucha repetición de las estructuras.Si puede decidir qué se considera un "registro" individual que puede almacenarse como un archivo XML más pequeño o en una columna de una base de datos, entonces puede estructurar su base de datos en función de los niveles de anidación que aparecen arriba. XML es ideal para pequeños y sucios, también es bueno para datos bastante desestructurados ya que es autoestructurante. Pero si tiene 8 GB de datos con los que va a hacer algo significativo, debe (por lo general) contar con alguna estructura predecible en algún lugar.

El almacenamiento de XML (o JSON) en una base de datos, y la consulta y búsqueda de registros XML, y dentro del XML es bien soportado hoy en día tanto por material SQL como por el paradigma NoSQL.

Por supuesto, es posible que no tenga la opción de no utilizar archivos XML tan grandes, o podría tener alguna situación en la que realmente son la mejor solución. Pero para algunas personas que leen esto podría ser útil mirar esta alternativa.