¿Inconvenientes de tener (potencialmente) miles de directorios en un servidor en lugar de una base de datos?

https://stackoverflow.com/questions/1220965

10-07-2019
|

Pregunta

Estoy tratando de comenzar a usar archivos de texto sin formato para almacenar datos en un servidor, en lugar de almacenarlos en una gran base de datos MySQL. El problema es que probablemente estaría generando miles de carpetas y cientos de miles de archivos (si alguna vez tengo que escalar). ¿Cuáles son los problemas al hacer esto? ¿Se pone realmente lento? ¿Tiene el mismo rendimiento que usar una base de datos?

Lo que quiero decir: En lugar de tener una base de datos que almacene una tabla de blog, tiene una fila que contiene "autor", "mensaje". y "fecha" En cambio, tendría: Una carpeta para la publicación específica, luego los archivos * .txt dentro de esa carpeta que tiene "autor", "mensaje" y "fecha" almacenado en ellos.

Solución

Esto sería una lectura inmensamente más lenta que una base de datos (las escrituras de archivos ocurren aproximadamente a la misma velocidad; no se puede almacenar una escritura en la memoria).

Las bases de datos

están optimizadas y están destinadas a manejar cantidades tan grandes de datos estructurados . Los sistemas de archivos no lo son. Sería un error intentar replicar una base de datos con un sistema de archivos. Después de todo, puede indexar las columnas de su base de datos, pero es difícil indexar el sistema de archivos sin otra herramienta.

Las bases de datos están construidas para un acceso y recuperación rápidos de datos. Los sistemas de archivos están diseñados para el almacenamiento de datos. Use la herramienta adecuada para el trabajo. En este caso, es absolutamente una base de datos.

Dicho esto, si desea crear archivos HTML para las publicaciones y luego almacenar esas configuraciones regionales en una base de datos para que pueda acceder fácilmente a ellas, entonces definitivamente es una buena solución (a la Movable Type).

Pero si almacena estas cosas en un sistema de archivos, ¿cómo puede encontrar su última publicación? ¿El autor más prolífico? ¿El autor más controvertido? Todas esas cosas son triviales con una base de datos y muy difíciles con un sistema de archivos. Quédese con la base de datos, se alegrará de haberlo hecho.

Otros consejos

Realmente depende:

¿Cuál es el tamaño del archivo
¿Qué requisitos de durabilidad tiene?
¿Cuántas actualizaciones realiza?
¿Qué es el sistema de archivos?

No es obvio que MySQL sea más rápido:

Una vez hice esa comparación para el objeto pequeño para usarlo como almacenamiento de sesiones para CppCMS . Con un índice (solo clave) y dos índices (clave principal y tiempo de espera secundario).

File System:   XFS     ext3 
-----------------------------
Writes/s:      322     20,000

Data Base \  Indexes:    Key Only   Key+Timeout
-----------------------------------------------
Berkeley DB              34,400      1,450
Sqlite No Sync            4,600      3,400
Sqlite Delayed Commit    20,800     11,700

Como puede ver, con el sistema de archivos Ext3 simple era más rápido o más rápido que Sqlite3 para almacenar datos porque no le da (D) de ACID.

Por otro lado ... DB te ofrece muchas, muchas características importantes que probablemente necesites, así que No recomendaría usar archivos como almacenamiento a menos que realmente lo necesite.

Recuerde, DB es no siempre el cuello de la botella del sistema

Olvídate de las respuestas largas, estas son las razones más simples por las que almacenar datos en archivos de texto sin formato es una mala idea:

Es casi imposible consultar. ¿Cómo ordenaría las publicaciones de blog por fecha? Tendría que leer todos los archivos y comparar su fecha, o mantener su propio archivo de índice (básicamente, escribir su propio sistema de base de datos).
Es una pesadilla hacer copias de seguridad. tar cjf no lo cortará, y si lo intenta, puede terminar con una instantánea inconsistente.

Probablemente haya una docena de otras buenas razones para no usar archivos, es difícil controlar el rendimiento, muy difícil de depurar, casi imposible de recuperar en caso de error, no hay herramientas para manejarlos, etc. ...

Creo que la clave aquí es que NO habrá indexación en sus datos. SO para recuperar cualquier cosa, por ejemplo, una búsqueda sería ridículamente lenta en comparación con una base de datos indexada. Además, las operaciones de E / S son caras, una base de datos podría estar (parcialmente) en la memoria, lo que hace que los datos estén disponibles mucho más rápido.

