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

193

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?

MaiaVictor
fuente
61
Si administrar las relaciones de sus datos en su aplicación es realmente más rápido que hacerlo en una base de datos (lo cual es extremadamente difícil de creer), entonces necesita leer sobre SQL y la normalización de la base de datos. Lo que está experimentando es muy probablemente el efecto secundario de una base de datos horriblemente diseñada.
Yannis
68
No necesita una base de datos en el escenario que está describiendo porque su conjunto de datos es trivial. Las bases de datos están destinadas a conjuntos de datos más complejos, si todo lo que hace es leer y mostrar una lista, su enfoque funciona.
Yannis
16
¿Qué condiciones de carrera podrías encontrar y estás listo para eso? ¿Desea escalar más allá de un único servidor web? ¿Cuál es su plan de respaldo si su servidor falla? Es probable que su respuesta a todas estas preguntas sea mejor si tiene una base de datos que si no la tiene. Además, si alguna vez pasó por alto el aprendizaje de cómo usar las bases de datos, supongo que encontrará que su "más fácil que usar consultas SQL" debería modificarse a "más fácil que usar consultas SQL si no entiende SQL".
btilly
37
La base de datos almacena datos en el disco de todos modos. Es solo el resultado final de una evolución natural de los sistemas para almacenar datos estructurados para archivar. Lo más probable es que si se propone utilizar archivos para almacenar sus datos estructurados, se encontrará reinventando características que ya se han desarrollado en bases de datos. Entonces, ¿por qué no usar una base de datos desde el principio?
Benedicto
13
Dependiendo de cómo evolucione su proyecto, es posible que tenga que lidiar con cosas como acceso concurrente y retrocesos. Suenan triviales, pero no lo son. Cuando termine de resolverlos, verá que básicamente ha escrito una base de datos. ¿Realmente quieres estar en el negocio de bases de datos u otro negocio?
jwernerny

Respuestas:

280
  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.

Robert Harvey
fuente
21
6. Normalización, 7. Ver el enlace, 8. Leer sobre tolerancia a fallos. Ah, y antes de dejarse atrapar por la locura NoSQL, aprenda sobre las bases de datos SQL; llegar a conocerlos en sus propios términos. Tu entenderás. Si solo está hablando de datos de configuración simples, JSON puede ser todo lo que necesita. Pero existen muchos otros tipos de datos además de la configuración del programa.
Robert Harvey
25
En la medida en que no sea seguro tener dos programas editando los datos a la vez, bueno, en parte es por eso que existen bases de datos. Si alguna vez tiene esta necesidad (y algunas o todas las otras necesidades que mencioné), se alegrará de no tener que reinventar todo esto.
Robert Harvey
23
@Dokkat No es necesario, nada lo es. Si su enfoque funciona para usted, hágalo. Sin embargo, debo mencionar que la mayoría de los rdbms medio decentes admiten almacenamientos basados ​​en memoria, puede cargar todo lo que necesite en la memoria cuando su aplicación se active (como ya lo hace) y consultarlos como lo haría con una base de datos típica (manteniendo todos los beneficios que Robert mencionó )
Yannis
28
Para decirlo de otra manera, a veces necesitas una tienda de campaña, pero a veces necesitas una casa, y construir una casa es un juego de pelota completamente diferente a lanzar una tienda de campaña.
Robert Harvey
49
@Dokkat cuando las personas se refieren a accidentes, significan cosas como ... su CPU explotó a la mitad al escribir su archivo de "base de datos". ¿Que pasa ahora? Lo más probable es que su archivo esté dañado / ilegible (al menos, es posible que ya no se ajuste a su propio formato) y que necesite restaurarlo desde una copia de seguridad (mientras que la mayoría de las bases de datos "reales" solo perderían la última transacción). Por supuesto, puede escribir código para que maneje esto. Entonces puedes escribir código para todas las demás cosas. Y luego te das cuenta de que has pasado 6 meses escribiendo una base de datos, que podrías haber usado desde el principio, por muy poco esfuerzo.
Daniel B
200

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.
Sam
fuente
14
+1, creo que es importante que hayas señalado que hay ocasiones en que los archivos son realmente adecuados para el almacenamiento.
GrandmasterB
15
Podría agregar otro ejemplo a su tercera lista: cuando los datos realmente son archivos, por ejemplo, imágenes cargadas, documentos pdf y demás. Puede parecer obvio, pero vi casos en los que las imágenes se almacenaron en un blob de base de datos sin ninguna buena razón.
Goran Jovic
55
Bueno, nunca se mencionó explícitamente que fuera una aplicación web, pero lo deduje del comentario de JSON. Sin embargo, a veces algo solo será utilizado por unas pocas personas y puede justificar el alcance de la aplicación para no preocuparse por la escalabilidad y la confiabilidad. Con esto quiero decir, no preocuparme por cosas como la agrupación y la redundancia.
Sam
8
@GoranJovic a veces tiene sentido. Almacene más de 10,000 imágenes en un directorio y algunos sistemas de archivos se detendrán; una base de datos podría ser más fácil que un esquema de partición de subdirectorio manual.
Martin Beckett
2
@MartinBeckett: ¿qué sistema de archivos de la última década hace eso?
Eamon Nerbonne
55

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.

