Datos en archivos XML: ¿Un archivo grande o varios pequeños?

Question

Actualmente estoy trabajando en un CMS basado en XML que guarda los datos en fragmentos llamados "elementos". Estos pueden usarse en el sitio web para mostrar contenido.

Ahora, de momento tengo un archivo XML por separado para cada elemento. Dado que la mayoría de las páginas de ese sitio web utilizan de tres a cuatro de estos elementos, un sitio web bastante pequeño con, p. 20 páginas tiene alrededor de 100 artículos diferentes. Y por lo tanto, la misma cantidad de archivos xml en mi carpeta/xml/items.

¿Sería preferible almacenar todos esos datos en un solo archivo items.xml o mi enfoque actual es el mejor?

Pro solo archivo - xml/items.xml

• archivos menos (quizá comienza a convertirse en un problema rendimiento cuando se habla de miles de elementos en una página web más grande.)
• Menos acceso al disco (especialmente en la administración con una lista de todos los artículos )

Pro - varios archivos. xml/artículos/xml *

• más rápido para acceder a un solo elemento ya que sólo un pequeño archivo tiene que ser analizado sintácticamente

Answer 1

Muchas respuestas bien pensadas aquí.

O bien 1 archivo grande, o muchos archivos pequeños, deberían funcionar bien. Las áreas de preocupación para pensar son más probables en cuanto a administración y mantenimiento. Si es difícil mantener elementos porque están en un grupo de archivos diferentes, entonces tal vez un archivo grande sea la respuesta.

Algunos pensamientos:

• un archivo grande significa que un solo error (no válido XML) podría acabar con toda la aplicación, mientras que muchos archivos sólo afectarían a las páginas que utilizan ese artículo (s). Mitigado al no editar datos en producción.

• ¿Cada servidor tiene su propia estructura de archivos de elementos? ¿O están los artículos ubicados en un solo recurso compartido de alta disponibilidad? Cuantas más copias de los datos tenga, más probabilidades tendrá de que los datos se desincronicen en un servidor en particular que podría ser difícil de rastrear.

• Ya sea que elija 1 archivo o muchos archivos, probablemente pueda resolver/abstraer cualquier problema de acceso a datos (bloqueo, búsqueda, etc.) en el código. Cuantos más códigos tenga que escribir para hacer cosas como bloquear, buscar, más errores tendrá que depurar.

• Considere el almacenamiento en caché de elementos durante un período de tiempo para evitar el acceso al disco si el rendimiento comienza a ser un problema.

Es posible que desee echa un vistazo a Scott Hanselman's dasBlog blogging engine. Creo que es esencialmente un sistema de administración de contenido basado en archivos xml/texto que tomó el enfoque de muchos archivos y podría ser útil revisarlo.

Answer 2

Si usted no está simplemente tomar la ruta de la base de datos, que, para mí, se siente obvio, I' d sugerir varios archivos. La razón principal es que si usa solo un archivo y lo actualiza, su aplicación necesita analizar todo el archivo cuando vuelve a mostrar una página, lo que es malo (tm).

Answer 3

Creo que su enfoque actual es la mejor de las dos alternativas. Dado que los usuarios usan una interfaz que usted crea para editar los archivos, de todos modos no buscarán archivos en un directorio con muchos archivos.

Teniendo en cuenta lo que se necesita para dañar un archivo, una ventaja de muchos archivos, es que no obtendrá un gran golpe, sino solo un golpe en un solo archivo. El bloqueo también es mejor, ya que un archivo a la vez está bloqueado para la escritura, en lugar del "archivo XML maestro" completo.

Answer 4

¿Su usuario trabajará con los archivos XML directamente o simplemente es una manera de almacenar los datos?

En este último caso, es un problema técnico y el acceso al disco y la velocidad de análisis son cuestiones relevantes.

Si el primero, la pregunta más importante es qué tiene más sentido para el usuario. A continuación, puede solucionar los problemas técnicos con el almacenamiento en caché y demás. Entonces, suponiendo que el usuario trabaje directamente con los archivos XML, debe preguntarse si está ayudando u obstaculizando a su usuario a tener múltiples archivos o un solo archivo. Si cada elemento describe un componente individual, y hay pocas o ninguna relación con otros elementos, los pondría en archivos separados. Si crea un solo archivo con muchos elementos no relacionados, el usuario pasará mucho tiempo buscando el elemento relevante. Si tiene varios archivos, puede usar el nombre del archivo para seleccionar inmediatamente el correcto.

Answer 5

Creo que depende de la memoria que tenga su servidor; qué tan grandes son los archivos XML; y qué analizador está usando Si el servidor tiene mucha memoria, creo que sería preferible un archivo XML, ya que podría almacenarse en la memoria y luego analizarse fácilmente.Creo que esto sería mayor que la sobrecarga de IO de abrir/leer muchos archivos.

Además, sería mucho más fácil de mantener y flexible para el futuro. Por ejemplo, si desea generar una lista de todos los elementos, o quizás buscarlos, entonces sería muy difícil usar muchos archivos XML separados. Para usar una analogía con la base de datos: si tuviera datos de página comunes en un DB, ¿crearía una tabla separada para cada página? Por supuesto no.

Answer 6

Si almacena todos los documentos XML en un archivo y un archivo de índice que asigna el nombre de cada documento en donde se inicia en el archivo (documentos), se obtiene:

• Menos archivos
• disco Menos acceso
• rápido acceso a un documento único

Honestamente, no creo que este método podría mejorar el tiempo de carga de una página lo suficiente como para merecer la pena el esfuerzo. Usted dijo que podría haber 100 elementos, si no los necesita al preparar las páginas, almacenarlos en un documento aumentaría el tiempo de carga de una página (por lo menos, aumentando el tiempo de acceso a un documento) . Me gustaría guardar cada elemento en un documento, cada documento en un archivo, todos los archivos en un directorio. Supongo que (de manera similar al método que sugerí) el directorio es un índice que mapea el nombre de cada documento (nombre de archivo) al lugar donde comienza en el disco (ruta del archivo).