Realmente no dices por qué no usarás una base de datos tú mismo ... Pero en el escenario que estás describiendo, definitivamente usaría un DB sobre carpeta cualquier día, por un par de razones. En primer lugar, el escenario del blog parece muy simple, pero es muy fácil imaginar que, algún día, le gustaría expandirlo con más funcionalidades como búsqueda, más detalles de publicaciones, categorías, etc.

Creo que hacer crecer el modelo sería más difícil de hacer en una estructura de carpetas que en una base de datos.

Además, las bases de datos son MUCHO más rápidas que el acceso a archivos debido a la indexación y el almacenamiento en caché de la memoria.

IIRC Fudforum utilizó el almacenamiento de archivos por razones de velocidad, puede ser mucho más rápido tomar un archivo que buscar un índice de base de datos, recuperar los datos de la base de datos y enviarlos al usuario. Estás intercambiando la interfaz del sistema de archivos con las interfaces DB y DB-library.

Sin embargo, eso no significa que será más rápido o más lento. Creo que encontrará que escribir es más rápido en el sistema de archivos, pero leer más rápido en la base de datos por problemas generales. Si, como fudforum, tiene datos relativamente inmutables en los que desea mostrar varias publicaciones en una, entonces un enfoque basado en archivos puede ser mucho más rápido: por ejemplo, no tienen que buscar todas las publicaciones relacionadas, lo pegan todo 1 archivo de texto y mostrarlo una vez. Si puede emplear ese tipo de optimización, su enfoque basado en archivos funcionará.

Además, los servidores de correo también funcionan en el enfoque basado en archivos, el formato Maildir almacena cada mensaje de correo electrónico como un archivo en un directorio, no en una base de datos.

una cosa que diría, sin embargo, será mejor almacenar todo en 1 archivo, no 3. El sistema de archivos es mejor para leer (y almacenar en caché) un solo archivo que con varios. Entonces, si desea almacenar cada mensaje como 3 partes, guárdelas en un solo archivo, léalo para obtener cualquiera de las partes y simplemente muestre el que desea mostrar.

... y luego desea buscar todas las publicaciones de un autor y puede leer un millón de archivos en lugar de una simple consulta SQL ...

Las bases de datos NO son más rápidas. Piénselo: al final, también almacenan los datos en el sistema de archivos. Entonces, la pregunta de si una base de datos es más rápida depende en gran medida de la ruta de acceso.

Si solo tiene una ruta de acceso, que se correlaciona con su estructura de archivos, el sistema de archivos podría ser mucho más rápido que una base de datos. Solo asegúrese de tener algo de caché disponible para el sistema de archivos.

Por supuesto que pierdes todas las cosas buenas de una base de datos: - transacciones - formas flexibles de indexar datos y, por lo tanto, acceder a los datos de manera flexible y razonablemente rápida. - lenguaje de consulta flexible (aunque feo) - alta capacidad de recuperación.

La escala realmente depende del sistema de archivos utilizado. La mayoría de los sistemas de archivos AFAIK tienen algún tipo de límite superior para el número de archivos (total o por directorio), aunque en los nuevos esto a menudo es muy alto. Para cientos y miles de archivos con alguna estructura de directorios para mantener los directorios a un tamaño razonable, debería ser posible encontrar un sistema de archivos que funcione bien.

Comentario de @ Eric: Depende de lo que necesites. Si solo necesita el contenido exacto en el archivo por consulta, y puede determinar la ubicación y el nombre del archivo de manera determinista, el acceso directo es más rápido que lo que hace una base de datos, que es aproximadamente:

acceder a un montón de entradas de índice para
acceder a un montón de filas de la tabla (rdbms suele leer bloques que contienen varias filas), para
elige una sola fila del bloque.

Si lo mira: tiene índices y filas adicionales en la memoria, que hacen que su almacenamiento en caché sea ineficiente, ¿de dónde se supone que proviene la aceleración de una base de datos?

Las bases de datos son excelentes para el caso general. Pero si tiene un caso especial, casi siempre hay una solución especial que es mejor en algún sentido.

si prefiere irse con RDBMS, ¿por qué no prueba con el otro valor de clave de código abierto o DBs de documentos (Dbs no relacionales)?

De su publicación, entiendo que no va a seguir ninguna propiedad ACID de db relacional ... sería mejor adaptar otros valores clave dbs (mongodb, coutchdb o hyphertable) en lugar de su propia implementación del sistema de archivos ... lo hará dar un mejor rendimiento que los enfoques existentes ..

Nota: no soy un experto en esto ... acabo de comenzar a trabajar en MongoDB y lo encuentro útil en escenarios similares. solo quería compartir en caso de que no conozca estos enfoques

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow