database - example - nosql mongodb

Ejemplo práctico para cada tipo de base de datos(casos reales)

Question

Existen varios tipos de bases de datos para diferentes propósitos, sin embargo, normalmente MySQL está acostumbrado a todo, porque es la base de datos más conocida. Solo para dar un ejemplo en mi empresa, una aplicación de big data tiene una base de datos MySQL en una etapa inicial, lo que es increíble y traerá serias consecuencias para la compañía. Por qué MySQL? Solo porque nadie sabe cómo (y cuándo) debería usar otro DBMS.

Entonces, mi pregunta no es sobre vendedores, sino sobre el tipo de bases de datos. ¿Puede darme un ejemplo práctico de situaciones específicas (o aplicaciones) para cada tipo de base de datos donde es altamente recomendable usarlo?

Ejemplo:

• Una red social debería usar el tipo X debido a Y.

• MongoDB o couch DB no pueden admitir transacciones, por lo que Document DB no es bueno para una aplicación para un banco o sitio de subastas.

Y así...

Relacional: MySQL , PostgreSQL , SQLite , Firebird , MariaDB , Oracle DB , servidor SQL , IBM DB2 , IBM Informix , Teradata

Objeto: ZODB , DB4O , Eloquera , Versant , Objectivity DB , VelocityDB

Bases de datos de gráficos: AllegroGraph , Neo4j , OrientDB , InfiniteGraph , graphbase , flockdb , flockdb , BrightstarDB

Principales tiendas de valores: Amazon DynamoDB , Redis , Riak , Voldemort , FoundationDB , leveldb , BangDB , KAI , hamsterdb , Tarantool , Maxtable , HyperDex , HyperDex , Memcachedb

Familia de columnas: Big table , Hbase , hyper table , Cassandra , Apache Accumulo

Tiendas RDF: Apache Jena , Sesame

Bases de datos multimodel: arangodb , Datomic , Orient DB , FatDB , AlchemyDB

Documento: Mongo DB , Couch DB , Rethink DB , Raven DB , terrastore , Jas DB , Raptor DB , djon DB , EJDB , denso DB , Couchbase

Bases de datos XML: BaseX , Sedna , eXist

Jerárquico: InterSystems Caché , GT.M gracias a @Laurent Parenteau

Answer 1

Encontré dos artículos impresionantes sobre este tema.

Todos los créditos a highscalability.com . La información se transcribe desde estas URL.

http://highscalability.com/blog/2011/6/20/35-use-cases-for-choosing-your-next-nosql-database.html

http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html

Si su aplicación necesita ...

• Transacciones complejas porque no puede permitirse perder datos o si desea un modelo de programación de transacciones simple, luego mire una base de datos relacional o de cuadrícula.

• Ejemplo: un sistema de inventario que podría querer ACID completo. Estaba muy descontento cuando compré un producto y me dijeron más tarde que estaban agotados. No quería una transacción compensada. ¡Yo quería mi artículo!

• para escalar, entonces NoSQL o SQL pueden funcionar. Busque sistemas que admitan escalado horizontal, particionado, adición en vivo y eliminación de máquinas, balanceo de carga, fragmentación automática y reequilibrio, y tolerancia a fallas.

• para poder escribir siempre en una base de datos porque necesita alta disponibilidad, luego observe los clones de Bigtable que presentan una consistencia final.

• manejar muchas lecturas y escrituras continuas pequeñas , que pueden ser volátiles, luego mirar el documento o valor clave o las bases de datos que ofrecen acceso rápido a la memoria. También considere SSD.

• para implementar operaciones de redes sociales , primero puede querer una base de datos Graph o, en segundo lugar, una base de datos como Riak que admita relaciones. Una base de datos relacional en memoria con uniones simples de SQL podría ser suficiente para pequeños conjuntos de datos. Las operaciones de establecimiento y lista de Redis también podrían funcionar.

• para operar sobre una amplia variedad de patrones de acceso y tipos de datos y luego mirar una base de datos de documentos, en general son flexibles y funcionan bien.

• poderosos informes fuera de línea con grandes conjuntos de datos, luego mira Hadoop primero y segundo, productos que admiten MapReduce. Soportar MapReduce no es lo mismo que ser bueno en eso.

• para abarcar múltiples centros de datos y luego ver los clones de Bigtable y otros productos que ofrecen una opción distribuida que puede manejar las latencias largas y son tolerantes a la partición.

• para construir aplicaciones CRUD luego mirar una base de datos de documentos, hacen que sea fácil acceder a datos complejos sin combinaciones.

• búsqueda incorporada y luego mira a Riak.

