Xml o Sqlite, cuándo soltar Xml para una base de datos?

Realmente me gusta Xml para guardar datos, pero ¿cuándo se convierte sqlite / database en la mejor opción? por ejemplo, cuando el xml tiene más de x elementos o es mayor que y MB?

Estoy codificando un lector de RSS y creo que tomé la decisión equivocada al usar xml en una base de datos sqlite para almacenar un caché de todos los elementos de fonts. Hay algunos feeds que tienen un archivo xml de ~ 1mb después de un mes, otro tiene más de 700 elementos, mientras que la mayoría solo tiene ~ 30 elementos y tienen un tamaño de ~ 50kb después de varios meses.

Actualmente no tengo planes de implementar un límite porque me gusta poder buscar a través de todo.

Entonces, mis preguntas son:

  1. ¿Cuándo se justifica la sobrecarga de sqlite / databases sobre el uso de xml?
  2. ¿Son suficientes los pocos archivos XML grandes para justificar la base de datos cuando hay muchos pequeños , aunque incluso los pequeños crecerán con el tiempo? ( mucho tiempo)

actualizado (más información)

Cada vez que se selecciona un feed en la GUI, recargo todos los elementos de ese archivo xml de fonts.

También necesito modificar el estado de lectura / no leída que parece realmente raro cuando recorro todos los nodos en el xml para encontrar el elemento y luego lo configuro para leer / no leer.

Básicamente estoy de acuerdo con Mitchel , que esto puede ser muy específico dependiendo de qué vas a hacer con XML / sqlite. Para su caso (caché), me parece que usar sqlite (u otros dbs incrustados) tiene más sentido.

Primero, realmente no creo que sqlite necesite más sobrecarga que XML. Y me refiero tanto a la sobrecarga de tiempo de desarrollo como a la sobrecarga en tiempo de ejecución. El único problema es que tiene una dependencia de la biblioteca sqlite. Pero dado que necesitaría alguna biblioteca para XML de todos modos, no importa (supongo que el proyecto está en C / C ++).

Ventajas de sqlite sobre xml:

  • todo en un archivo,
  • la pérdida de rendimiento es menor que XML a medida que la memoria caché se hace más grande,
  • puede mantener metadatos de feed separados de la caché en sí (otra tabla), pero accesibles de la misma manera,
  • SQL es probablemente más fácil de trabajar que XPath para la mayoría de las personas.

Desventajas de sqlite:

  • puede ser problemático con múltiples procesos accediendo a la misma base de datos (probablemente no sea su caso),
  • deberías saber al menos SQL básico. A menos que haya cientos de miles de elementos en el caché, no creo que deba optimizarlo mucho,
  • tal vez de alguna manera puede ser más peligroso desde el punto de vista de seguridad (inyección SQL). Por otro lado, no está codificando la aplicación web, por lo que esto no debería suceder.

Otras cosas están a la par para ambas soluciones, probablemente.

Para resumir, responde a sus preguntas, respectivamente:

  1. No lo sabrás, a menos que pruebes tu aplicación específica con ambos backends. De lo contrario, siempre es solo una suposición. La compatibilidad básica para ambas memorias caché no debería ser un problema para el código. Luego compara y compara.

  2. Debido a la forma en que se organizan los archivos XML, las búsquedas en sqlite siempre deben ser más rápidas (salvo en algunos casos de esquina donde no importa de todos modos porque es tremendamente rápido). Acelerar las búsquedas en XML requeriría una base de datos indexada de todos modos, en su caso eso significaría tener memoria caché para el caché, lo que no es una buena idea. Pero con sqlite puede indexar como parte de la base de datos.

Hombre, tengo experiencia con esto Trabajo en un proyecto donde originalmente almacenamos todos nuestros datos usando XML, luego lo trasladamos a sqlite. Existen muchos pros y contras para cada tecnología, pero fue el rendimiento el que causó el cambio. Esto es lo que observamos.

Para bases de datos pequeñas (algunas megas o más pequeñas), XML era mucho más rápido y más fácil de manejar. Nuestros datos se encontraban naturalmente en un formato de árbol, lo que hizo que XML fuera mucho más atractivo, y XPATH nos permitió hacer muchas consultas en una línea simple en lugar de tener que caminar por un árbol de ascendencia.

Estábamos progtwigndo en un entorno Win32 y usamos la biblioteca DOM estándar de Microsoft. Cargamos todos los datos en la memoria, los analizamos en un árbol dom y buscamos, agregamos, modificamos en la copia de la memoria. Periódicamente guardaríamos los datos y necesitaríamos rotar copias en caso de que la máquina se bloqueara en medio de una escritura.

