¿Tiene sentido usar un servidor de base de datos si la aplicación solo hace cosas localmente?

41

He visto algunas aplicaciones que son básicamente software de aplicación que se ejecutan localmente en el sistema (por lo que no tienen mucha comunicación a través de la red). Estas aplicaciones parecen depender de servidores de bases de datos para almacenar sus datos.

Un ejemplo de una aplicación es Amarok (un reproductor de música popular en Linux). No sé si todavía lo hacen, pero recuerdo que hubo un momento en que instalar Amarok significaba que tenía que instalar un servidor MySQL y tenerlo funcionando en segundo plano todo el tiempo.

¿Cuál es la ventaja de usar un servidor para almacenamiento local en comparación con el uso de una solución SQL incrustada más pequeña como sqlite? Estoy hablando del software de aplicación en general, no necesariamente de amarok (eso fue solo un ejemplo). ¿Hay alguna situación en la que el uso de un servidor de bases de datos tenga sentido en comparación con una base de datos integrada?

database applications

— 9a3eedi
fuente

44

Tener una base de datos puede ser muy importante. Tener una base de datos en proceso o una base de datos de proceso separada es una opción / detalle de implementación.

— 9000

2

Entiendo que. La pregunta es más acerca de por qué elegiría una base de datos de proceso separada (como el servidor mysql) en lugar de una base de datos en proceso (como SQLite) para aplicaciones locales.

— 9a3eedi

29

SQLite ofrece un resumen bastante bueno de cuándo usarlo o no frente a las alternativas:

https://www.sqlite.org/whentouse.html

Esta línea de resumen captura el caso de uso de SQLite extremadamente bien en mi experiencia:

SQLite no compite con las bases de datos cliente / servidor. SQLite compite con fopen ().

El artículo se expande extensamente sobre este punto. También tiene una sección titulada "Situaciones donde un cliente / servidor RDBMS puede funcionar mejor". En pocas palabras, son:

Aplicaciones cliente / servidor : múltiples usuarios en una red.
Sitios web de alto volumen : ya sea de escritura intensiva o de lectura lo suficientemente intensiva como para requerir fragmentación.
Conjuntos de datos muy grandes : más grandes que los que se pueden almacenar razonablemente en un disco.
Alta concurrencia : en particular escrituras concurrentes.

— Denis de Bernardy
fuente

@ 9a3eedi: en realidad, entre esos cuatro puntos no hay ninguno que describa un escenario con un servidor de base de datos completo en combinación con almacenamiento local (especialmente los dos primeros son exactamente lo opuesto a eso), entonces, ¿le importaría aclararnos por qué eligió esto? respuesta, aunque no se ajusta a su pregunta original? Por cierto, le di a esta respuesta un voto negativo exactamente por esa razón.

— Doc Brown

@DocBrown: los casos específicos en los que debe usar un RDBMS de cliente / servidor son [ver respuesta]; para todo lo demás, SQLite funciona bien. No estoy seguro de qué no está claro allí, así que siéntase libre de editar la respuesta si cree que es necesaria.

— Denis de Bernardy

La pregunta original era sobre casos específicos en los que la base de datos ac / s tiene sentido si la aplicación solo hace cosas localmente (cite del título), o use un servidor para almacenamiento local (cite del texto de la pregunta). Los cuatro escenarios anteriores son exactamente lo contrario de eso (los dos primeros) o muy poco probable o poco común como escenarios "locales" (los segundos dos). Entonces, lo que escribió no está mal, pero no se ajusta a la pregunta.

— Doc Brown

@DocBrown, y la respuesta corta es: no tiene ningún sentido a menos que se trate de conjuntos de datos de gran tamaño o que necesiten escrituras concurrentes. (O, por razones obvias, necesita algo que SQLite no ofrece). Nuevamente, siéntase libre de editar la respuesta si ese punto no le resulta claro.

— Denis de Bernardy