• para operar en estructuras de datos como listas, conjuntos, colas, publicar-suscribir y luego mirar a Redis. Útil para bloqueo distribuido, registros con tope y mucho más.

• facilidad de uso del programador en forma de tipos de datos amigables para programadores como JSON, HTTP, REST, Javascript; luego, primero mire las bases de datos de documentos y luego las bases de datos de valores clave.

• transacciones combinadas con vistas materializadas para feeds de datos en tiempo real y luego mirar VoltDB. Ideal para acumulaciones de datos y ventanas de tiempo.

• el soporte de nivel empresarial y los SLA luego buscan un producto que sirva para atender ese mercado. Membase es un ejemplo.

• para registrar flujos continuos de datos que pueden no tener garantías de coherencia necesarias en absoluto y luego ver los clones de Bigtable porque generalmente funcionan en sistemas de archivos distribuidos que pueden manejar muchas escrituras.

• para ser lo más simple posible para operar, luego busque una solución alojada o PaaS porque harán todo el trabajo por usted.

• para ser vendidos a clientes empresariales y luego considerar una Base de datos relacional porque están acostumbrados a la tecnología relacional.

• para construir dinámicamente las relaciones entre los objetos que tienen propiedades dinámicas, entonces considere una Base de Datos de Gráficos porque a menudo no requerirán un esquema y los modelos se pueden construir incrementalmente a través de la programación.

• para admitir medios de comunicación grandes y luego buscar servicios de almacenamiento como S3. Los sistemas NoSQL tienden a no manejar grandes BLOBS, aunque MongoDB tiene un servicio de archivos.

• cargar grandes cantidades de datos de forma rápida y eficiente, luego buscar un producto compatible con ese escenario. La mayoría no lo hará porque no admiten operaciones masivas.

• una ruta de actualización más sencilla, luego use un sistema de esquema fluido como una Base de datos de documentos o una Base de datos de valores clave porque admite campos opcionales, campos agregados y eliminaciones de campos sin la necesidad de construir un marco de migración de esquemas completo.

• implementar restricciones de integridad, luego elegir una base de datos que admita SQL DDL, implementarlas en procedimientos almacenados o implementarlas en el código de la aplicación.

• una profundidad de combinación muy profunda con el uso de una base de datos de gráficos porque admiten navegación increíblemente rápida entre entidades.

• mover el comportamiento cerca de los datos para que los datos no tengan que moverse a través de la red y luego observar los procedimientos almacenados de un tipo u otro. Estos se pueden encontrar en las bases de datos relacionales, de cuadrícula, de documentos e incluso de valores clave.

• para almacenar en caché o almacenar datos BLOB y luego mirar un almacén de valores clave. El almacenamiento en caché puede para partes de páginas web, o para guardar objetos complejos que son costosos para unirse en una base de datos relacional, para reducir la latencia, y así sucesivamente.

• un historial comprobado como no corromper los datos y simplemente trabajar en general, luego elegir un producto establecido y cuando acierte el escalado (u otros problemas) use una de las soluciones comunes (ampliación, ajuste, memcached, sharding, desnormalización, etc.).

• tipos de datos fluidos porque sus datos no son de naturaleza tabular, o requieren una cantidad flexible de columnas, o tienen una estructura compleja, o varían según el usuario (o lo que sea), luego consulte las bases de datos Document, Key-value y Bigtable Clone . Cada uno tiene mucha flexibilidad en sus tipos de datos.

• otras unidades de negocios para ejecutar consultas relacionales rápidas para que no tenga que volver a implementar todo y luego use una base de datos que admita SQL.

• para operar en la nube y aprovechar automáticamente las características de la nube, es posible que aún no estemos allí.

• soporte para índices secundarios para que pueda buscar datos con diferentes claves y luego ver las bases de datos relacionales y el nuevo soporte de índice secundario de Cassandra.

• crea un conjunto de datos en constante crecimiento (realmente BigData) que rara vez se accede y luego mira Bigtable Clone, que distribuirá los datos a través de un sistema de archivos distribuido.

• para integrarse con otros servicios, luego verifique si la base de datos proporciona algún tipo de función de sincronización de escritura atrás para que pueda capturar los cambios de la base de datos y alimentarlos a otros sistemas para garantizar la coherencia.

• tolerancia a fallas: compruebe la durabilidad de las escrituras en las fallas de alimentación, particiones y otros escenarios de falla.

• para empujar la envolvente tecnológica en una dirección en la que nadie parece ir, entonces contrátela usted mismo porque eso es lo que se necesita para ser bueno a veces.

• trabajar en una plataforma móvil y luego mirar CouchDB / Mobile couchbase.

