Xml o Sqlite, ¿cuándo descartar Xml para una base de datos?
Realmente me gusta Xml para guardar datos, pero ¿cuándo sqlite/database se convierte 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 rss y creo que tomé la decisión incorrecta al usar xml en una base de datos sqlite para almacenar un caché de todos los elementos de feeds. 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 tiene un tamaño de ~ 50kb después de un varios meses.
Actualmente no tengo planes de implementar un límite porque me gusta poder buscar en todo.
Entonces, mis preguntas son:
- ¿Cuándo se justifica la sobrecarga de sqlite/bases de datos sobre el uso de xml?
- ¿Son pocos archivos xml grandes justificación suficiente para la base de datos cuando hay muchos pequeños, aunque incluso los pequeños crecerán con el tiempo? (un tiempo largo largo )
actualizado (más información)
Cada vez que se selecciona un feed en la GUI, recargo todos los elementos de ese archivo xml de feeds.
También necesito modificar el estado de lectura/no leído, lo que parece realmente extraño cuando recorro todos los nodos en el xml para encontrar el elemento y luego configurarlo como leído/no leído.
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 integrados) tiene más sentido.
Primero, realmente no creo que sqlite necesite más sobrecarga que XML. Y me refiero tanto a la sobrecarga del tiempo de desarrollo como a la sobrecarga del tiempo de ejecución. El único problema es que depende 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 el caché se hace más grande,
- puede mantener los metadatos del feed separados del caché (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 que acceden 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 la memoria caché, no creo que deba optimizarlo demasiado,
- quizás de alguna manera puede ser más peligroso desde el punto de vista de la seguridad (inyección SQL). Por otro lado, no está codificando una aplicación web, por lo que esto no debería suceder.
Otras cosas están a la par para ambas soluciones probablemente.
Para resumir, respuestas a sus preguntas respectivamente:
No lo sabrá, a menos que pruebe su aplicación específica con ambos backends. De lo contrario, siempre es solo una suposición. El soporte básico para ambas cachés no debería ser un problema para codificar. Luego, compara y compara.
Debido a la forma en que se organizan los archivos XML, las búsquedas en sqlite siempre deberían ser más rápidas (salvo algunos casos de esquina donde no importa de todos modos porque es increíblemente rápido). Acelerar las búsquedas en XML requeriría una base de datos de índice de todos modos, en su caso eso significaría tener caché para caché, no es una idea particularmente buena. Pero con sqlite puede tener indexación 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 nos mudamos a sqlite. Hay muchas ventajas y desventajas de cada tecnología, pero fue el rendimiento lo que causó el cambio. Aquí está lo que observamos.
Para bases de datos pequeñas (algunas meg o más pequeñas), XML fue mucho más rápido y más fácil de manejar. Nuestros datos estaban naturalmente en un formato de árbol, lo que hacía 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 programando en un entorno Win32 y utilizamos la biblioteca estándar de Microsoft DOM. Cargaríamos todos los datos en la memoria, los analizaríamos en un árbol dom y buscaríamos, agregaríamos, modificaríamos la copia en memoria. Periódicamente guardamos los datos y necesitábamos rotar las copias en caso de que la máquina se bloqueara en medio de una escritura.
También necesitábamos construir algunos "índices" a mano usando mapas de árbol C++. Esto, por supuesto, sería trivial con sql.
Tenga en cuenta que el tamaño de los datos en el sistema de archivos fue un factor de 2-4 menor que el árbol de 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 era en realidad doble: primero, el tiempo de carga realmente comenzó a alargarse. 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 programa fue muy rápido. El segundo problema era que toda esta memoria estaba atada todo el tiempo. Los sistemas con solo unos pocos cientos de megas no responderían en otras aplicaciones a pesar de que funcionamos muy rápido.
De hecho, estamos buscando usar una base de datos xml basada en un sistema de archivos. Hay un par de bases de datos xml de versiones de código abierto, las probamos. Nunca he tratado de usar una base de datos comercial xml, así que no puedo comentar sobre ellos. Desafortunadamente, nunca pudimos lograr que las bases de datos xml funcionen bien. Incluso el acto de poblar la base de datos con cientos de meg de xml tomó horas ... Tal vez lo estábamos usando incorrectamente. Otro problema era que estas bases de datos eran bastante pesadas. Requerían Java y tenían una arquitectura de servidor de cliente completa. Renunciamos a 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 en segundo plano aumentó. Mientras que antes ni siquiera notábamos la carga de la CPU, ahora el uso del procesador era muy alto. Necesitábamos optimizar el código, y aún necesitábamos mantener algunos datos en la memoria. También necesitábamos reescribir muchas consultas XPATH simples como algoritmos complicados de múltiples consultas.
Así que aquí hay un resumen de lo que aprendimos.
Para los datos de árbol, XML es mucho más fácil de consultar y modificar con XPATH.
Para conjuntos de datos pequeños (menos de 10M), XML superó el rendimiento de sqlite.
Para grandes conjuntos de datos (mayores de 10M-100M), el tiempo de carga XML y el uso de memoria se convirtió en un gran problema, hasta el punto de que algunas computadoras se vuelven inutilizables.
No pudimos obtener ninguna base de datos xml de código abierto para solucionar los problemas asociados con grandes conjuntos de datos.
SQLITE no tiene los problemas de memoria de XML dom, pero generalmente es más lento en el procesamiento de datos (está en el disco duro, no en la memoria). (nota: las tablas sqlite se pueden almacenar en la memoria, tal vez esto lo haría tan rápido ... No lo intentamos porque queríamos sacar los datos de la memoria).
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 excelente base de datos a su alcance: ¡el sistema de archivos!
Muchos programadores olvidan que una estructura decente de archivos de directorio es/tiene:
- Es rápido como el infierno
- Es portátil
- Tiene una pequeña huella de tiempo de ejecución
La gente habla de dividir archivos XML en múltiples archivos XML ... Consideraría dividir su XML en múltiples directorios y múltiples archivos de texto sin formato.
Darle una oportunidad. Es refrescantemente rápido.
- Utilice XML para los datos que la aplicación debe conocer: configuración, registro y lo que no.
- Utilice bases de datos (Oracle, SQL Server, etc.) para los datos con los que el usuario interactúa directa o indirectamente: datos reales
- Use SQLite si los datos del usuario son más de una colección serializada, como una gran 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.
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 una fácil 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 tienen los datos en el archivo XML versus 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 de la base de datos.
XML se utiliza mejor como formato de intercambio cuando necesita mover datos de su aplicación a otro lugar o compartir información entre aplicaciones. Una base de datos debería ser el método preferido de almacenamiento para aplicaciones de casi cualquier tamaño.
¿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 para analizar e incómodo para consultar. Analice el XML (¡no lo triture!) Y convierta los datos resultantes en objetos de dominio. Luego persisten los objetos de dominio. Una ventaja importante de una base de datos para la persistencia es SQL, que significa consultas no estructuradas y acceso a herramientas comunes y técnicas de optimización.
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
- Ordenar por múltiples columnas
- Eliminar duplicados con un índice único
He creado 2 vistas, una para elementos no leídos y otra para todos los elementos, no estoy seguro de 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 .
- # artículos pequeños y tamaño (25 artículos, 30kb)
- ~ 1.5 ms sqlite
- ~ 8.0 ms xml
- Gran cantidad de artículos (700 artículos, 350kb)
- ~ 20 ms sqlite
- ~ 25 ms xml
- Tamaño de archivo grande (850 elementos, 1024 kb)
- ~ 45 ms sqlite
- ~ 60 ms xml
Si alguna vez necesita escalar, use bases de datos.
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 un solo proceso, importan elementos de estilo, que el multiusuario o el rendimiento no son realmente necesarios.
Así que realmente es un equilibrio.
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 tipográficos 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.
Dado que solicita una regla general, le diría que use datos de aplicación 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, actualice 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. Debe usar XML y las configuraciones de acción no cambian mucho una vez que la aplicación se desarrolla e implementa. De nuevo, el archivo XML es una buena manera. Ahora, si su aplicación desarrollada Struts permite búsquedas extensas y actualizaciones, eliminaciones, entonces SQL es la forma óptima.
Por supuesto, seguramente conocerá a uno o dos desarrolladores en su organización que cantarán solo XML o SQL y proclamarán XML o SQL como el único camino a seguir. Tenga cuidado con esas personas y haga lo que 'sienta' correcto para su aplicación. No sigas una "religión tecnológica".
Piense en cosas como con qué frecuencia necesita actualizar los datos, con qué frecuencia necesita buscar los datos. Entonces tendrá su respuesta sobre qué usar: XML o SQL.
Estoy de acuerdo con @Bradley.
XML es muy lento y no es particularmente útil como formato de almacenamiento. ¿Por qué molestarse? ¿Va a editar los datos a mano con un editor de texto? Si es así, XML todavía 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 sus datos.
XML está bien si necesita enviar datos entre programas. 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 algo 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 la sobrecarga administrativa, pero esa es una pregunta totalmente diferente).
XML se puede almacenar como texto y como formato de archivo binario.
Si su objetivo principal es dejar 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 en formato de archivo binario.
Lo que puede acelerar las cosas es usar una base de datos en memoria/tipo de base de datos. Sqlite tiene esta opción.
Y esto suena como la mejor manera de hacerlo por ti.
Mi opinión es que debe usar SQLite (u otra base de datos integrada 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 ven beneficiados, por formatos de archivo de texto puro.
En lo que respecta a los gastos generales, SQLite compila a algo así como 250 k con banderas normales. Muchas bibliotecas de análisis XML son más grandes que SQLite. No obtienes 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 leer datos, la mayoría de los cuales supongo que es un acceso bastante aleatorio, será más rápido usando SQLite.
Y para colmo, obtienes acceso a los beneficios de SQL como transacciones e índices.
Editar: Olvidé mencionar. Una ventaja de SQLite (a diferencia de muchas bases de datos) es que permite cualquier tipo en cualquier fila de 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 tiene que preocuparse por poner límites a las columnas de texto.
Una base de datos es excelente como parte de su programa. Si consultar los datos es parte de su lógica empresarial. XML es mejor como formato de archivo, especialmente si su formato de datos es:
1, jerárquico
2, es probable que cambie en el futuro de maneras que no puedes adivinar
3, los datos van a vivir más tiempo que el programa
Debe tener en cuenta que muchas bases de datos 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 instrucción SQL para obtener acceso a esos datos.
Además, hay bases de datos XML nativas que funcionan de manera muy similar a SQLite en el sentido de que son un archivo binario que contiene una colección de documentos (que podría ser más o menos una tabla), entonces puede XPath/XQuery en un solo documento o en toda la colección. Entonces, con una base de datos XML, puede hacer cosas como almacenar los datos de días como un documento XML separado en la colección ... por lo que solo necesita usar ese documento cuando esté tratando con los datos de hoy. Pero escriba una XQuery para descubrir datos históricos sobre la recopilación de documentos para esa persona. Resbaloso.
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 pueda usar las XPaths que usa actualmente con ligeras modificaciones.
Digo que no es una cuestión de tamaño de datos, sino de tipo de datos. Si sus datos son estructurados, use una base de datos relacional. Si sus datos son semi-estructurados, use XML o, si las cantidades de datos realmente crecen demasiado, una base de datos XML.
Si buscas ir con un db. Puede dividir los archivos xml en directorios para facilitar la búsqueda, pero la sobrecarga administrativa fácilmente se vuelve bastante pesada. También obtienes mucho más que solo rendimiento con un sql db ...