Bueno, si realmente piensa que la lista está completa (y, por lo tanto, da una declaración oculta de que para un escenario local el uso de un servidor C / S DB no tiene ningún sentido), entonces no estoy de acuerdo, y no creo que pueda mejorar Su respuesta agregando algunas aclaraciones.

— Doc Brown

28

Incluso para un solo sistema con un solo usuario, un servidor de base de datos "real" tiene sentido:

Utiliza un lenguaje familiar ( SQL ). SQLite usa SQL, pero algunas bases de datos incrustadas (por ejemplo , base de datos de objetos , NoSQL ) no usan SQL. Esos tienden a tener una curva de aprendizaje más alta porque son menos comunes.
Proporciona integridad referencial, restricciones, disparadores, etc., que productos como SQLite pueden no proporcionar o al menos no proporcionar en su totalidad.
Al apuntar a una verdadera base de datos de red compatible con ACID multiusuario, la aplicación tiene la opción de trabajar en un escenario de usuario único / estación de trabajo única, o como una aplicación alojada multiusuario que utiliza la misma base de código .
El usuario tiene la capacidad de examinar los datos fuera de línea utilizando herramientas estándar (por ejemplo, SQL Developer, MySQL Workbench, SQL Server Management Studio), cargar o hacer una copia de seguridad de los datos utilizando esas herramientas, etc. Si bien es posible hacerlo con muchas bases de datos integradas de varios tipos, las personas pueden estar más familiarizadas con esas herramientas del mundo de la base de datos C / S.

El principal inconveniente es la necesidad de instalar y mantener el software del servidor de la base de datos, que es un poco complejo para usuarios no técnicos (e incluso muchos usuarios técnicos). Los sistemas operativos como Linux lo hacen más fácil: tengo PostgreSQL y MySQL ejecutándose en mi sistema Linux. He instalado aplicaciones que se engancharon a ellas con poca o ninguna interacción de mi parte.

— Doc Brown
fuente

99

En realidad, hay un sistema de base de datos (es decir, Sybase SQL Anywhere) con soporte completo de SQL, integridad referencial, ACID, procedimientos almacenados, que no requiere una configuración de servidor o una instalación como servicio cuando se ejecuta en una configuración local (aunque puede ser configuración para un entorno multiusuario). No conozco ningún otro sistema de base de datos con estas propiedades, si alguien conoce uno, me interesaría.

— Doc Brown

3

@DocBrown IIRC MS SQLServer Compact le ofrece esto como un dll, aunque LocalDB es probablemente la mejor opción: no requiere instalación como servicio, aunque sí requiere derechos de administrador.

— gbjbaanb

55

Para agregar a la discusión sobre la validez del inconveniente, aparte de SQLite curiosamente ya mencionado en la respuesta, una serie de bases de datos que no son SQL y sistemas similares a bases de datos, por ejemplo, OrientDB, Solr y otros, tienen soporte de incrustación dedicado .

— mikołak

14

SQLite proporciona integridad referencial (aunque debe activarse) y restricciones básicas. También es significativamente más rápido que la mayoría de los servidores si se usa correctamente. Su principal desventaja en comparación con el servidor es que es de un solo escritor.

— Jan Hudec

2

@DocBrown: la base de datos incrustada de Firebird proporciona soporte SQL completo, incluida la integridad referencial, garantías ACID, procesos almacenados y disparadores. No solía admitir múltiples conexiones simultáneas a una base de datos incrustada, y no estoy seguro de si esa limitación todavía está en su lugar o no, pero todo el conjunto de características de SQL está ahí.

— Mason Wheeler

21

Creo que tiene que ver con la inercia.

Amarok se basa en XMMS, que es de 1997. Para tener buenas capacidades de base de datos, tenía que usar un servidor, porque era mucho más potente que las soluciones basadas en archivos, que de ninguna manera tenían buenas capacidades de base de datos.

La popularidad próxima y creciente de buenas bases de datos integradas locales como SQLlite es algo bastante reciente.

