¿Por qué usar una base de datos en lugar de simplemente guardar sus datos en el disco?

En lugar de una base de datos, solo serializo mis datos en JSON, guardándolos y cargándolos en el disco cuando sea necesario. Toda la gestión de datos se realiza en el propio programa, que es más rápido Y más fácil que usar consultas SQL. Por esa razón, nunca he entendido por qué las bases de datos son necesarias en absoluto.

¿Por qué debería uno usar una base de datos en lugar de simplemente guardar los datos en el disco?

1. Puede consultar datos en una base de datos (hacer preguntas).
2. Puede buscar datos de una base de datos con relativa rapidez.
3. Puede relacionar datos de dos tablas diferentes juntas mediante JOIN.
4. Puede crear informes significativos a partir de datos en una base de datos.
5. Sus datos tienen una estructura incorporada.
6. La información de un tipo dado siempre se almacena una sola vez.
7. Las bases de datos son ACID .
8. Las bases de datos son tolerantes a fallas.
9. Las bases de datos pueden manejar conjuntos de datos muy grandes.
10. Las bases de datos son concurrentes; varios usuarios pueden usarlos al mismo tiempo sin corromper los datos.
11. Las bases de datos escalan bien.

En resumen, usted se beneficia de una amplia gama de tecnologías conocidas y probadas desarrolladas durante muchos años por una amplia variedad de personas muy inteligentes.

Si le preocupa que una base de datos sea exagerada, consulte SQLite.

Aunque estoy de acuerdo con todo lo que dijo Robert, no le dijo cuándo debería usar una base de datos en lugar de simplemente guardar los datos en el disco.

Tome esto además de lo que dijo Robert sobre escalabilidad, confiabilidad, tolerancia a fallas, etc.

Para saber cuándo usar un RDBMS, aquí hay algunos puntos a considerar:

• Tiene datos relacionales, es decir, tiene un cliente que compra sus productos y esos productos tienen un proveedor y un fabricante.
• Tiene grandes cantidades de datos y necesita poder localizar información relevante rápidamente
• Debe comenzar a preocuparse por los problemas anteriores identificados: escalabilidad, confiabilidad, cumplimiento de ACID
• Necesita usar herramientas de informes o inteligencia para resolver problemas comerciales

En cuanto a cuándo usar un NoSQL

• Tiene muchos datos que deben almacenarse y que no están estructurados.
• Necesidades de escalabilidad y velocidad
• Por lo general, no necesita definir su esquema por adelantado, por lo que si tiene requisitos cambiantes, este podría ser un buen punto

Finalmente, cuando usar archivos

• Tiene datos no estructurados en cantidades razonables que el sistema de archivos puede manejar
• No te importa la estructura, las relaciones
• No le importa la escalabilidad o la confiabilidad (aunque esto se puede hacer, dependiendo del sistema de archivos)
• No quiere o no puede lidiar con los gastos generales que agregará una base de datos
• Se trata de datos binarios estructurados que pertenecen al sistema de archivos, por ejemplo: imágenes, archivos PDF, documentos, etc.

Una cosa que nadie parece haber mencionado es la indexación de registros. Su enfoque está bien en este momento, y supongo que tiene un conjunto de datos muy pequeño y muy pocas personas que acceden a él.

A medida que se vuelve más complejo, en realidad está creando una base de datos. Como quiera llamarlo, una base de datos es solo un conjunto de registros almacenados en el disco. Ya sea que esté creando el archivo, o MySQL , SQLite o lo que sea que esté creando los archivos, ambas son bases de datos.

Lo que falta es la funcionalidad compleja que se ha incorporado en los sistemas de bases de datos para que sean más fáciles de usar.

Lo principal que me viene a la mente es la indexación. De acuerdo, puede almacenar 10 o 20 o incluso 100 o 1000 registros en una matriz serializada, o una cadena JSON y extraerlo de su archivo e iterarlo relativamente rápido.

Ahora, imagine que tiene 10,000, 100,000 o incluso 1,000,000 de registros. Cuando alguien intenta iniciar sesión, tendrá que abrir un archivo que ahora tiene varios cientos de megabytes, cargarlo en la memoria de su programa, extraer una matriz de información de tamaño similar y luego iterar cientos de miles de registros solo para encuentre el registro al que desea acceder.

