¿Buenas razones para NO utilizar una base de datos relacional?
https://stackoverflow.com/questions/37823
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Podría señalar herramientas alternativas de almacenamiento de datos y dar buenas razones para usarlas en lugar de las antiguas bases de datos relacionales?En mi opinión, la mayoría de las aplicaciones rara vez utilizan todo el poder de SQL; sería interesante ver cómo crear una aplicación sin SQL.
Solución
Archivos de texto sin formato en un sistema de archivos
- Muy sencillo de crear y editar.
- Fácil de manipular para los usuarios con herramientas simples (es decir,editores de texto, grep, etc.)
- Almacenamiento eficiente de documentos binarios.
Archivos XML o JSON en el disco
- Como arriba, pero con un poco más de capacidad para validar la estructura.
Hoja de cálculo/archivo CSV
- Modelo muy fácil de entender para los usuarios empresariales.
Subversion (o sistema de control de versiones basado en disco similar)
- Muy buen soporte para versiones de datos.
Berkeley DB (Básicamente, una tabla hash basada en disco)
- Muy simple conceptualmente (solo clave/valor sin escribir)
- Bastante rapido
- Sin gastos administrativos
- Soporta transacciones, creo
Base de datos simple de Amazon
- Creo que es muy parecido a Berkeley DB, pero alojado
Almacén de datos de App Engine de Google
- Alojado y altamente escalable
- Almacenamiento de valores clave por documento (es decir,modelo de datos flexible)
- Enfoque del documento
- Almacenamiento sencillo de datos semiestructurados/basados en documentos
Colecciones de idiomas nativos (almacenadas en la memoria o serializadas en el disco)
- Integración lingüística muy estrecha
Motor de almacenamiento personalizado (escrito a mano)
- Rendimiento potencialmente muy alto en casos de uso requeridos
No puedo decir que sepa mucho sobre ellos, pero quizás también quieras investigar sistemas de bases de datos de objetos.
Otros consejos
La respuesta de Matt Sheppard es excelente (modificación), pero tendría en cuenta estos factores al pensar en un husillo:
- Estructura :¿Obviamente se rompe en pedazos o estás haciendo concesiones?
- Uso:¿Cómo se analizarán/recuperarán/asimilarán los datos?
- Toda la vida :¿Cuánto tiempo son útiles los datos?
- Tamaño :¿Cuantos datos hay?
Una ventaja particular de los archivos CSV sobre los RDBMS es que pueden ser fáciles de condensar y mover a prácticamente cualquier otra máquina.Realizamos grandes transferencias de datos y todo es bastante simple: solo usamos un archivo CSV grande y es fácil de crear scripts usando herramientas como rsync.Para reducir la repetición en archivos CSV grandes, puedes usar algo como YAML.No estoy seguro de almacenar algo como JSON o XML, a menos que tenga requisitos de relación importantes.
En cuanto a las alternativas no mencionadas, no descartes Hadoop, que es una implementación de código abierto de MapReduce.Esto debería funcionar bien si tiene una TONELADA de datos poco estructurados que deben analizarse y desea estar en un escenario en el que pueda agregar 10 máquinas más para manejar el procesamiento de datos.
Por ejemplo, comencé a intentar analizar el rendimiento, que consistía esencialmente en todos los números de sincronización de diferentes funciones registradas en unas 20 máquinas.Después de intentar guardar todo en un RDBMS, me di cuenta de que realmente no necesito volver a consultar los datos una vez que los he agregado.Y solo me resulta útil en su formato agregado.Entonces, mantengo los archivos de registro, los comprimo y luego dejo los datos agregados en una base de datos.
Nota Estoy más acostumbrado a pensar con tallas "grandes".
El sistema de archivos es bastante útil para almacenar datos binarios, lo que nunca funciona muy bien en bases de datos relacionales.
Prueba Prevayler:http://www.prevayler.org/wiki/Prevayler es una alternativa a RDBMS.En el sitio tienes más información.
Si no necesitas ÁCIDO, probablemente no necesite la sobrecarga de un RDBMS.Entonces, determina si lo necesitas primero.La mayoría de las respuestas que no son RDBMS proporcionadas aquí no no proporcionar ÁCIDO.
Motor de almacenamiento personalizado (escrito a mano) / Rendimiento potencialmente muy alto en los casos de uso requeridos
Si tiene conjuntos de datos enormes, en lugar de crear los suyos propios, puede utilizar HDF, el formato de datos jerárquico.
http://en.wikipedia.org/wiki/Hierarchical_Data_Format:
HDF admite varios modelos de datos diferentes, incluidos conjuntos multidimensionales, imágenes rasterizadas y tablas.
También es jerárquico como un sistema de archivos, pero los datos se almacenan en un archivo binario mágico.
HDF5 es una suite que hace posible la gestión de colecciones de datos extremadamente grandes y complejas.
Piense en petabytes de datos de teledetección de NASA/JPL.
Buen día,
Un caso que se me ocurre es cuando los datos que estás modelando no se pueden representar fácilmente en una base de datos relacional.
Un ejemplo de ello es la base de datos utilizada por los operadores de telefonía móvil para supervisar y controlar las estaciones base de las redes de telefonía móvil.
En casi todos estos casos, un OODB Se utiliza, ya sea un producto comercial o un sistema autoenrollable que permite jerarquías de objetos.
He trabajado en una aplicación de monitorización 3G para una gran empresa cuyo nombre permanecerá anónimo, pero cuyo logotipo es una mancha de vino tinto (-:, y utilizaron dicha base de datos OO para realizar un seguimiento de todos los diversos atributos de las células individuales dentro de la red.
El interrogatorio de dichas bases de datos se realiza mediante técnicas patentadas que, por lo general, están completamente libres de SQL.
HTH.
salud,
Robar
Las bases de datos de objetos no son bases de datos relacionales.Pueden ser realmente útiles si solo desea incluir algunos objetos en una base de datos.También admiten versiones y modifican clases para objetos que ya existen en la base de datos. db4o es el primero que me viene a la mente.
En algunos casos (por ejemplo, datos del mercado financiero y control de procesos), es posible que necesite utilizar una base de datos en tiempo real en lugar de un RDBMS.Ver enlace wiki
Había una herramienta RAD llamada JADE escrito hace unos años que tiene un OODBMS incorporado.Las encarnaciones anteriores del motor DB también eran compatibles con Digitalk Smalltalk.Si desea probar la creación de aplicaciones utilizando un paradigma que no sea RDBMS, este podría ser un comienzo.
Otros productos OODBMS incluyen Objetividad, Piedra preciosa (Necesitará obtener VisualWorks Smalltalk para ejecutar la versión Smalltalk pero también hay una versión java).También hubo algunos proyectos de investigación de código abierto en este espacio: me vienen a la mente EXODUS y su descendiente SHORE.
Lamentablemente, el concepto pareció morir, probablemente debido a la falta de un estándar claramente visible y una capacidad de consulta ad hoc relativamente pobre en relación con los sistemas RDMBS basados en SQL.
Un OODBMS es más adecuado para aplicaciones con estructuras de datos centrales que se representan mejor como un gráfico de nodos interconectados.Solía decir que la aplicación OODBMS por excelencia era una mazmorra multiusuario (MUD) donde las salas contendrían los avatares de los jugadores y otros objetos.
Puede recorrer un largo camino simplemente utilizando archivos almacenados en el sistema de archivos.Los RDBMS están mejorando en el manejo de blobs, pero esta puede ser una forma natural de manejar datos de imágenes y similares, particularmente si las consultas son simples (enumerar y seleccionar elementos individuales).
Otras cosas que no encajan muy bien en un RDBMS son las estructuras de datos jerárquicas y supongo que tampoco es tan fácil trabajar con datos geoespaciales y modelos 3D.
Servicios como amazon s3 proporcione modelos de almacenamiento más simples (clave->valor) que no admitan SQL.La escalabilidad es la clave allí.
Los archivos de Excel también pueden ser útiles, especialmente si los usuarios necesitan poder manipular los datos en un entorno familiar y no es factible crear una aplicación completa para hacerlo.
Hay una gran cantidad de formas de almacenar datos; incluso la "base de datos relacional" cubre una variedad de alternativas, desde una simple biblioteca de código que manipula un archivo (o archivos) local como si fuera una base de datos relacional para un solo usuario, hasta desde sistemas basados en archivos que pueden manejar múltiples usuarios hasta una generosa selección de sistemas serios basados en "servidores".
Usamos mucho archivos XML: obtienes datos bien estructurados, buenas herramientas para consultar, la capacidad de realizar ediciones si corresponde, algo que es legible por humanos y luego no tienes que preocuparte por el funcionamiento del motor de base de datos (o el funcionamiento del motor de base de datos).Esto funciona bien para cosas que son esencialmente de solo lectura (en nuestro caso, la mayoría de las veces se generan desde una base de datos en otro lugar) y también para sistemas de un solo usuario donde puedes simplemente cargar los datos y guardarlos según sea necesario, pero estás creando oportunidades. para problemas si desea la edición multiusuario, al menos de un solo archivo.
Para nosotros, eso es todo: vamos a usar algo que haga SQL (MS ofrece un conjunto de herramientas que se ejecutan desde un .DLL para hacer cosas de un solo usuario hasta el servidor empresarial y todos hablan el mismo SQL). (con limitaciones en el extremo inferior)) o usaremos XML como formato porque (para nosotros) la verbosidad rara vez es un problema.
Actualmente no tenemos que manipular datos binarios en nuestras aplicaciones para que no surja esa pregunta.
Murph
Es posible que desee considerar el uso de un servidor LDAP en lugar de una base de datos SQL tradicional si los datos de la aplicación están fuertemente orientados a clave/valor y son de naturaleza jerárquica.
Los archivos BTree suelen ser mucho más rápidos que las bases de datos relacionales.SQLite contiene una biblioteca BTree que es de dominio público (como en genuinamente "dominio público", sin usar el término libremente).
Francamente, si quisiera un sistema multiusuario necesitaría mucha persuasión para no utilizar una base de datos relacional de servidor decente.
Bases de datos de texto completo, que se pueden consultar con operadores de proximidad como "dentro de 10 palabras de", etc.
Las bases de datos relacionales son una herramienta empresarial ideal para muchos propósitos: bastante fáciles de entender y diseñar, lo suficientemente rápidas, adecuadas incluso cuando no están diseñadas y optimizadas por un genio que pueda "usar todo el poder", etc.
Pero algunos propósitos comerciales requieren indexación de texto completo, que los motores relacionales no proporcionan o añaden como una ocurrencia tardía.En particular, los campos legal y médico tienen grandes extensiones de texto no estructurado para almacenar y explorar.
También:* Escenarios integrados: donde normalmente se requiere utilizar algo más pequeño que un RDBMS completo. Db4o es un ODB que se puede utilizar fácilmente en tal caso.* Desarrollo rápido o de prueba de concepto: donde desea centrarse en el negocio y no preocuparse por la capa de persistencia
teorema de la PAC lo explica sucintamente.SQL proporciona principalmente "fuerte consistencia:todos los clientes ven la misma vista, incluso en presencia de actualizaciones".
BESO:Manténgalo pequeño y simple
Ofrecería RDBMS :) Si no permite tener problemas con la configuración/administración, vaya a SQLite.RDBMS integrado con soporte completo de SQL.Incluso te permite almacenar cualquier tipo de datos en cualquier columna.
Principal ventaja frente, por ejemplo, al archivo de registro:Si tienes uno enorme, ¿cómo vas a buscar en él?Con el motor SQL, simplemente crea un índice y acelera drásticamente la operación.
Acerca de la búsqueda de texto completo:SQLite también tiene módulos para búsqueda de texto completo.
Simplemente disfrute de una agradable interfaz estándar para sus datos :)
Una buena razón para no utilizar una base de datos relacional sería cuando se tiene un conjunto de datos masivo y se desea realizar un procesamiento masivo paralelo y distribuido de los datos.El índice web de Google sería un ejemplo perfecto de tal caso.
Hadoop también tiene una implementación del Sistema de archivos de Google llamó al Sistema de archivos distribuido Hadoop.
Recomendaría encarecidamente Lua como alternativa al tipo de almacenamiento de datos SQLite.
Porque:
- Para empezar, el lenguaje fue diseñado como un lenguaje de descripción de datos.
- La sintaxis es legible por humanos (XML es no)
- Se pueden compilar fragmentos de Lua en binario, para mayor rendimiento.
Esta es la opción "colección de idioma nativo" de la respuesta aceptada.Si está utilizando C/C++ como nivel de aplicación, es perfectamente razonable incluir el motor Lua (100 kB de binario) solo para leer configuraciones/datos o escribirlos.