— Pieter B
fuente

Por lo que recuerdo, AmaroK 1 (que podría haberse basado en XMMS) no dependía de un servidor de base de datos. Fue Amarok 2, que fue liberada con KDE4 que introdujo la dependencia, y en ese momento me pareció muy extraño que me iban a requerir a MySQL instalar y que siga funcionando en segundo plano

— 9a3eedi

10

La característica discriminante más importante es la concurrencia .

Si solo tiene una aplicación que se ejecuta en una instancia para el usuario, la solución integrada (ya sea sqlite o algún almacenamiento de objetos) generalmente está bien.

Sin embargo, si tiene varias instancias que necesitan manipular la base de datos al mismo tiempo, necesita tener un servidor para sincronizarla. SQLite solo permite una escritura a la vez, en toda la base de datos, y también lo hacen la mayoría de las otras soluciones integradas. Y si incluso tiene múltiples aplicaciones, es probable que necesite una especificación de restricción más detallada que las soluciones integradas generalmente tampoco permiten.

— Jan Hudec
fuente

5

Muchas de las otras respuestas hablan de la concurrencia como una ventaja, pero también dado que la base de datos se está ejecutando como un servidor, la base de datos puede ejecutar tareas sin la necesidad de ejecutar la aplicación. Esto podría ser mantenimiento, copias de seguridad, sincronización con otro servidor o cualquiera de las tareas programadas.

Si cree que su aplicación podría convertirse en una aplicación cliente / servidor, es posible que desee comenzar a usar un RDBMS desde el principio en lugar de portarlo más tarde.

No tengo idea si el ejemplo dado se aprovecha de esto o no.

— JeffO
fuente

2

A menos que esté ejecutando un sistema integrado con poca memoria y CPU, no creo que ejecutar un servidor en segundo plano le esté causando ningún daño.

Ejecutar un servidor de base de datos localmente está bien. La base de datos está destinada a acceder y manipular datos. El acceso a la red es una ventaja, que puede o no ser necesaria. Hay algunas herramientas de ingeniería y científicas que hacen esto.

Digamos que está utilizando datos, en una aplicación local. ¿Por qué no deberías usar una base de datos? a diferencia de qué?

— cauchy
fuente

Si tuviera que implementar una aplicación para usuarios normales (por ejemplo, un reproductor de música como AmaroK), pensaría que hacer que instalen el servidor MySQL y que se ejecute en segundo plano es un requisito demasiado grande del sistema y será algo que los usuarios querrían diferente a. Pero supongo que depende de la aplicación. Esto es opuesto al uso de algo como SQLite.

— 9a3eedi

2

Depende de la extracción de datos y el espacio general de la aplicación, los requisitos de administración de acceso, la inversión que está planeando en el mantenimiento de datos, la urgencia del prototipo requerido, dónde se encuentra en la curva de aprendizaje, etc.

Si desea garantizar una base de datos estrechamente integrada a una aplicación que no requiere acceso desde otras aplicaciones, cree islas de bases de datos integradas. La implementación de Mozilla Firefox Web Storage con SQLite podría ser un ejemplo.

Si necesita aún más eficiencia con datos limitados, es preferible una selección de diseño de bases de datos en memoria.

Por otro lado, si tiene muchas aplicaciones que ejecutan múltiples consultas en los mismos datos y requiere una mejor estructuración del almacenamiento de datos para optimizar el rendimiento, se requiere un DBMS centralizado. Lo preferiré absolutamente para la investigación científica, cuando requiera una gran cantidad de datos y donde el tiempo de respuesta de la consulta afecte drásticamente la experiencia general del usuario.

Para el caso de Amarok, supongo que era una selección de DBMS de código abierto en ese momento, antes de que elijan el camino de las bases de datos incrustadas.

Si hay una definición específica del sistema a la mano, será más fácil evaluar los pros y los contras.

V / r, Umut

— Umut Kahramankaptan
fuente