Una base de datos adecuada le permitirá configurar índices en ciertos campos en registros que le permitirán consultar la base de datos y recibir una respuesta muy rápidamente, incluso con grandes conjuntos de datos. Combine eso con algo como Memcached , o incluso un sistema de almacenamiento en caché casero (por ejemplo, almacene los resultados de una búsqueda en una tabla separada durante 10 minutos y cargue esos resultados en caso de que alguien más busque lo mismo poco después), y tendrá consultas rápidas, algo que no obtendrá con un conjunto de datos tan grande cuando esté leyendo / escribiendo manualmente en archivos.

Otra cosa poco relacionada con la indexación es la transferencia de información. Como dije anteriormente, cuando tienes archivos de cientos o miles de megabytes, tienes que cargar toda esa información en la memoria, iterarla manualmente (probablemente en el mismo hilo) y luego manipular tus datos.

Con un sistema de base de datos, se ejecutará en sus propios subprocesos o incluso en su propio servidor. Todo lo que se transmite entre su programa y el servidor de la base de datos es una consulta SQL y todo lo que se transmite son los datos a los que desea acceder. No está cargando todo el conjunto de datos en la memoria; todo lo que está enviando y recibiendo es una pequeña fracción de su conjunto total de datos.

Cuando tiene datos simples, como una lista de cosas como describe en los comentarios de su pregunta, una base de datos SQL no le dará mucho. Mucha gente todavía los usa, porque saben que sus datos pueden volverse más complicados con el tiempo, y hay muchas bibliotecas que hacen que trabajar con bases de datos sea trivial.

Pero incluso con una lista simple que carga, guarda en la memoria y luego escribe cuando es necesario, puede sufrir varios problemas:

La finalización anormal del programa puede perder datos, o al escribir datos en el disco, algo sale mal y puede terminar matando todo el archivo. Puede utilizar sus propios mecanismos para manejar esto, pero las bases de datos lo manejan por usted utilizando técnicas probadas en batalla.

Si sus datos comienzan a crecer demasiado y se actualizan con demasiada frecuencia, la serialización de todos sus datos y el ahorro serán una gran carga de recursos y ralentizarán todo. Tendría que comenzar a resolver cómo dividir las cosas, por lo que no será tan costoso. Las bases de datos están optimizadas para guardar solo las cosas que cambian al disco de una manera tolerante a fallas. También están diseñados para que pueda cargar rápidamente los pequeños bits de datos que necesita en cualquier momento.

Además, no tiene que usar bases de datos SQL. Puede usar las " bases de datos" NoSQL, lo que muchos hacen, simplemente use JSON para almacenar los datos. Pero se hace de una manera tolerante a fallas, y de una manera en que los datos se pueden dividir, consultar y dividir de manera inteligente en varias computadoras.

Además, algunas personas mezclan cosas. Pueden usar un almacén de datos NoSQL como Redis para almacenar información de inicio de sesión. Luego use bases de datos relacionales para almacenar datos más complejos donde necesiten hacer consultas más interesantes.

Veo muchas respuestas centradas en el problema de la concurrencia y la fiabilidad. Las bases de datos proporcionan otros beneficios además de concurrencia, confiabilidad y rendimiento. Permiten no molestar cómo se representan los bytes y caracteres en la memoria. En otras palabras, las bases de datos permiten al programador centrarse en "qué" en lugar de "cómo".

Una de las respuestas menciona consultas. "Hacer una pregunta a la base de datos SQL" se adapta bien a la complejidad de una pregunta. A medida que el código evoluciona durante el desarrollo, las consultas simples como "buscar todo" pueden expandirse fácilmente para "buscar todo donde la propiedad1 es igual a este valor y luego ordenar por propiedad2" sin que el programador se preocupe por optimizar la estructura de datos para dicha consulta. El rendimiento de la mayoría de las consultas se puede acelerar haciendo un índice para una determinada propiedad.

Otro beneficio son las relaciones. Con las consultas es más claro hacer referencias cruzadas de datos de diferentes conjuntos de datos y luego tener bucles anidados. Por ejemplo, la búsqueda de todas las publicaciones del foro de usuarios que tienen menos de 3 publicaciones en un sistema donde los usuarios y las publicaciones son conjuntos de datos diferentes (o tablas DB u objetos JSON) se puede hacer con una sola consulta sin sacrificar la legibilidad.

En general, las bases de datos SQL son mejores que las matrices simples si el volumen de datos puede ser grande (digamos más de 1000 objetos), acceso a datos en partes no triviales y diferentes partes del código de acceso a diferentes subconjuntos de datos.

TLDR

Parece que tomó una decisión técnica de almacenamiento de datos a corto plazo esencialmente válida para su aplicación: eligió escribir una herramienta de administración de almacenamiento de datos personalizada.

