Almacenar grandes cantidades de datos: ¿DB o sistema de archivos?

Question

Digamos que mi aplicación crea, almacena y recupera una gran cantidad de entradas (decenas de millones). Cada entrada tiene un número variable de datos diferentes (por ejemplo, algunas entradas tienen solo unos pocos bytes, como ID/título, mientras que algunos pueden tener megabytes de datos suplementarios). La estructura básica de cada entrada es la misma y está en formato XML.

Las entradas se crean y editan (lo más probable es que añadan, no reescriban) arbitrariamente.

¿Tiene sentido almacenar entradas como archivos separados en un sistema de archivos mientras se mantienen los conjuntos de índices necesarios en la base de datos frente a guardar todo en una base de datos?

Answer 1

Realmente depende de cómo va a usarlo. Las bases de datos pueden manejar más entradas en una tabla de lo que la mayoría de la gente piensa, especialmente con una indexación adecuada. Por otro lado, si no va a utilizar la funcionalidad que proporciona una base de datos relacional, es posible que no haya muchas razones para usarla.

Ok, suficiente generalización. Dado que una base de datos eventualmente se reduce a "archivos en el disco" de todos modos, no me preocuparía demasiado sobre lo que "es lo correcto". Si el propósito principal de la base de datos es solo recuperar estos archivos de manera eficiente, creo que sería perfectamente correcto mantener pequeñas las entradas de la base de datos y buscar rutas de archivos en lugar de datos reales, especialmente porque su sistema de archivos debería ser bastante eficiente para recuperar datos. dada una ubicación específica.

En caso de que le interese, este es un patrón de almacenamiento de datos común para los motores de búsqueda: el índice almacenará los datos indexados y un puntero a los datos almacenados en el disco, en lugar de almacenar todo en el índice.

Answer 2

Quiero definitivamente almacenar los datos en el sistema de archivos y un hash la ruta en la base de datos.

Answer 3

Bueno, dependiendo de sus costos, MS SQL Server tiene lo que se llama un "Índice XML Primario" que se puede crear, incluso en datos no estructurados. Esto le permite escribir XQuery para buscar las columnas y la base de datos lo ayudará.

Si hay alguna coherencia en los datos, o puede colocarse en un esquema, entonces puede ver un beneficio en esto.

Podría recomendar si tiene grandes cantidades de datos binarios, como imágenes, etc., que los quita y los coloca en otro lugar, como un sistema de archivos. O si usa 2008 hay un tipo llamado "Filestream" (cheers @Marc_s) que le permite indexar, almacenar y asegurar todos los archivos que anota y usa API NTFS para recuperarlos (es decir, transferencia rápida de bloques) pero aún tenerlos mantenido como columnas en la base de datos.

Tener la base de datos allí podría ofrecerle una buena capa de abstracción y escalado si su aplicación exige mucho al buscar a través de los datos XML, lo que significa que no tiene que hacerlo.

Just my 2c.

Answer 4

En el trabajo, a menudo tengo que acumular grandes conjuntos de documentos XML para su posterior análisis. Normalmente esto se hace pegándolos en un directorio, y el análisis se realiza mediante grep (o un programa Java a medida con toda su parafina XML factory/builder/wrapper/API).

Un día lento, pensé en intentar ponerlo en PostgreSQL.Hay dos características que quería probar:

• Compresión automática de datos grandes cuando corresponda (TOAST).
• Indexación utilizando una expresión.

Con respecto a la primera característica, el tamaño de la base de datos era menos de la mitad del tamaño de los archivos sin formato. Hacer una búsqueda de texto completo, un escaneo de tabla usando WHERE data::TEXT LIKE '%pattern%', fue en realidad más rápido que ejecutar grep en los archivos. Cuando se trata de unos GB de XML, esto solo hace que la base de datos valga la pena.

La segunda función, la indexación, es un poco más laboriosa de mantener. Hubo algunos elementos particulares que supuse que sería bueno indexar. Un índice en xpath('//tradeHeader/tradeId/text()', data) funciona, pero puede ser complicado duplicarlo en cada consulta. Me resultó más fácil agregar columnas comunes para algunos campos y usar los disparadores de inserción/actualización para mantenerlos sincronizados.

Answer 5

Un par de consideraciones: gestión

• transacción;
• copia de seguridad y recuperación.

Estos son más fáciles de ordenar con una base de datos que con un sistema de archivos. Pero probablemente lo más difícil es sincronizar una copia de seguridad del sistema de archivos con el registro de avance (rehacer) de una base de datos. Cuanto más transaccional sea su aplicación, más importan estos factores.

Según su pregunta, no tiene intención de utilizar la funcionalidad normal de la base de datos (integridad relacional, unión). En ese caso, debe prestar mucha atención a una tercera opción: almacenar sus datos en el sistema de archivos y, en lugar de una base de datos, utilizar un motor de recuperación de texto basado en archivos como Solr (o Lucene), Sphinx, Autonomy, etc.

Answer 6

Depende de cómo va a utilizar los datos, como dice una respuesta anterior.

Los datos en una base de datos se pueden usar para admitir muchos tipos diferentes de consultas y alimentar los resultados a informes, formularios, motores OLAP y muchos otros tipos de herramientas. La indexación adecuada puede acelerar las búsquedas de forma espectacular.

Si conoce SQL, y si la base de datos está bien diseñada, generar consultas es más fácil, más rápido y menos propenso a errores que hacer lo mismo con los archivos. Pero, como han señalado otros, puede conectar sus datos XML a SQL sin moverlo a una base de datos.

Diseñar un buen esquema multipropósito es más difícil de lo que la mayoría de los principiantes piensan que es. Hay mucho que aprender, y no se trata solo de cómo manipular una herramienta u otra. Y un esquema multipropósito malo puede ser incluso más difícil de trabajar que los archivos.

Si decide utilizar una base de datos, prepárese para realizar una inversión importante. Y asegúrese de obtener los beneficios de esa inversión.

Answer 7

Utilizaré HDFS (sistema de archivos distribuido Hadoop) para almacenar los datos. La idea principal es que obtendrá alta disponibilidad, escalabilidad y replicación. Cualquier consulta a su aplicación se puede hacer para reducir las consultas del mapa. Y los campos principales se pueden almacenar como un índice distribuido en la parte superior de Hadoop usando Katta.

Pruebe Google para estas tecnologías.