También necesitábamos crear algunos “índices” a mano usando mapas de árbol C ++. Esto, por supuesto, sería trivial para hacer con sql.

Tenga en cuenta que el tamaño de los datos en el sistema de archivos fue un factor de 2-4 más pequeño que el árbol dom “en memoria”.

Cuando los datos llegaron al tamaño de 10M-100M, comenzamos a tener problemas reales. Curiosamente, en todos los tamaños de datos, el procesamiento XML fue mucho más rápido de lo que resultó ser sqlite (¡porque estaba en la memoria, no en el disco duro)! El problema en realidad era doble: primero, el tiempo de carga realmente comenzó a ser largo. Tendríamos que esperar un minuto más o menos antes de que los datos estuvieran en la memoria y se construyeran los mapas. Por supuesto, una vez cargado el progtwig fue muy rápido. El segundo problema fue que toda esta memoria estaba atada todo el tiempo. Los sistemas con solo unos pocos cientos de megas no responderían en otras aplicaciones aunque corriéramos muy rápido.

En realidad buscamos usar una base de datos xml basada en el sistema de archivos. Hay un par de versiones abiertas de bases de datos XML, las probamos. Nunca intenté usar una base de datos xml comercial, así que no puedo comentar sobre ellos. Desafortunadamente, nunca pudimos lograr que las bases de datos xml funcionaran bien. Incluso el acto de poblar la base de datos con cientos de megagramos de xml tomó horas … Tal vez lo estábamos usando incorrectamente. Otro problema fue que estas bases de datos eran bastante pesadas. Requerían Java y tenían una architecture de servidor cliente completa. Nos dimos por vencidos con esta idea.

Encontramos sqlite entonces. Solucionó nuestros problemas, pero a un precio. Cuando inicialmente conectamos sqlite, los problemas de memoria y tiempo de carga desaparecieron. Desafortunadamente, dado que todo el procesamiento se realizó ahora en el disco duro, la carga de procesamiento de fondo aumentó. Aunque antes ni siquiera notamos la carga de la CPU, ahora el uso del procesador estaba muy avanzado. Necesitábamos optimizar el código y aún así mantener algunos datos en la memoria. También necesitábamos reescribir muchas consultas XPATH simples como complicados algoritmos multiquery.

Entonces aquí hay un resumen de lo que aprendimos.

  1. Para los datos de árbol, XML es mucho más fácil de consultar y modificar mediante XPATH.

  2. Para conjuntos de datos pequeños (menos de 10 M), XML reventó sqlite en rendimiento.

  3. Para grandes conjuntos de datos (más de 10M-100M), el tiempo de carga XML y el uso de la memoria se convirtieron en un gran problema, hasta el punto de que algunas computadoras se vuelven inutilizables.

  4. No pudimos obtener ninguna base de datos xml de fuente abierta para solucionar los problemas asociados con grandes conjuntos de datos.

  5. SQLITE no tiene los problemas de memoria de XML dom, pero generalmente es más lento en el procesamiento de los datos (está en el disco duro, no en la memoria). (Nota: las tablas sqlite se pueden almacenar en la memoria, quizás esto lo haría tan rápido … No probamos esto porque queríamos sacar los datos de la memoria).

  6. Almacenar y consultar datos de árbol en una tabla no es agradable. Sin embargo, administrar las transacciones y la indexación lo compensa parcialmente.

No olvide que tiene una gran base de datos a su scope: ¡el sistema de archivos!

Muchos progtwigdores olvidan que una estructura decente de archivos de directorio es / tiene:

  1. Es rápido como el infierno
  2. Es portátil
  3. Tiene una pequeña huella de tiempo de ejecución

La gente está hablando de dividir archivos XML en múltiples archivos XML … Consideraría dividir tu XML en múltiples directorios y múltiples archivos de texto claro.

Darle una oportunidad. Es refrescantemente rápido.

No usaría XML para almacenar elementos RSS. Un lector de feeds realiza actualizaciones constantes a medida que recibe datos.

Con XML, primero debe cargar los datos del archivo, analizarlos y luego almacenarlos para facilitar su búsqueda / recuperación / actualización. Suena como una base de datos …

Además, ¿qué sucede si su aplicación falla? si usa XML, qué estado son los datos en el archivo XML frente a los datos en la memoria. Al menos con SQLite obtienes atomicidad, por lo que estás seguro de que tu aplicación comenzará con el mismo estado que cuando se realizó la última escritura en la base de datos.

XML se utiliza mejor como formato de intercambio cuando necesita mover datos desde su aplicación a otro lugar o compartir información entre aplicaciones. Una base de datos debe ser el método preferido de almacenamiento para casi cualquier aplicación de tamaño.

  1. Use XML para datos que la aplicación debe conocer: configuración, registro y otras cosas.
  2. Usar bases de datos (oracle, servidor SQL, etc.) para datos con los que el usuario interactúa directa o indirectamente – datos reales
  3. Use SQLite si los datos del usuario son más bien una colección serializada, como una enorme lista de archivos y su contenido o colección de elementos de correo electrónico, etc. SQLite es bueno en eso.

Depende del tipo y el tamaño de los datos.

¿Cuándo se debe usar XML para la persistencia de datos en lugar de una base de datos? Casi nunca. XML es un lenguaje de transporte de datos. Es lento de analizar y difícil de consultar. Analice el XML (¡no lo triture!) Y convierta los datos resultantes en objetos de dominio. Luego persiste los objetos de dominio. Una gran ventaja de una base de datos para persistencia es SQL, lo que significa consultas no estructuradas y acceso a herramientas comunes y técnicas de optimización.

Para mí, realmente depende de lo que esté haciendo con ellos, cuántos usuarios / procesos necesitan acceder a ellos al mismo tiempo, etc.

Trabajo con archivos XML grandes todo el tiempo, pero son procesos únicos, importan elementos de estilo, que el multiusuario o el rendimiento no son realmente necesarios.

ASÍ QUE realmente es un equilibrio.

Si necesita escalar en algún momento, use las bases de datos.

XML es bueno para almacenar datos que no están completamente estructurados y normalmente desea intercambiarlos con otra aplicación. Prefiero usar una base de datos SQL para datos. XML es propenso a errores ya que puede causar errores sutiles debido a errores u omisiones en los datos. Algunos marcos de aplicaciones de código abierto usan demasiados archivos xml para configuración, datos, etc. Prefiero tenerlo en SQL.

Como usted solicita una regla empírica, yo diría que utilice datos de aplicaciones basados ​​en XML, configuración, etc., si va a configurarlo una vez y no accederá / buscará mucho. Para búsquedas y actualizaciones activas, lo mejor es ir con SQL.

Por ejemplo, un servidor web almacena datos de aplicaciones en un archivo XML y realmente no necesita realizar búsquedas complejas ni actualizar el archivo. El servidor web se inicia, lee el archivo xml y eso es todo. Entonces XML es perfecto aquí. Supongamos que usa un marco como Struts. Necesita usar XML y las configuraciones de acción no cambian mucho una vez que la aplicación se desarrolla e implementa. Entonces, de nuevo, el archivo XML es una buena manera. Ahora, si su aplicación desarrollada Struts permite búsquedas y actualizaciones extensas, eliminaciones, entonces SQL es la forma óptima.

Por supuesto, seguramente conocerá a uno o dos desarrolladores en su organización que entonarán solo XML o SQL y proclamarán XML o SQL como el único camino a seguir. Tenga cuidado con esa gente y haga lo que ‘se siente’ correcto para su aplicación. No sigas una ‘religión tecnológica’.

Piense en la frecuencia con la que necesita actualizar los datos, la frecuencia con la que debe buscar los datos. Luego tendrá su respuesta sobre qué usar: XML o SQL.

He hecho el cambio a SQLite y me siento mucho mejor sabiendo que está en una base de datos.

Hay muchos otros beneficios de esto:

  • Agregar nuevos elementos es realmente simple
  • Ordenando por múltiples columnas
  • Eliminar duplicados con un índice único

Creé 2 vistas, una para elementos no leídos y otra para todos los artículos, no estoy seguro si este es el mejor uso de las vistas, pero realmente quería intentar usarlas.

También comparé el xml vs sqlite usando la clase StopWatch , y el sqlite es más rápido, aunque podría ser que mi forma de analizar archivos xml no era el método más rápido .

  1. Pequeños # elementos y tamaño (25 artículos, 30kb)
    • ~ 1.5 ms sqlite
    • ~ 8.0 ms xml
  2. Gran cantidad de artículos (700 artículos, 350kb)
    • ~ 20 ms sqlite
    • ~ 25 ms xml
  3. Tamaño de archivo grande (850 artículos, 1024kb)
    • ~ 45 ms sqlite
    • ~ 60 ms xml

Estoy de acuerdo con @Bradley.