Estás sentado en un continuo, con opciones para moverte en cualquier dirección.

A largo plazo, es probable que (casi, pero no al 100%) se encuentre con problemas, y es mejor que cambie a usar las soluciones de almacenamiento de datos existentes. Hay problemas de rendimiento específicos, muy comunes y predecibles con los que se verá obligado a lidiar, y es mejor que use las herramientas existentes en lugar de utilizar las suyas propias.

Parece que ha escrito una base de datos (pequeña) personalizada, integrada y utilizada directamente por su aplicación. Supongo que confía en un sistema operativo y un sistema de archivos para administrar la escritura y lectura del disco real, y trata la combinación como un almacén de datos.

Cuando hacer lo que hiciste

Estás sentado en un punto ideal para el almacenamiento de datos. Un sistema operativo y un almacén de datos del sistema de archivos es increíblemente conveniente, accesible y portátil multiplataforma. La combinación ha existido durante tanto tiempo, que seguramente tendrá soporte y ejecutará su aplicación en casi cualquier configuración de implementación estándar.

También es una combinación fácil para escribir código: la API es bastante sencilla y básica, y se necesitan relativamente pocas líneas de código para que funcione.

En general, es ideal hacer lo que has hecho cuando:

• Creación de prototipos de nuevas ideas
• Creación de aplicaciones que es muy poco probable que necesiten escalarse, en términos de rendimiento
• Restringido por circunstancias inusuales, como la falta de recursos para instalar una base de datos

Alternativas

Estás en un continuo de opciones, y hay dos 'direcciones' a las que puedes ir desde aquí, lo que considero como 'abajo' y 'arriba':

Abajo

Esta es la opción menos probable para aplicar, pero está aquí para completar:

Puede, si lo desea, bajar , es decir, omitir el sistema operativo y el sistema de archivos por completo y realmente escribir y leer directamente desde el disco. Esta opción generalmente es relevante solo en casos en los que se requiere una eficiencia extrema; piense, por ejemplo, en un dispositivo reproductor de MP3 mínimo / pequeño , sin suficiente RAM para un sistema operativo completamente funcional, o en algo como la máquina Wayback , que requiere una masa increíblemente eficiente operaciones de escritura de datos (la mayoría de los almacenes de datos intercambian escrituras más lentas por lecturas más rápidas, ya que ese es el caso de uso abrumadoramente más común para casi todas las aplicaciones).

Arriba

Aquí hay varias subcategorías; sin embargo, estas no son exactamente exclusivas. Algunas herramientas abarcan ambos, proporcionando cierta funcionalidad en cada una, algunas pueden cambiar completamente de trabajar en un modo a trabajar en el otro, y algunas se pueden superponer unas sobre otras, proporcionando diferentes funciones a diferentes partes de su aplicación.

Almacenes de datos más potentes

Es posible que necesite almacenar volúmenes de datos cada vez más altos, mientras sigue confiando en su propia aplicación para gestionar la complejidad de la manipulación de datos. Tiene a su disposición una amplia gama de tiendas de valores clave, con diferentes grados de soporte para funciones relacionadas. Las herramientas NoSQL entran en esta categoría, así como en otras.

Este es el camino obvio para escalar cuando lo siguiente describe su aplicación:

• Es inusualmente pesado lectura dependiente
• Usted está de acuerdo con intercambiar un mayor rendimiento por garantías de consistencia más bajas (a corto plazo) (muchas ofrecen "consistencia eventual").
• Está administrando "directamente" la mayor parte de la manipulación de datos y la falta de coherencia (en la práctica, probablemente terminará utilizando una herramienta de terceros al principio, aunque eventualmente lo incorporará a su aplicación o en una capa intermedia escrita personalizada) .
• Está buscando escalar masivamente la cantidad de datos que está almacenando y / o su capacidad de buscar a través de ellos, con requisitos de manipulación de datos "relativamente simples".

Aquí hay algo de margen de maniobra: puede forzar una mejor consistencia de lectura, para lecturas más lentas. Varias herramientas y opciones proporcionan API de manipulación de datos, indexación y otras opciones, que pueden ser más o menos adecuadas para escribir fácilmente su aplicación específica. Entonces, si los puntos anteriores describen casi por completo su aplicación, podría estar "lo suficientemente cerca" para trabajar con una solución de almacenamiento de datos más potente.

Ejemplos conocidos: CouchDB , MongoDB , Redis , soluciones de almacenamiento en la nube como Azure de Microsoft , Google App Data Store y ECE de Amazon.

Motores de manipulación de datos más complejos.

