sql - relacionales - ¿Buenas razones para NO usar una base de datos relacional?

elementos de una base de datos relacional (21)

¿Puede indicar herramientas de almacenamiento de datos alternativas y dar buenas razones para usarlas en lugar de las bases de datos relacionales antiguas? En mi opinión, la mayoría de las aplicaciones rara vez utilizan toda la potencia de SQL, sería interesante ver cómo crear una aplicación libre de SQL.

Motor de almacenamiento personalizado (escrito a mano) / Potencialmente muy alto rendimiento en los casos de uso requeridos

http://www.hdfgroup.org/

Si tiene enormes conjuntos de datos, en lugar de enrollar los suyos, puede usar HDF, el formato de datos jerárquicos.

http://en.wikipedia.org/wiki/Hierarchical_Data_Format :

HDF es compatible con varios modelos de datos diferentes, incluidas las matrices multidimensionales, las imágenes ráster y las tablas.

También es jerárquico, como un sistema de archivos, pero los datos se almacenan en un único archivo binario mágico.

HDF5 es una suite que hace posible la administración de colecciones de datos extremadamente grandes y complejas.

Piensa en petabytes de datos de teledetección de NASA / JPL.

Además: * Escenarios integrados: donde generalmente se requiere el uso de algo más pequeño que un RDBMS completo. db4o es un ODB que se puede usar fácilmente en tal caso. * Desarrollo rápido o prueba de concepto: donde desea enfocarse en el negocio y no preocuparse por la capa de persistencia

Archivos de texto sin formato en un sistema de archivos

Muy simple de crear y editar
Fácil de usar para los usuarios con herramientas simples (ed 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 habilidad para validar la estructura.

Hoja de cálculo / archivo CSV

Modelo muy fácil para que los usuarios de negocio entiendan

Subversion (o sistema similar de control de versiones basado en disco)

Muy buen soporte para versionar datos

Berkeley DB (Básicamente, una tabla hash basada en disco)

Muy simple conceptualmente (solo clave / valor sin tipear)
Bastante rapido
Sin gastos generales de administración
Admite transacciones que creo

Base de datos simple de Amazon

Al igual que Berkeley DB, creo, pero alojado

Datastore de App Engine de Google

Hospedado y altamente escalable
Por valor clave de almacenamiento de documentos (es decir, modelo de datos flexible)

CouchDB

Enfoque del documento
Almacenamiento simple de datos semiestructurados / basados en documentos

Colecciones de idiomas nativos (almacenados en memoria o serializados en el disco)

Integración muy estrecha de idiomas

Motor de almacenamiento personalizado (escrito a mano)

Potencialmente muy alto rendimiento en casos de usos requeridos

No puedo afirmar que sé mucho sobre ellos, pero es posible que también desee examinar los sistemas de bases de datos de objetos .

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, lo suficientemente 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 toda la potencia", etc.

Pero algunos propósitos comerciales requieren una indexación de texto completo, que los motores relacionales no proporcionan o complementan como una ocurrencia tardía. En particular, los campos legales y médicos tienen grandes franjas de texto no estructurado para almacenar y vadear.

El sistema de archivos es útil para almacenar datos binarios, lo que nunca funciona increíblemente bien en bases de datos relacionales.

En algunos casos (datos del mercado financiero y control de procesos, por ejemplo) es posible que necesite utilizar una base de datos en tiempo real en lugar de un RDBMS. Ver enlace wiki

Gday,

Un caso en el que puedo pensar es cuando los datos que está modelando no se pueden representar fácilmente en una base de datos relacional.

Una vez que tal ejemplo es la base de datos utilizada por los operadores de telefonía móvil para controlar y controlar las estaciones base de las redes de telefonía móvil.

En casi todos estos casos, se usa un OO DB , ya sea un producto comercial o un sistema auto-rodado que permite heirarchies de objetos.

He trabajado en una aplicación de monitoreo 3G para una gran empresa que seguirá siendo anónima, pero cuyo logo es una mancha de vino tinto (-, y usaron una OO DB así para hacer un seguimiento de todos los diversos atributos de las celdas individuales dentro del red.

El interrogatorio de dichos DB se realiza utilizando técnicas patentadas que, por lo general, están completamente libres de SQL.

HTH.

aclamaciones,

Robar

Hay una gran cantidad de formas de almacenar datos, incluso "databse relacional" cubre una gama de alternativas desde una simple biblioteca de código que manipula un archivo local (o archivos) como si fuera una base de datos relacional para un solo usuario, a través de sistemas basados en archivos que pueden manejar múltiples usuarios a una generosa selección de sistemas serios basados en "servidores".

Usamos mucho los archivos XML: obtienes datos bien estructurados, buenas herramientas para consultar los mismos, la posibilidad de realizar ediciones, si es apropiado, algo que es legible por el ser humano y no tienes que preocuparte por el funcionamiento del motor db (o el funcionamiento del db engine). Esto funciona bien para cosas que son esencialmente de solo lectura (en nuestro caso la mayoría de las veces se generan desde un db) y también para sistemas de usuario único donde puede cargar los datos y guardarlos según sea necesario, pero está creando oportunidades para problemas si desea edición multi-usuario, 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 usuario único hasta el servidor empresarial y todos hablan el mismo SQL (con limitaciones en el extremo inferior)) o vamos a usar 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 la pregunta no surja.

Murph

Hubo una herramienta RAD llamada JADE escrita hace unos años que tiene un OODBMS incorporado. Las primeras encarnaciones del motor de DB también admitieron Digitalk Smalltalk. Si desea muestrear el desarrollo de aplicaciones utilizando un paradigma que no sea RDBMS, esto podría ser un comienzo.

Otros productos OODBMS incluyen Objectivity , GemStone (Necesitará tener VisualWorks Smalltalk para ejecutar la versión de Smalltalk pero también hay una versión de Java). También hubo algunos proyectos de investigación de código abierto en este espacio: vienen a la mente EXODUS y su SHORE descendiente.

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) en la que las salas contendrían los avatares de los jugadores y otros objetos.