XML es muy lento y no es especialmente útil como formato de almacenamiento. ¿Por qué molestarse? ¿Estarás editando los datos a mano usando un editor de texto? Si es así, XML aún no es un formato muy conveniente en comparación con algo como YAML. Con algo como SQlite, las consultas son más fáciles de escribir, y hay una API bien definida para ingresar y sacar datos.

XML está bien si necesita enviar datos entre progtwigs. Pero en nombre de la eficiencia, probablemente debería producir el XML en el momento del envío y analizarlo en “datos reales” en el momento de la recepción.

Todo lo anterior significa que su pregunta sobre “cuándo se justifica la sobrecarga de una base de datos” es un poco discutible. XML tiene una sobrecarga más alta, todo el tiempo, que SQlite. (Las bases de datos completas como MSSQL son más pesadas, especialmente en gastos generales administrativos, pero esa es una pregunta totalmente diferente).

XML se puede almacenar como texto y como un formato de archivo binario.

Si su objective principal es permitir que una computadora lea / escriba un formato de archivo de manera eficiente, debe trabajar con un formato de archivo binario.

Las bases de datos son una forma fácil de usar de almacenar y mantener datos. No son la forma más rápida de almacenar datos que es un formato de archivo binario.

Lo que puede acelerar las cosas es usar una base de datos en la memoria / tipo de base de datos. Sqlite tiene esta opción.

Y esta parece ser la mejor manera de hacerlo por ti.

Mi opinión es que debe usar SQLite (u otra base de datos incrustada apropiada) cada vez que no necesite un formato de archivo de texto puro. Tenga en cuenta que esta es una gran excepción. Hay muchos escenarios que requieren, o se benefician de, formatos de archivo de texto puro.

En lo que respecta a la sobrecarga, SQLite comstack algo así como 250 k con banderas normales. Muchas bibliotecas de análisis XML son más grandes que SQLite. No obtiene ganancias de concurrencia usando XML. El formato de archivo binario SQLite admitirá escrituras mucho más eficientes (en gran parte porque no se puede agregar al final de un archivo XML bien formateado). E incluso la lectura de datos, la mayoría de los cuales supongo que es un acceso bastante aleatorio, será más rápido con SQLite.

Y para colmo, tiene acceso a los beneficios de las transacciones e índices SQL.

Editar: se olvidó de mencionar. Un beneficio de SQLite (a diferencia de muchas bases de datos) es que permite cualquier tipo en cualquier fila en cualquier columna. Básicamente, con SQLite obtienes la misma libertad que tienes con XML en términos de tipos de datos. Esto también significa que no debe preocuparse por poner límites a las columnas de texto.

Debe tener en cuenta que muchos DB relacionales grandes (Oracle y SQLServer) tienen tipos de datos XML para almacenar datos dentro de una base de datos y usan XPath dentro de la statement SQL para obtener acceso a esos datos.

Además, existen bases de datos XML nativas que funcionan en gran medida como SQLite en el sentido de que son un archivo binario que contiene una colección de documentos (que podría ser una tabla), luego puede XPath / XQuery en un solo documento o toda la colección. Entonces, con una base de datos XML puede hacer cosas como almacenar datos de días como un documento XML separado en la colección … por lo que solo necesita usar ese documento cuando trate los datos de hoy. Pero escriba un XQuery para descubrir datos históricos sobre la colección de documentos para esa persona. Mancha.

He usado Berkeley XMLDB (ahora respaldado por Oracle). Hay otros si busca en google “Base de datos XML nativa”. No he visto un problema de rendimiento al almacenar / recuperar datos de esta manera.

XQuery es una bestia diferente (pero vale la pena aprender), sin embargo, es posible que solo pueda usar los XPath que usa actualmente con ligeras modificaciones.

Una base de datos es excelente como parte de su progtwig. Si consultar los datos es parte de su lógica comercial. XML es mejor como formato de archivo, especialmente si su formato de datos es:

1, Hierarchal
2, es probable que cambie en el futuro en formas que no se pueden adivinar
3, los datos van a vivir más tiempo que el progtwig

Digo que no es una cuestión de tamaño de datos, sino de tipo de datos. Si sus datos están estructurados , use una base de datos relacional. Si sus datos están semiestructurados , use XML o, si los montos de datos realmente crecen demasiado, una base de datos XML.

Si su búsqueda va con un db. Puede dividir los archivos xml en directorios para facilitar la búsqueda, pero la sobrecarga de administración se vuelve bastante pesada. También obtienes mucho más que rendimiento con un db sql …