La familia de aplicaciones de almacenamiento de datos "SQL", así como una variedad de otras, se describen mejor como herramientas de manipulación de datos que los motores de almacenamiento puro. Proporcionan una amplia gama de funcionalidades adicionales, más allá del almacenamiento de datos y, a menudo, más allá de lo que está disponible en el lado de la tienda de valores clave. Querrás tomar este camino cuando:

• Absolutamente tiene que tener consistencia de lectura, incluso si eso significa que tendrá un éxito en el rendimiento.
• Está buscando realizar de manera eficiente una manipulación de datos altamente compleja: piense en operaciones muy complejas de UNIRSE y ACTUALIZAR, cubos de datos y segmentación, etc.
• Usted está de acuerdo con cambiar la rigidez por el rendimiento (piense en formatos de almacenamiento de datos fijos y forzados, como las tablas, que no pueden modificarse fácil y / o eficientemente).
• Tiene los recursos para lidiar con un conjunto de herramientas e interfaces a menudo más complejo.

Esta es la forma más "tradicional" de pensar en una base de datos o un almacén de datos, y ha existido durante mucho más tiempo, por lo que hay muchas cosas disponibles aquí y, a menudo, hay mucha complejidad con la que lidiar. Es posible, aunque requiere un poco de experiencia y conocimiento, y construir soluciones simples / evitar gran parte de la complejidad; sin embargo, lo más probable es que termines usando herramientas y bibliotecas de terceros para administrar la mayor parte por ti.

Ejemplos bien conocidos son MySQL , SQL Server , Oracle's Database y DB2 .

Subcontratar el trabajo

Existen varias herramientas y bibliotecas modernas y de terceros, que se interponen entre sus herramientas de almacenamiento de datos y su aplicación, para ayudarlo a administrar la complejidad.

Intentan eliminar inicialmente la mayor parte o todo el trabajo que se dedica a administrar y manipular los almacenes de datos e, idealmente, le permiten realizar una transición suave hacia la complejidad solo cuando sea necesario. Esta es un área activa de emprendimiento e investigación, con algunos resultados recientes que son inmediatamente accesibles y utilizables.

Ejemplos bien conocidos son las herramientas MVC ( Django , Yii ), Ruby on Rails y Datomic . Aquí es difícil ser justo, ya que hay literalmente docenas de herramientas y bibliotecas que actúan como envoltorios alrededor de las API de varios almacenes de datos.

PD: si prefiere videos a texto, es posible que desee ver algunos de los videos relacionados con la base de datos de Rich Hickey; él hace un buen trabajo al dilucidar la mayor parte del pensamiento que implica la elección, el diseño y el uso de un almacén de datos.

Un sistema de archivos se ajusta a la descripción de una base de datos NoSQL, por lo que diría que definitivamente debería considerar usar eso al decidir cómo almacenar sus datos y no simplemente descartarlos a favor de RDBMS, como algunas respuestas parecen sugerir aquí.

Un problema con los sistemas de archivos (y NoSQL en general) es el manejo de las relaciones entre los datos. Si ese no es el principal bloqueador aquí, entonces diría que omita el RDBMS por ahora. También recuerde los aspectos positivos de usar un sistema de archivos como almacenamiento:

• Administración cero
• Baja complejidad, fácil de configurar
• Funciona con cualquier sistema operativo, idioma, plataforma, bibliotecas, etc.
• Solo la configuración es el directorio
• Trivial para probar
• Trivial para examinar con las herramientas existentes, hacer copias de seguridad, modificar, etc.
• Buenas características de rendimiento y bien ajustado por el sistema operativo.
• Fácil de entender para cualquier desarrollador
• Sin dependencias, sin controladores adicionales
• El modelo de seguridad es trivial de entender y es una parte básica del sistema operativo
• Los datos no son accesibles externamente

( fuente )

Los sistemas de archivos son un tipo de base de datos. Tal vez no sea un RDBMS como todos los demás están hablando, pero ciertamente es un DB en el sentido más estricto. Proporciona claves (nombre de archivo) para buscar datos (contenido del archivo), que ha abstraído el almacenamiento y una API mediante la cual su programa se comunica.

Entonces, estás usando una base de datos. Las otras publicaciones pueden discutir sobre las virtudes de los diferentes tipos de bases de datos ...

Se necesita una base de datos si tiene múltiples procesos (usuarios / servidores) que modifican los datos. Luego, la base de datos sirve para evitar que sobrescriban los cambios de los demás.