KISS: mantenlo pequeño y simple

La respuesta de Matt Sheppard es genial (mod up), pero tendría en cuenta estos factores al pensar en un eje:

Estructura: ¿obviamente se rompe en pedazos, o estás haciendo concesiones?
Uso: ¿cómo serán analizados / recuperados / asimilados los datos?
Vida útil: ¿por cuánto tiempo son útiles los datos?
Tamaño: ¿cuántos datos hay?

Una ventaja particular de los archivos CSV sobre RDBMS es que pueden ser fáciles de condensar y moverse a prácticamente cualquier otra máquina. Hacemos grandes transferencias de datos, y todo es bastante simple, solo usamos un gran archivo CSV, y fácil de usar usando herramientas como rsync. Para reducir la repetición en grandes archivos CSV, puede usar algo como YAML . No estoy seguro de que almaceno algo como JSON o XML, a menos que tenga requisitos significativos de relación.

En cuanto a las alternativas no mencionadas, no descarte Hadoop , que es una implementación de código abierto de MapReduce. Esto debería funcionar bien si tiene una TONELACIÓN de datos poco estructurados que debe analizarse, y desea estar en un escenario donde puede agregar 10 máquinas más para manejar el procesamiento de datos.

Por ejemplo, comencé a tratar de analizar el rendimiento que era esencialmente todos los números de tiempo de diferentes funciones registradas en alrededor de 20 máquinas. Después de intentar incluir todo en un RDBMS, me di cuenta de que realmente no era necesario volver a consultar los datos una vez que los agregué. Y, solo es útil en su formato agregado para mí. Entonces, mantengo los archivos de registro, comprimidos y luego dejo los datos agregados en un DB.

Tenga en cuenta que estoy más acostumbrado a pensar con tamaños "grandes".

Las bases de datos de objetos no son bases de datos relacionales. Pueden ser realmente útiles si solo quieres rellenar algunos objetos en una base de datos. También son compatibles con el control de versiones y modificación de clases para objetos que ya existen en la base de datos. db4o es el primero que viene a la mente.

Los archivos BTree son a menudo mucho más rápidos que las bases de datos relacionales. SQLite contiene una biblioteca BTree que está en el dominio público (como en el ''dominio público'' genuino, sin utilizar el término libremente).

Sin embargo, francamente, si quisiera un sistema multiusuario necesitaría persuadir mucho para que no use una base de datos relacional decente del servidor.

Pruebe Prevayler: http://www.prevayler.org/wiki/ Prevayler es una alternativa a RDBMS. En el sitio tienes más información.

Puede recorrer un largo camino simplemente usando archivos almacenados en el sistema de archivos. Los RDBMS son cada vez mejores 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 los datos geoespaciales y los modelos 3D tampoco son tan fáciles de usar.

Los servicios como Amazon S3 ofrecen modelos de almacenamiento más simples (clave-> valor) que no son compatibles con 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 crear una aplicación completa para hacer eso que no es factible.

Recomiendo Lua como una alternativa al almacenamiento de datos tipo SQLite.

Porque:

El lenguaje fue diseñado como un lenguaje de descripción de datos para comenzar
La sintaxis es legible por humanos (XML no )
Uno puede compilar fragmentos Lua en binario, para un mayor rendimiento

Esta es la opción de "recopilació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 (100kB de binario) solo por leer configuraciones / datos o escribirlos.

Se podría considerar el uso de un servidor LDAP en el lugar de una base de datos SQL tradicional si los datos de la aplicación están fuertemente orientados a la clave / valor y de naturaleza jerárquica.

Si no necesita ACID , probablemente no necesite la sobrecarga de un RDBMS. Entonces, determine si necesita eso primero. La mayoría de las respuestas no RDBMS proporcionadas aquí no proporcionan ACID.

Una buena razón para no usar una base de datos relacional sería cuando tiene un conjunto de datos masivo y quiere hacer un procesamiento masivamente paralelo y distribuido en los datos. El índice web de Google sería un ejemplo perfecto de tal caso.

Hadoop también tiene una implementación de Google File System llamada Hadoop Distributed File System .

Yo ofrecería RDBMS :) Si no tienes problemas con la configuración / administración ve a SQLite. Construido en RDBMS con soporte SQL completo. Incluso le permite almacenar cualquier tipo de datos en cualquier columna.

Ventaja principal contra, por ejemplo, el archivo de registro: si tiene uno enorme, ¿cómo va a buscar en él? Con el motor SQL, simplemente crea índices y acelera la operación de forma espectacular.

Acerca de la búsqueda de texto completo: SQLite también tiene módulos para la búsqueda de texto completo.

Simplemente disfruta de una agradable interfaz estándar para tus datos :)

El teorema de CAP lo explica de manera sucinta. SQL proporciona principalmente "Consistencia fuerte: todos los clientes ven la misma vista, incluso en presencia de actualizaciones".