Esta cita no trata sobre el uso de XML como formato de almacenamiento en general (para lo cual está bien, según los requisitos), sino para el almacenamiento de tipo de base de datos .
Cuando las personas hablan de bases de datos, generalmente se refieren a sistemas de almacenamiento que almacenan grandes cantidades de datos, a menudo en el rango de gigabytes o terabytes. Una base de datos es potencialmente mucho más grande que la cantidad de RAM disponible en el servidor que la almacena. Dado que nadie necesita todos los datos en una base de datos a la vez, las bases de datos deben optimizarse para la recuperación rápida de subconjuntos selectivos de sus datos: para eso es la SELECT
declaración, y las bases de datos relacionales, así como las soluciones NoSQL, optimizan su formato de almacenamiento interno rápidamente recuperación de tales subconjuntos.
XML, sin embargo, realmente no se ajusta a estos requisitos. Debido a su estructura de etiquetas anidadas, es imposible determinar en qué parte del archivo se almacena un determinado valor (en términos de desplazamiento de bytes en un archivo) sin recorrer todo el árbol de documentos, al menos hasta la coincidencia. Una base de datos relacional tiene índices, y buscar un valor en un índice, incluso con una implementación de búsqueda binaria primitiva, es una búsqueda única de O (log n), y luego llegar a los valores reales no es más que una búsqueda de archivos (p. Ej. fseek(data_file_handle, row_index * row_size)
), que es O (1). En un archivo XML, la forma más eficiente es ejecutar un analizador SAX sobre su documento, haciendo un montón de lecturas y búsquedas antes de llegar a sus datos reales; difícilmente puede obtener esto mejor que O (n), a menos que use índices, pero luego, tendría que reconstruir todo el índice para cada inserción (ver más abajo).
Insertar es aún peor. Las bases de datos relacionales no garantizan el orden de las filas, lo que significa que solo pueden agregar nuevas filas o sobrescribir las filas marcadas como 'eliminadas'. Esto es extremadamente rápido: la base de datos puede mantener un grupo de ubicaciones de escritura; obtener una entrada del grupo es O (1) a menos que el grupo esté vacío; En el peor de los casos, el grupo está vacío y se debe crear una nueva página, pero esto también es O (1). Por el contrario, una base de datos basada en XML tendría que mover todo después del punto de inserción para hacer espacio; esto es O (n). Cuando entran en juego los índices, las cosas se vuelven aún más interesantes: los índices típicos de bases de datos relacionales pueden actualizarse con una complejidad relativamente baja, por ejemplo O (log n); pero si desea indexar sus archivos XML, cada inserción cambia potencialmente la ubicación en el disco de cada valor en el documento, por lo que debereconstruir todo el índice . Esto también se aplica a las actualizaciones, porque actualizar, por ejemplo, el contenido de texto de un elemento, puede cambiar su tamaño, lo que significa que el XML consecutivo debe cambiar. Una base de datos relacional no tiene que tocar el índice si actualiza una columna no indexada; una base de datos XML tendría que reconstruir el índice completo para cada actualización que cambie el tamaño del nodo XML actualizado.
Esos son los inconvenientes más importantes, pero hay más. XML es muy detallado, lo cual es bueno para la comunicación de servidor a servidor, ya que agrega seguridad (el servidor receptor puede realizar todo tipo de verificaciones de integridad en el XML, y si algo salió mal en la transferencia, es poco probable que el documento valide ) Sin embargo, para el almacenamiento masivo, esto es mortal: no es raro tener una sobrecarga del 100% o más para los datos XML (no es raro ver relaciones de sobrecarga en el rango del 1000% para cosas como mensajes SOAP), mientras que el almacenamiento de base de datos relacional típico los esquemas solo tienen una sobrecarga constante para los metadatos de la tabla, más un pequeño bit por fila; La mayor parte de la sobrecarga en las bases de datos relacionales proviene de anchos de columna fijos. Si tiene un terabyte de datos, una sobrecarga del 500% es simplemente inaceptable, por muchas razones.