java - texto - ¿Son buenas las bases de datos de archivos planos?
modificar archivos txt en java (11)
Idea horrible Agregar implicaría buscar hasta el final del archivo cada vez que quiera agregar algo. La actualización requeriría reescribir todo el archivo cada vez. La lectura implica un escaneo de tabla (o mantener un índice separado, que tendría los mismos problemas con la escritura / actualización). Solo use una base de datos a menos que, por supuesto, vuelva a implementar todo lo que un RDBMS ya proporciona para que su solución sea moderadamente escalable.
Se necesitan opciones informadas sobre los méritos de la base de datos de archivos sin formato. Estoy considerando utilizar un esquema de base de datos de archivo plano para administrar los datos de un blog personalizado. Se implementaría en la variante del sistema operativo Linux y se escribiría en Java.
¿Cuáles son los posibles aspectos negativos o positivos con respecto al rendimiento para la lectura y redacción de artículos y comentarios?
¿Sería la recuperación del artículo una mierda por ser un archivo plano en lugar de un RDBMS si se tratara de un ataque de apoplejía? (Ilusión)
No estoy en contra de usar un RDBMS, simplemente preguntando a la comunidad su opinión sobre la viabilidad de un esquema de arquitectura de software.
Seguimiento: en el caso de esta pregunta, vería "archivo plano == basado en sistema de archivos". Por ejemplo, cada entrada de blog y sus metadatos se encontrarían en un único archivo. Realización de muchos archivos organizados por estructura de fechas de las carpetas de archivos (blogs / testblog2 / 2008 / 12 / 01) == 12/01/2008
Escribir su propio motor en un código nativo puede superar a una base de datos de propósito general.
Sin embargo, la calidad del motor y el nivel de característica nunca se acercarán a eso. Todas las cosas que las bases de datos le brindan como características principales (indización, transacciones, integridad referencial), debería implementarlas usted mismo.
No hay nada malo que reinventar la rueda (después de todo, Linux era solo eso), pero tenga en cuenta sus expectativas y su compromiso de tiempo.
Esto se ha hecho con asp.net con Dasblog. Utiliza almacenamiento basado en archivos.
Algunos detalles se enumeran en este enlace más antiguo. http://www.hanselman.com/blog/UpcomingDasBlog19.aspx
También puede obtener más detalles en http://dasblog.info/Features.aspx
He escuchado algunas opiniones sobre el rendimiento. Le sugiero que investigue un poco más para ver si ese tipo de sistema funcionaría bien para usted. Esto es lo más cercano que he oído hablar todavía.
Estoy respondiendo esto para no responder por qué las bases de datos de archivos planos son buenas o malas, otros han hecho un amplio trabajo en eso.
Sin embargo, algunos han estado apuntando a SQLite, que hace su trabajo bien. Como está utilizando Java, su mejor opción sería usar HSQLDB , que hace exactamente lo mismo que SQLite, pero se implementa en Java y se integra en su aplicación.
Las bases de datos de archivos planos son posibles, pero considere lo siguiente.
Las bases de datos deben alcanzar todos los elementos ACID (atomicidad, consistencia, aislamiento, durabilidad) y, si vas a asegurarte de que todo se hace en un archivo plano (especialmente con acceso concurrente), básicamente has escrito un DBMS completo .
Entonces, ¿por qué no usar un DBMS completo en primer lugar?
Se ahorrará tiempo y dinero en escribir (y reescribir muchas veces, lo garantizaré) si solo opta por una de las opciones gratuitas (SQLite, MySQL, PostgresSQL, etc.).
Las bases de datos de archivos planos tienen su lugar y son bastante viables para el dominio correcto.
Los servidores de correo y los servidores NNTP del pasado realmente superaron los límites de cuán lejos puedes llevar realmente estas cosas (lo que en realidad es bastante lejano: los sistemas de archivos pueden tener millones de archivos y directorios).
Las dos vulnerabilidades más importantes son la indexación y las actualizaciones atómicas, pero si el dominio es adecuado, es posible que esto no sea un problema.
Pero puede, por ejemplo, con un bloqueo adecuado, hacer una actualización de índice "atómica" utilizando los comandos básicos del sistema de archivos, al menos en Unix.
Un caso simple es hacer que el proceso de indexación se ejecute a través de los datos para crear el nuevo archivo de índice con un nombre temporal. Luego, cuando haya terminado, simplemente cambie el nombre (ya sea el nombre de la llamada renombrado (2) o el comando shell mv) del archivo anterior sobre el nuevo archivo. Rename y mv son operaciones atómicas en un sistema Unix (es decir, funciona o no y nunca falta un "estado intermedio").
Lo mismo con la creación de nuevas entradas. Básicamente, escriba el archivo completamente en un archivo temporal, luego cambie el nombre o muévalo a su lugar final. Entonces nunca tienes un archivo "intermedio" en el "DB". De lo contrario, es posible que tenga una condición de carrera (como un proceso de lectura de un archivo que aún se está escribiendo, y puede llegar al final antes de que se complete el proceso de escritura - condición de carrera fea).
Si su indexación principal funciona bien con nombres de directorio, entonces eso funciona bien. Puede utilizar un esquema de hash, por ejemplo, para crear directorios y subdirectorios para localizar nuevos archivos.
Encontrar un archivo usando el nombre de archivo y la estructura de directorios es muy rápido ya que la mayoría de los sistemas de archivos indexan sus directorios.
Si está colocando un millón de archivos en un directorio, es posible que haya problemas de ajuste en los que desee consultar, pero fuera de ese cuadro, la mayoría manejará decenas de miles fácilmente. Solo recuerde que si necesita ESCANEAR el directorio, habrá una gran cantidad de archivos para escanear. Particionar a través de directorios ayuda a prevenir eso.
Pero todo eso depende de sus técnicas de indexación y búsqueda.
Efectivamente, un servidor web estándar que sirve contenido estático es una base de datos grande y plana, y el modelo funciona bastante bien.
Por último, por supuesto, tiene a su disposición la gran cantidad de herramientas de sistema de archivos gratuitas de Unix, pero todas tienen problemas con tropecientos millones de archivos (dividir grep 1000000 veces para encontrar algo en un archivo tendrá compensaciones de rendimiento; la sobrecarga simplemente agrega arriba).
Si todos sus archivos están en el mismo sistema de archivos, los enlaces duros también le dan opciones (dado que también son atómicos) en términos de poner el mismo archivo en diferentes lugares (básicamente para indexar).
Por ejemplo, podría tener un directorio "hoy", un directorio "ayer", un directorio "java" y el directorio de mensajes actual.
Por lo tanto, una publicación podría estar vinculada en el directorio "hoy", el directorio "java" (porque la publicación está etiquetada con "java", por ejemplo), y en su lugar final (digamos / articles / 2008/12/01 / my_java_post .TXT). Luego, a medianoche, ejecuta dos procesos. El primero toma todos los archivos en el directorio "hoy", verifica su fecha de creación para asegurarse de que no son "hoy" (ya que el proceso puede demorar varios segundos y puede colarse un nuevo archivo) y cambia el nombre de esos archivos a " ayer". A continuación, haga lo mismo para el directorio "ayer", solo aquí simplemente elimínelos si están desactualizados.
Mientras tanto, el archivo aún está en el directorio "java" y "... / 12/01". Como está utilizando un sistema de archivos Unix y enlaces duros, el "archivo" solo existe una vez, estos son solo indicadores del archivo. Ninguno de ellos es "el" archivo, son todos iguales.
Puede ver que aunque cada movimiento de archivo individual es atómico, el volumen no lo es. Por ejemplo, mientras se ejecuta el script "today", el directorio "ayer" puede contener archivos de "ayer" y "el día anterior" porque todavía no se ejecutó el script "ayer".
En una base de datos transaccional, lo haría todo de una vez.
Pero, simplemente, es un método probado y verdadero. Unix, en particular, funciona MUY bien con ese idioma, y los sistemas de archivos modernos también lo soportan bastante bien.
Parecen funcionar bastante bien para bases de datos de alta escritura, baja lectura y sin actualización, donde se añaden nuevos datos.
Los servidores web y sus primos dependen de ellos en gran medida para los archivos de registro.
El software DBMS también los usa para los registros.
Si su diseño se encuentra dentro de estos límites, parece estar en buena compañía. Es posible que desee mantener metadatos y punteros en una base de datos, y configurar algún tipo de cola query asincrónica rápida para almacenar los comentarios, pero el sistema de archivos ya es bastante bueno en ese nivel de almacenamiento en memoria intermedia y bloqueo de escritura.
Puede usar bases de datos de archivos fiat si es lo suficientemente pequeño como para que no se pierda el acceso aleatorio. Un archivo grande con mucho acceso aleatorio será muy lento. Y no hay consultas complejas. Sin uniones, sin suma, grupo, etc. Tampoco puede esperar obtener datos jerárquicos del archivo plano. El formato XML es mucho mejor para estructuras complejas.
La mayoría de las veces una base de datos de archivos plana es suficiente ahora . Pero le agradecerás a tu yo más joven si comienzas tu proyecto con una base de datos. Esto podría ser SQLite , si no desea configurar un sistema de base de datos completo como PostgreSQL .
Mira esto http://jsondb.io una base de datos basada en Java opensource tiene la mayor parte de lo que estás buscando. Guarda los datos como archivos planos .json, Soporte de subprocesos múltiples, Soporte de cifrado, Soporte de ORM, Soporte de la atomicidad, Soporte de consultas avanzadas basado en XPATH.
Descargo de responsabilidad: Creé esta base de datos.
(respuesta copiada y modificada desde aquí )
Aconsejo no utilizar un archivo plano para nada más que acceso de solo lectura, porque entonces tendría que lidiar con problemas de concurrencia, como asegurarse de que solo un proceso esté escribiendo en el archivo a la vez. En cambio, recomiendo SQLite , una base de datos SQL totalmente funcional que se almacena en un archivo. SQLite ya tiene simultaneidad incorporada, por lo que no tiene que preocuparse por cosas como el bloqueo de archivos, y es realmente rápido para las lecturas.
Sin embargo, si está haciendo muchos cambios en la base de datos, es mejor hacerlos todos a la vez dentro de una transacción . Esto solo escribirá los cambios en el archivo una vez, a diferencia de cada vez que se emite una consulta de cambio. Esto aumenta drásticamente la velocidad de hacer múltiples cambios.
Cuando se emite una consulta de cambio, ya sea dentro o fuera de una sección de transición, toda la base de datos se bloquea hasta que finaliza la consulta. Esto significa que las transacciones extremadamente grandes podrían afectar negativamente el rendimiento de otros procesos porque deben esperar a que la transacción finalice antes de que puedan acceder a la base de datos. En la práctica, no he encontrado que esto sea tan notable, pero siempre es una buena práctica tratar de minimizar el número de consultas de modificación de bases de datos que emite, y ciertamente es más rápido que tratar de usar un archivo sin formato.