Casos de uso general (NoSQL)

• Bigness . NoSQL se ve como una parte clave de una nueva pila de datos que admite: grandes cantidades de datos, grandes números de usuarios, grandes cantidades de computadoras, grandes cadenas de suministro, grandes científicos, etc. Cuando algo se vuelve tan masivo que debe distribuirse masivamente, NoSQL está ahí, aunque no todos los sistemas NoSQL apuntan a lo grande. La grandeza puede ser a través de muchas dimensiones diferentes, no solo usando mucho espacio en el disco.

• Rendimiento de escritura masivo. Este es probablemente el uso canónico basado en la influencia de Google. Alto volumen. Facebook necesita almacenar 135 mil millones de mensajes al mes. Twitter, por ejemplo, tiene el problema de almacenar 7 TB / datos por día con la perspectiva de duplicar este requisito varias veces al año. Esta es la información demasiado grande para caber en un problema de nodo. A 80 MB / s, se necesita un día para almacenar 7TB, por lo que las escrituras deben distribuirse en un clúster, lo que implica acceso a valores clave, MapReduce, replicación, tolerancia a errores, problemas de consistencia y todo lo demás. Para grabaciones más rápidas, se pueden usar sistemas en memoria.

• Acceso rápido a valores-clave. Esta es probablemente la segunda virtud más citada de NoSQL en el conjunto mental general. Cuando la latencia es importante, es difícil superar el hash en una tecla y leer el valor directamente desde la memoria o en tan poco como una búsqueda de disco. No todos los productos NoSQL se tratan de acceso rápido, algunos son más acerca de la confiabilidad, por ejemplo. pero lo que las personas querían desde hace mucho tiempo era una mejor memcached y muchos sistemas NoSQL ofrecen eso.

• Esquema flexible y tipos de datos flexibles. Los productos NoSQL admiten toda una gama de nuevos tipos de datos, y esta es un área importante de innovación en NoSQL. Tenemos: orientado a columnas, gráfico, estructuras de datos avanzadas, orientado a documentos y clave-valor. Los objetos complejos se pueden almacenar fácilmente sin una gran cantidad de mapas. A los desarrolladores les encanta evitar esquemas complejos y marcos ORM. La falta de estructura permite mucha más flexibilidad. También contamos con tipos de datos compatibles con programas y programadores como JSON.

• Migración de esquema. La ausencia de esquemas hace que sea más fácil tratar las migraciones de esquemas sin tanta preocupación. Los esquemas son, en cierto sentido, dinámicos, ya que la aplicación los imponen en tiempo de ejecución, por lo que diferentes partes de una aplicación pueden tener una vista diferente del esquema.

• Escribir disponibilidad. ¿Sus escritos deben tener éxito, no importa qué? Entonces podemos entrar en partición, CAP, consistencia eventual y todo ese jazz.

• Mantenibilidad, administración y operaciones más fáciles. Esto es muy específico del producto, pero muchos proveedores de NoSQL están tratando de obtener la adopción al facilitar que los desarrolladores los adopten. Están gastando mucho esfuerzo en facilidad de uso, administración mínima y operaciones automatizadas. Esto puede conducir a costos de operación más bajos, ya que no es necesario escribir un código especial para escalar un sistema que nunca fue diseñado para ser utilizado de esa manera.

• No hay un solo punto de falla. No todos los productos cumplen con esto, pero estamos viendo una convergencia definida en la relativamente fácil configuración y administración de alta disponibilidad con equilibrio de carga automático y dimensionamiento de clúster. Un compañero perfecto en la nube.

• Computación paralela generalmente disponible. Vemos que MapReduce se hornea en productos, lo que hace que la computación paralela sea algo que será una parte normal del desarrollo en el futuro.

• Facilidad de uso del programador. El acceso a sus datos debe ser fácil. Si bien el modelo relacional es intuitivo para los usuarios finales, como los contadores, no es muy intuitivo para los desarrolladores. Los programadores obtienen claves, valores, JSON, procedimientos almacenados de Javascript, HTTP, etc. NoSQL es para programadores. Este es un golpe liderado por un desarrollador. La respuesta a un problema de base de datos no siempre puede ser contratar un DBA realmente entendido, obtener su esquema correcto, desnormalizar un poco, etc., los programadores preferirían un sistema que puedan hacer que funcionen por sí mismos. No debería ser tan difícil hacer un producto. El dinero es parte del problema. Si cuesta mucho escalar un producto, ¿no irá con el producto más barato, que usted controla, que es más fácil de usar y que es más fácil de escalar?