También necesita una base de datos cuando sus datos son más grandes que la memoria. Hoy en día con la memoria que tenemos disponible, esto hace que el uso de bases de datos en muchas aplicaciones sea obsoleto.

Su enfoque es definitivamente mejor que la tontería de las "bases de datos en memoria". Que son esencialmente su enfoque, pero con una gran cantidad de sobrecarga añadida.

Siempre debe preguntarse si una aplicación en particular necesita un RDBMS. Se crean demasiadas aplicaciones con un proceso de diseño que asume automáticamente todas las herramientas y marcos necesarios al principio. Las bases de datos relacionales son tan comunes y muchos desarrolladores han trabajado en aplicaciones similares como antes, que se incluyen automáticamente antes de que comience el proyecto. Muchos proyectos pueden salirse con la suya, así que no juzgues con demasiada dureza.

Comenzaste tu proyecto sin uno y funciona. Fue más fácil para usted poner esto en funcionamiento sin esperar hasta su SQL. No hay nada de malo en ello.

A medida que este proyecto se expande y los requisitos se vuelven más complicados, algunas cosas se volverán difíciles de construir. Hasta que investigue y pruebe métodos alternativos, ¿cómo sabe cuál es mejor? Puede preguntar a los programadores y eliminar las llamas y "depende" para responder a esta pregunta. Una vez que lo aprenda, puede considerar cuántas líneas de código está dispuesto a escribir en su idioma para manejar algunos de los beneficios de una base de datos. En algún momento, estás reinventando la rueda.

Fácil es a menudo relativo. Hay algunos marcos que pueden construir una página web y conectar un formulario a una tabla de base de datos sin requerir que el usuario escriba ningún código. Supongo que si luchas con el mouse, esto podría ser un problema. Todo el mundo sabe que esto no es escalable ni flexible porque Dios no lo quiera, ha acoplado todo a la GUI. Un no programador acaba de construir un prototipo; muchos YAGNI se encuentran aquí.

Si prefiere aprender un ORM manipulado por el idioma de su elección en lugar de aprender SQL, hágalo, pero intente instalarlo, cree una tabla y extraiga algunos datos de una base de datos popular con SQL (Seleccione * De; no es cosas alucinantes). Es facil de hacer. Es por eso que alguien los creó en primer lugar. No parece una inversión tan grande para tomar una decisión informada. Probablemente también podrías hacer una prueba de rendimiento.

Guardar los datos en el disco ES escribirlos en una base de datos, especialmente si coloca cada objeto en su propio archivo con el nombre del archivo como clave del registro. Y para minimizar los tiempos de búsqueda para leer el archivo, cree subdirectorios basados ​​en los primeros caracteres de la clave.

Por ejemplo, key = ghostwriter iría en g / ho / stwriter.json o g / h / o / stwriter.json o g / ho / ghostwriter.json o g / h / o / ghostwriter.json. Elija su esquema de nomenclatura en función de la distribución de sus claves. Si son números de secuencia, entonces 5/4/3 / 12345.json es mejor que al revés.

Esa es una base de datos y si hace todo lo que necesita, hágalo de esa manera. Hoy en día eso se llamaría una base de datos NoSQL como GDBM o Berkeley db. Tantas opciones. Primero descubra lo que necesita, luego cree una biblioteca de interfaz para tratar los detalles, tal vez una interfaz get / set como memcached o una interfaz CRUD, y luego podrá intercambiar bibliotecas si necesita cambiar el formato de la base de datos para una Con diferentes características.

Tenga en cuenta que algunas bases de datos SQL como PostgreSQL y Apache Derby DB le permitirán hacer consultas SQL sobre muchos formatos NoSQL, incluidas sus propias bases de datos locales. No estoy seguro acerca de MyBatis pero puede ser similar.

Evite el bombo NoSQL. Lea acerca de las características, pruebe el rendimiento y la capacidad y luego elija según cuán bien se adapte a las necesidades de su aplicación.

http://www.hdfgroup.org/HDF5/ es otro formato de datos interesante y ampliamente utilizado que la gente no suele considerar.

Tan pronto como los datos se actualicen al mismo tiempo, el enfoque que utiliza una base de datos (podría ser una base de datos en memoria) probablemente será más correcto y más eficiente, mientras que al mismo tiempo su código sigue siendo fácil, porque simplemente no tiene preocuparse por actualizaciones concurrentes, transacciones, almacenamiento en caché, E / S asincrónicas y todo eso.

¡Necesita una base de datos para almacenar / recuperar los QA como los que publicamos aquí! Un archivo simple no puede organizar datos relacionados con diferentes temas.