Thomas Clayson
fuente
1
1. ¡Nunca cargue toda su información de usuario en el código del lado del cliente! (Estoy seguro de que fue solo un ejemplo) 2. Cargar eso en primer lugar desde un archivo de 100s de MB de gran tamaño llevará un tiempo. 3. Su ejemplo es correcto, sin embargo, se supone que solo va a buscar por nombre de usuario. ¿Qué sucede si desea almacenar más datos sobre un usuario? Ej. Edad. Ahora desea buscar todos los usuarios que tengan entre 20 y 30 años. O incluso más simple, encuentre un usuario por dirección cuando su json se vea así: {login: {pass: pass, add1: "123 sasd", city: "Wherever"}}.
Thomas Clayson
2
Su último punto es potencialmente correcto, pero entonces podría estar trabajando a partir de datos antiguos, específicamente, si abro su programa, cargo la base de datos actual, luego de 5 minutos más tarde alguien más inicia sesión y edita algo, mi base de datos ahora es una versión posterior hasta que yo salga del programa y vuelva a iniciarlo. Si luego edito mi base de datos y la guardo nuevamente, sobrescribiré cualquier cambio que haya realizado el otro usuario. Cuando tenga una base de datos de usuario, esto podría ser cualquier cosa, solo cambiar su contraseña. Si dos usuarios cambian su contraseña durante las otras sesiones, se revertirá el cambio de un usuario.
Thomas Clayson
44
He aprendido mucho después de buscar algunas cosas sobre indexación. Fue realmente esclarecedor. Las bases de datos tienen un poco más de sentido ahora. Todavía hay algunas cosas que no entiendo, pero ese es un gran progreso. Gracias por esa respuesta!
MaiaVictor
44
Acerca de los índices, no, la base de datos no indexa todo automáticamente. Solo algunas cosas se indexan automáticamente, mientras que el resto requiere explícitamente "por favor haga esto indexado". Y los índices reducen la búsqueda al tiempo logarítmico, O (log (n)), que es ligeramente más lento que constante.
Emperador Orionii
1
Preocuparse por la diferencia entre una implementación basada en hash y b-tree es una optimización prematura. Si los datos están en el índice, aún será una docena de veces más rápido que leerlos en el disco.
SilverbackNet
14

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.

Keith Nicholas
fuente
12

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.