• Use el modelo de datos correcto para el problema correcto. Se usan diferentes modelos de datos para resolver diferentes problemas. Se han realizado muchos esfuerzos, por ejemplo, encajando las operaciones de gráfico en un modelo relacional, pero no funciona. ¿No es mejor resolver un problema gráfico en una base de datos de gráficos? Ahora estamos viendo una estrategia general de intentar encontrar el mejor ajuste entre un problema y una solución.

• Evita golpear la pared. Muchos proyectos golpean algún tipo de muro en su proyecto. ¿Han agotado todas las opciones para hacer que su sistema se escale o funcione correctamente y se preguntan qué sigue? Es reconfortante seleccionar un producto y un enfoque que pueda saltar al otro lado de la pared al escalar linealmente utilizando recursos añadidos incrementalmente. En un momento esto no fue posible. Tomó todo a medida, pero eso ha cambiado. Ahora estamos viendo productos listos para usar que un proyecto puede adoptar fácilmente.

• Soporte de sistemas distribuidos. No todos están preocupados por la escala o el rendimiento por encima de lo que se puede lograr con sistemas que no son NoSQL. Lo que necesitan es un sistema distribuido que pueda abarcar los centros de datos mientras maneja los escenarios de falla sin interrupciones. Los sistemas NoSQL, debido a que se han enfocado en la escala, tienden a explotar particiones, tienden a no usar protocolos pesados ​​de coherencia estricta, y por lo tanto están bien posicionados para operar en escenarios distribuidos.

• Compensaciones de CAP ajustable. Los sistemas NoSQL generalmente son los únicos productos con un "control deslizante" para elegir dónde desean aterrizar en el espectro CAP. Las bases de datos relacionales escogen una coherencia fuerte, lo que significa que no pueden tolerar un error de partición. Al final, esta es una decisión comercial y debe decidirse caso por caso. ¿Su aplicación incluso se preocupa por la consistencia? ¿Algunas gotas están bien? ¿Su aplicación necesita consistencia fuerte o débil? ¿La disponibilidad es más importante o es la consistencia? ¿Disminuir será más costoso que estar equivocado? Es bueno tener productos que te permitan elegir.

• Casos de uso más específicos

• Gestionar grandes flujos de datos no transaccionales: registros de Apache, registros de aplicaciones, registros de MySQL, secuencias de clics, etc.

• Sincronización de datos en línea y fuera de línea. Este es un nicho al que CouchDB ha apuntado.

• Tiempos de respuesta rápidos bajo todas las cargas.

• Evitar combinaciones pesadas cuando la carga de consultas para combinaciones complejas se vuelve demasiado grande para un RDBMS.

• Sistemas blandos en tiempo real donde la baja latencia es crítica. Los juegos son un ejemplo.

• Aplicaciones donde se necesita una gran variedad de patrones diferentes de escritura, lectura, consulta y consistencia. Hay sistemas optimizados para 50% de lecturas, 50% de escrituras, 95% de escrituras o 95% de lecturas. Aplicaciones de solo lectura que requieren velocidad y flexibilidad extremas, consultas sencillas y pueden tolerar datos levemente obsoletos. Aplicaciones que requieren un rendimiento moderado, acceso de lectura / escritura, consultas simples, datos completamente autorizados. Aplicación de solo lectura que requiere requisitos complejos de consulta.

• Equilibrio de carga para acomodar datos y concentraciones de uso y para ayudar a mantener ocupados a los microprocesadores.

• Inserciones, actualizaciones y consultas en tiempo real.

• Datos jerárquicos como discusiones con hilos y explosión de partes.

• Creación de tabla dinámica.

• Aplicaciones de dos niveles donde los datos de baja latencia están disponibles a través de una interfaz rápida NoSQL, pero los datos en sí pueden ser calculados y actualizados por aplicaciones Hadoop de alta latencia u otras aplicaciones de baja prioridad.

• Lectura de datos secuenciales. Se debe seleccionar el modelo de almacenamiento de datos subyacente correcto. Un árbol B puede no ser el mejor modelo para lecturas secuenciales.

• Cortar parte del servicio que puede necesitar un mejor rendimiento / escalabilidad en su propio sistema. Por ejemplo, los inicios de sesión de los usuarios pueden necesitar un alto rendimiento y esta característica podría usar un servicio dedicado para cumplir esos objetivos.

• Almacenamiento en caché. Un nivel de almacenamiento en caché de alto rendimiento para sitios web y otras aplicaciones. Ejemplo es un caché para el Sistema de Agregación de Datos utilizado por el Gran Colisionador de Hadrones. Votación.

• Contadores de vista de página en tiempo real.

• Registro de usuario, perfil y datos de sesión.

• Documentos, gestión de catálogos y sistemas de gestión de contenidos. Estos se ven facilitados por la capacidad de almacenar documentos complejos que tienen un todo más que organizado como tablas relacionales. Se aplica una lógica similar al inventario, los carritos de compra y otros tipos de datos estructurados.

• Archivo. Almacenamiento de una gran cantidad de datos continuos que aún se puede acceder en línea. Bases de datos orientadas a documentos con un esquema flexible que puede manejar cambios de esquema a lo largo del tiempo.

• Analítica. Use MapReduce, Hive o Pig para realizar consultas analíticas y sistemas de escalabilidad que admitan altas cargas de escritura.

• Trabajar con tipos de datos heterogéneos, por ejemplo, diferentes tipos de medios en un nivel genérico.

• Sistemas embebidos. No quieren la sobrecarga de SQL y servidores, por lo que utilizan algo más simple para el almacenamiento.

• Un juego de "mercado", donde usted posee edificios en una ciudad. Desea que la lista de creación de alguien aparezca rápidamente, de modo que particione en la columna de propietario de la tabla de compilación, de modo que la selección tenga una sola partición. Pero cuando alguien compra el edificio de otra persona, actualiza la columna de propietario junto con el precio.

• JPL está utilizando SimpleDB para almacenar los atributos del plan móvil. Las referencias se mantienen en un blob de plan completo en S3.

• Las agencias federales encargadas de hacer cumplir la ley siguen a los estadounidenses en tiempo real utilizando tarjetas de crédito, tarjetas de fidelidad y reservas de viaje.

• Detección de fraude al comparar transacciones con patrones conocidos en tiempo real.

• Ayudar a diagnosticar la tipología de tumores integrando la historia de cada paciente. Base de datos en memoria para situaciones de alta actualización, como un sitio web que muestra la "última vez" activa de todos (para el chat). Si los usuarios realizan alguna actividad una vez cada 30 segundos, estarás casi al límite con aproximadamente 5000 usuarios simultáneos. Manejar consultas de particiones múltiples de frecuencias más bajas utilizando vistas materializadas mientras continúa procesando datos de transmisión de alta frecuencia.

• Colas de prioridad.

• Ejecución de cálculos en datos en caché, utilizando una interfaz amigable para el programa, sin tener que pasar por un ORM.

• Único conjunto de datos grande que usa columnas sencillas de valores-clave.

• Para seguir consultando rápidamente, los valores pueden acumularse en diferentes segmentos de tiempo.

• Calcular la intersección de dos conjuntos masivos, donde una unión sería demasiado lenta.

• Una línea de tiempo ala Twitter.

Answer 2

Esta pregunta es casi imposible de responder debido a la generalidad. Creo que estás buscando algún tipo de respuesta fácil problema = solución. El problema es que cada "problema" se vuelve más y más único a medida que se convierte en un negocio.

¿Cómo llamas a una red social? ¿Gorjeo? ¿Facebook? LinkedIn? ¿Desbordamiento de pila? Todos usan diferentes soluciones para diferentes partes, y pueden existir muchas soluciones que usan un enfoque políglota. Twitter tiene un concepto de tipo gráfico, pero solo hay conexiones de 1 grado, seguidores y seguidores. LinkedIn, por otro lado, prospera al mostrar cómo las personas están conectadas más allá del primer grado. Estas son dos necesidades diferentes de procesamiento y datos, pero ambas son "redes sociales".

Si tienes una "red social" pero no haces ningún mecanismo de descubrimiento, entonces puedes usar fácilmente cualquier tienda básica de valor-clave. Si necesita alto rendimiento, escala horizontal, y tendrá índices secundarios o búsqueda de texto completo, podría usar Couchbase .

Si está haciendo aprendizaje automático además de los datos de registro que está reuniendo, puede integrar Hadoop con Hive o Pig, o Spark / Shark. O puede hacer una arquitectura lambda y usar muchos sistemas diferentes con Storm.

Si está realizando un descubrimiento a través de gráficos, como las consultas que van más allá de los vértices de segundo grado y también filtra las propiedades de borde, es probable que considere las bases de datos de gráficos en la parte superior de su tienda primaria. Sin embargo, las bases de datos de gráficos no son buenas opciones para la tienda de sesiones o como tiendas de uso general, por lo que necesitará una solución políglota para ser eficiente.

¿Cuál es la velocidad de los datos? ¿escala? cómo quieres administrarlo ¿Cuál es la experiencia que tiene disponible en la empresa o inicio? Hay una serie de razones por las cuales esta no es una pregunta y respuesta simple.