Emperador Orionii
fuente
Soy un poco receloso acerca de la idea de que puedes ignorar cómo se representan las cosas. Si bien puede ignorar esto, si lo hace, y especialmente. Si escribe una consulta un poco más compleja, es muy probable que su aplicación ya no pueda escalar. "Agregar un índice" no siempre es posible: tiene que lidiar con escrituras, y simplemente no ayuda mucho con consultas cuya complejidad abarca varias tablas. Cuando los índices son necesarios, eso implica que ha perdido el beneficio de la capacidad de consulta interactiva ya que solo las consultas específicamente estructuradas son respondibles en un tiempo razonable.
Eamon Nerbonne
12

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.

blueberryfields
fuente
11

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 )

Martin Wickman
fuente
10

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 ...

Chris S
fuente
1
la base de datos y el almacenamiento realmente no se pueden usar indistintamente. Una base de datos es un tipo de almacenamiento, pero un sistema de archivos ciertamente no es un tipo de base de datos
Gaz_Edge
3
"almacenamiento" es donde se almacenan bits y bytes. Una base de datos no necesariamente usa archivos en un sistema de archivos. Un sistema de archivos es definitivamente un tipo de base de datos en el sentido más estricto del término.
Chris S
66
Para alguien que argumenta que no hay uso en las bases de datos cuando son alternativas es usar una base de datos ; si. Parece útil explicarles que su argumento se basa en una noción preconcebida que está mal. Una vez que comprendan mejor su situación inicial, podemos ayudarlos a avanzar con una comprensión más completa de las tecnologías disponibles. Los sistemas de archivos son bases de datos jerárquicas, hay buenas razones por las que los sistemas de bases de datos de objetos y relaciones los han suplantado como almacenamiento / recuperación de datos más rápido, mejor organizado y más eficiente.
Chris S
2
@Gaz_Edge Los datos ya están en una especie de "base de datos" ineficiente almacenados en un montón de archivos cuya estructura y contenido son administrados por la aplicación del OP. Tratar de que el OP entienda y acepte que es un primer paso útil para que comprendan el caso de uso de un sistema de base de datos "real"; Una vez que entienden que una "base de datos" de algún tipo está sucediendo de todos modos, es más fácil comenzar a hablar sobre dónde un servicio gestionado y estructurado de manera adecuada es más eficiente que dejar que la aplicación haga lo suyo. Sugeriría que esta respuesta ayuda, mucho.
Rob Moir
8

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.

funql.org
fuente
Para ser sincero, me encanta esta respuesta y me gustaría que fuera cierta, pero no estoy seguro de que sea así. Por ejemplo, algunos usuarios (y usted) plantearon una preocupación sobre la memoria. Por supuesto, si estoy almacenando datos por valor de GB, no puedo mantenerlo todo en la memoria. Pero, ¿qué pasa si estoy seguro de que los datos nunca serían tan grandes, debería usar la memoria? Bueno, hay otras cosas también. Por ejemplo, he aprendido sobre las vistas incrementales de CouchDB. Eso es ciertamente algo que, a diferencia de la indexación, NO sería trivial para implementarse, y sin duda es una gran aceleración cuando está utilizando un modelo de vista,
MaiaVictor
que supongo que soy. Por ejemplo, cuando transformo datos de "lista de jugadores" a "clasificación", esto no es más que una operación de reducción de mapa. Al crear un juego o un sitio interactivo, ¡casi todo lo que presenta es una operación mapReduce de sus datos centrales! Por lo tanto, tener ese tipo de optimización podría ser realmente deseable. Bueno, no tengo idea de si algo de lo que estoy hablando procede, pero eso tiene sentido. Aprendí mucho hoy y realmente me gustan los conceptos de NoSQL. Gracias por la respuesta (:
MaiaVictor
7

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.

JeffO
fuente
Solo para tener en cuenta, en realidad he usado mysql durante años cuando alojé un "otserv". ¿Adivina qué? Todo lo que trajo fueron problemas. La gente podía "clonar" elementos usando un truco sucio después de darse cuenta de que sus personajes se habían guardado cuando se desconectaban, pero no cuando el servidor fallaba. Este es un problema grave para los otservs. Y la comunidad otserv es ENORME. Eso no sucedería si solo almacenaran datos en la memoria y los serializaran periódicamente. Así que modifiqué la fuente por mí mismo, esos largos archivos C ++ y comencé a guardar en mysql periódicamente, en lugar de cuando los personajes cerraban sesión. ¿Adivina qué? Fue lento!
MaiaVictor
Mysql simplemente no podía manejar el estado de ahorro total cada 2 minutos más o menos. Estaba bastante claro cuándo ocurrió el guardado: todo el servidor "se retrasó" por un segundo. ¡Ahora realmente agradecería si las personas que publican aquí tuvieran una respuesta para esa!
MaiaVictor
1
No juzgue los RDBMS por lo que sucedió con una sola aplicación que probablemente estaba mal codificada. Especialmente cuando las modificaciones para soportar una base de datos fueron hechas por alguien sin experiencia en la base de datos.
alroc
1
@Dokkat, espero que nadie conecte el cable de alimentación entre depositar fondos en su cuenta bancaria y escribir "periódicamente" el saldo de la cuenta en el disco. Describió una arquitectura de pérdida de datos garantizada. Eso está bien para algunas aplicaciones, pero la mayoría de las aplicaciones de bases de datos les dan a los usuarios el poder de elegir. Puede ejecutar un solo nodo de base de datos con copias de seguridad y arriesgarse a perder algunos datos o utilizar la replicación para eliminar la pérdida de datos si falla un solo nodo.
mikerobi
@Dokkat para que no use MySql o cualquier otra base de datos de estilo "servidor" con todas las funciones. Utiliza Sqlite (o similar) y persistirá en el disco cada vez, mientras le proporciona una base de datos incrustada en su aplicación (por lo que no necesita una instalación por separado) y aún le brinda acceso sql, integridad transaccional y persistencia del disco.
gbjbaanb
6

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.

Michael Dillon
fuente
4

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.

Ingo
fuente
La modificación concurrente dentro de un proceso será más eficiente usando bloqueos en proceso en lugar de IPC a un demonio de base de datos que adquiera un montón de bloqueos. Pero presumiblemente estás hablando de múltiples procesos que modifican los datos.
dhasenan
@dhasenan: esta es otra ventaja de los buenos sistemas de bases de datos. Obtiene la concurrencia y funciona en todos los casos: multiproceso, multiproceso, múltiples clientes en diferentes servidores, o cualquier combinación de los mismos. Su programa multiproceso bien pensado puede ser "más eficiente" en ciertos casos, sin embargo, simplemente no escalará.
Ingo
-5

¡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.

joe
fuente
3
No, los "temas" podrían ser carpetas, y las "publicaciones" en el sitio podrían ser archivos. Definitivamente es posible ejecutar un sitio como este desde un sistema de archivos. No es eficiente: lento y complicado de desarrollar, ejecutar consultas, insertar nuevos datos, etc.
Chris S
lento + complicado = incapaz?
Joe
Lento y complicado de construir! = Lento y complicado de funcionar
Joe
1
@joe, realmente no es cierto que un archivo (quizás no sea un archivo "simple", pero ¿qué significa eso?) no se puede usar para organizar datos relacionados con diferentes temas. Podría usar JSON, como sugiere Dokkat, o XML, o archivos de registros mixtos como solíamos hacer en los días anteriores a XML, o cualquier formato de archivo que pueda imaginar. No recomendaría ninguno de estos enfoques para la mayoría de los escenarios, pero eso no significa que no se puedan hacer.
John M Gant
@John M Gant: totalmente de acuerdo con usted, las bases de datos no pueden reemplazar archivos individuales (ya que no le gustan los simples), y viceversa, por la única razón por la que un automóvil no puede reemplazar una bicicleta. hablo 3 idiomas "humanos", y mi elección de palabras y vocabulario es la razón por la que me malinterpretaron ... supongo
Joe