Ejemplo práctico para cada tipo de base de datos (casos reales) [en espera]

Encontré dos artículos impresionantes sobre este tema. Todos los créditos a highscalability.com. La información en esta respuesta se transcribe de estos artículos:

35+ Casos De Uso Para Elegir Su Próxima Base De Datos NoSQL

¿Para Qué Diablos Estás Usando NoSQL?

Si Su Aplicación Lo Necesita...

• transacciones complejas porque no puede permitirse perder datos o si desea una 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 completo ÁCIDO. Yo estaba muy infeliz cuando compré un producto y me dijeron más tarde que estaban fuera de stock. No quería una transacción compensada. ¡Quería mi artículo!

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

• to always be able to write to a database because you need high availability then look at Bigtable Clones which feature eventual consistency.

• para manejar un montón de pequeñas lecturas y escrituras continuas, que pueden ser volátiles, a continuación, mirar Documento o Valor clave o bases de datos que ofrecen un acceso rápido en memoria. Además, considere SSD .

* para implementar operaciones de redes socialesentonces primero puede querer una base de datos de gráficos o en segundo lugar, una base de datos como Riak que soporte relaciones. Una base de datos relacional en memoria con uniones SQL simples podría ser suficiente para conjuntos de datos pequeños. Redis' las operaciones set y list también podrían funcionar.

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

• potente informes sin conexión con grandes conjuntos de datos luego mira Hadoop primero y segundo, productos que admiten MapReduce. Apoyar MapReduce no es lo mismo que ser bueno en ello.

• to span multiple data-centers then look at Bigtable Clones and other products that offer a distributed option that can handle the long latencies and are partition tolerant.

* para construir CRUD aplicaciones luego mirar una base de datos de documentos, que facilitar el acceso a datos complejos, sin uniones.

• built-in search luego mira Riak.

• para operar en estructuras de datos como listas, conjuntos, colas, publish-subscribe, mire Redis. Útil para bloqueo distribuido, registros tapados y mucho más.

• compatibilidad con el programador en forma de tipos de datos amigables con el programador como JSON, HTTP, REST, Javascript, luego primero mire las bases de datos de documentos y luego el valor clave Base.

• transactions combined with materialized viewsfor real-timedata feeds then look at VoltDB. Ideal para acumuladores de datos y ventanas de tiempo.

• soporte a nivel empresarial y SLAS luego busque un producto que tenga un punto de catering para ese mercado. Membase es un ejemplo.

* para registrar flujos continuos de datos que pueden no tener garantías de consistencia necesarias en absoluto, entonces mire los clones Bigtable porque generalmente funcionan en sistemas de archivos distribuidos que pueden manejar muchas escrituras.

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

• para ser vendido a clientes empresariales luego considere una Base de datos Relacional porque están acostumbrados a la tecnología relacional.

* para construir dinámicamente relaciones entre 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 de forma incremental a través de la programación.

• para soportar medios grandes entonces mira los servicios de almacenamiento como S3. NoSQL los sistemas tienden a no manejar grandes BLOBS, aunque MongoDB tiene un servicio de archivos.

* para cargar a granel muchos datos de forma rápida y eficiente, luego busque un producto que admita ese escenario. La mayoría no lo hará porque no admiten operaciones masivas.

• una ruta de actualización más fácil luego use un sistema de esquema fluido como una base de datos de documentos o una Base de datos de clave-valor porque admite campos opcionales, agregar campos y eliminar campos sin la necesidad de crear un marco de migración de esquema completo.

* para implementar restricciones de integridad, elija una base de datos que admita SQL DDL , impleméntelas en procedimientos almacenados o implemente ellos en el código de aplicación.

• a very deep join depth luego use una base de datos de gráficos porque admiten una navegación increíblemente rápida entre entidades.

• para mover el comportamiento de cerca de los datos para que los datos no tengan que moverse a través de la red, mire los procedimientos almacenados de un tipo u otro. Estos se pueden encontrar en bases de datos Relacionales, de Cuadrícula, de documentos e incluso de Clave-valor.

• a cache o almacenar datos BLOB luego mire un almacén de clave-valor. El almacenamiento en caché puede para bits de páginas web, o para guardar objetos complejos que eran costosos de unir en una base de datos relacional, para reducir la latencia, y así sucesivamente.

* un historial comprobado como no corromper los datos y simplemente trabajar generalmente, elija un producto establecido y cuando llegue a escalar (u otros problemas) use una de las soluciones comunes (escalar, tuning, memcached, sharding, desnormalización , etc.).

• tipos de datos fluidos porque sus datos no es de naturaleza tabular, o requiere un número flexible de columnas, o tiene una estructura compleja, o varía según el usuario (o lo que sea), luego mire las bases de datos de clones Document, Key-value y Bigtable. Cada uno tiene mucha flexibilidad en sus tipos de datos.

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

* para operar en la nube y aprovechar al máximo automáticamente la nube características entonces puede que no estemos allí todavía.

• soporte para índices secundarios para que pueda buscar datos por diferentes claves y luego mirar las bases de datos relacionales y Cassandra's nuevo índice secundario soporte.

• crea un conjunto de datos cada vez mayor (realmente BigData) al que rara vez se accede, luego mira el Clon Bigtable que extenderá los datos sobre un sistema de archivos distribuido.

* para integrarse con otros services luego verifique si la base de datos proporciona algún tipo de característica de sincronización de escritura para que pueda capturar los cambios de la base de datos y alimentarlos a otros sistemas para garantizar la consistencia.

• tolerancia a fallos compruebe qué tan duraderas son las escrituras en las fallas de alimentación, particiones y otros escenarios de fallas.

• para empujar el sobre tecnológico en una dirección que nadie parece ir entonces construirlo usted mismo porque eso es lo que se necesita para ser grande a veces.

• para trabajar en una plataforma móvil entonces mira CouchDB/ Mobile couchbase.

Casos de Uso General (NoSQL)

• Bigness . NoSQL es visto como una parte clave de una nueva pila de datos que soporta: big data, grandes números de usuarios, grandes números de computadoras, grandes cadenas de suministro, grandes ciencias, y así sucesivamente. Cuando algo se vuelve tan masivo que debe ser distribuido masivamente, NoSQL está ahí, aunque no todos los sistemas NoSQL están apuntando a grandes. La grandeza puede ser en muchas dimensiones diferentes, no solo usando mucho espacio en 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 ^{(en 2010)} . Twitter, por ejemplo, tiene el problema de almacenar 7 TB / datos por día ^{(in 2010)} with the prospect of this requirement doubling multiple times per year. Esto es que los datos son demasiado grandes para encajar en un problema de nodo. A 80 MB/s se tarda un día en almacenar 7 TB, por lo que las escrituras deben distribuirse en un clúster, lo que implica acceso a clave-valor, MapReduce, replicación, tolerancia a errores, problemas de consistencia y todo lo demás. Para escrituras más rápidas se pueden utilizar sistemas en memoria.

• Acceso rápido clave-valor. Esta es probablemente la segunda virtud más citada de NoSQL en la mentalidad general. Cuando la latencia es importante, es difícil superar el hash en una clave y leer el valor directamente desde memoria o en tan poco como un disco buscar. No todos los productos NoSQL son sobre acceso rápido, algunos son más sobre confiabilidad, por ejemplo. pero lo que la gente ha querido durante mucho tiempo era un mejor memcached y muchos sistemas NoSQL ofrecen eso.

• Esquema flexible y tipos de datos flexibles. Los productos NoSQL admiten una amplia gama de nuevos tipos de datos, y esta es una á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 mucho mapeo. A los desarrolladores les encanta evitar esquemas complejos y marcos {. La falta de estructura permite mucha más flexibilidad. También tenemos tipos de datos compatibles con programas y programadores como JSON.

• Migración de esquemas. Schemalessness hace que sea más fácil lidiar con migraciones de esquemas sin tanta preocupación. Los esquemas son en cierto sentido dinámicos porque son impuestos por la aplicación en tiempo de ejecución, tan diferentes las partes de una aplicación pueden tener una vista diferente del esquema.

• Escriba disponibilidad. ¿Sus escrituras necesitan tener éxito sin importar qué? Entonces podemos entrar en particionamiento, CAP, consistencia eventual y todo ese jazz.

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

• No hay un único punto de fracaso. No todos los productos están cumpliendo con esto, pero estamos viendo una convergencia definitiva en relativamente fácil de configurar y administrar la alta disponibilidad con el equilibrio de carga automático y el tamaño del clúster. Una nube perfecta socio.

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

• Programador facilidad de uso. Acceder 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. Programadores grok claves, valores, JSON, Javascript procedimientos almacenados, HTTP, y así sucesivamente. NoSQL es para programadores. Este es un golpe dirigido por desarrolladores. La respuesta a un problema de base de datos no siempre puede ser contratar a un DBA realmente bien informado, obtener su esquema correcto, desnormalizar un poco, etc., los programadores preferirían un sistema que puedan hacer funcionar por sí mismos. No debería ser tan difícil hacer que un producto funcione. El dinero es parte del problema. Si cuesta mucho escalar un producto, entonces no irá con el producto más barato, que usted controla, que es más fácil de usar, y eso es más fácil a escala?

• Utilice el modelo de datos correcto para el problema correcto. Se utilizan diferentes modelos de datos para resolver diferentes problemas. Se ha puesto mucho esfuerzo en, por ejemplo, encajar las operaciones del gráfico en un modelo relacional, pero no funciona. ¿No es mejor resolver un problema de gráfico en una base de datos de gráficos? Ahora estamos viendo una estrategia general de tratar de encontrar el mejor ajuste entre un problema y una solución.

• Evita golpear la pared. Muchos proyectos golpean algún tipo de pared en su proyecto. Han agotado todas las opciones para hacer que su sistema se escale o funcione correctamente y se preguntan qué es lo siguiente. Es reconfortante seleccionar un producto y un enfoque que pueda saltar por encima de la pared escalando linealmente utilizando recursos añadidos de forma incremental. En un momento esto no era posible. Tomó todo hecho 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 todo el mundo está preocupado por la escala o el rendimiento por encima de lo que se puede lograr con sistemas no NoSQL. Lo que necesitan es un sistema distribuido que pueda abarcar centros de datos mientras maneja escenarios de fallas sin un contratiempo. Los sistemas NoSQL, debido a que se han centrado en la escala, tienden a explotar particiones, tienden a no usar protocolos de consistencia estricta pesados, y por lo tanto están bien posicionados para operar en escenarios distribuidos.

• Compensaciones de capitalización sintonizables . Los sistemas NoSQL son en general, los únicos productos con un "control deslizante" para elegir dónde quieren aterrizar en el espectro de la TAPA. Las bases de datos relacionales eligen una consistencia 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. ¿A tu app le importa la consistencia? ¿Están bien unas gotas? ¿Su aplicación necesita consistencia fuerte o débil? ¿Es más importante la disponibilidad o la consistencia? ¿Será más costoso estar abajo que estar equivocado? Es bueno tener productos que le dan una opción.

• Casos de Uso Más Específicos

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

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

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

* Evitar uniones pesadas cuando la carga de consulta para uniones complejas se vuelve demasiado grande para un RDBMS .

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

• Aplicaciones en las que es necesario admitir una amplia variedad de patrones 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 necesitan velocidad y resiliencia extremas, consultas simples y pueden tolerar datos ligeramente obsoletos. Aplicaciones que requieren un rendimiento moderado, acceso de lectura / escritura, consultas simples, datos completamente autorizados. Una aplicación de solo lectura con requisitos de consulta complejos.

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

• Inserciones, actualizaciones y consultas en tiempo real.

• Datos jerárquicos como discusiones en subprocesos y explosión de partes.

• Creación de tablas dinámicas.

* Aplicaciones de dos niveles donde los datos de baja latencia están disponibles a través de una interfaz NoSQL rápida, pero los datos en sí se pueden calcular y actualizar mediante aplicaciones Hadoop de alta latencia u otras aplicaciones de baja prioridad.

• Lectura secuencial de datos. 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 tener que ser de alto rendimiento y esta función podría utilizar un servicio dedicado para cumplir con los objetivo.

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

• Contadores de visualización de páginas en tiempo real.

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

• Gestión de documentos, catálogos y sistemas de gestión de contenidos. Estos son facilitados por la capacidad de almacenar documentos complejos tiene un todo en lugar de organizado como tablas relacionales. Lógica similar se aplica al inventario, carritos de compras y otros tipos de datos estructurados.

• Archivar. Almacenar un gran flujo continuo de datos que todavía es accesible en línea. Bases de datos orientadas a documentos con un esquema flexible que puede manejar los cambios de esquema a lo largo del tiempo.

• Análisis. Utilice MapReduce, Hive o Pig para realizar consultas analíticas y sistemas de escalado horizontal que admiten altas cargas de escritura.

* Trabajando con heterogéneos tipos de datos, por ejemplo, diferentes tipos de medios a 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 tienes edificios en una ciudad. Desea que la lista de construcción de alguien aparezca rápidamente, de modo que particione en la columna propietario de la tabla de construcción, de modo que la selección tenga una sola partición. Pero cuando alguien compra el edificio de otra persona se actualiza el propietario columna junto con el precio.

• JPL está utilizando SimpleDBpara almacenar rover atributos del plan. Las referencias se mantienen a un blob de plan completo en S3. ^(fuente)

• Agencias federales de aplicación de la ley rastreando estadounidenses en tiempo real usando tarjetas de crédito, tarjetas de lealtad y reservas de viajes.

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

• Ayudando 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 el tiempo "último activo" de todos (para chat tal vez). Si los usuarios están realizando alguna actividad una vez cada 30 segundos, entonces estará más o menos en su límite con aproximadamente 5000 usuarios simultáneos.

* Manejo de consultas multiparticiones de menor frecuencia utilizando vistas materializadas mientras se continúa procesando transmisión de datos de alta frecuencia.

• Colas de prioridad.

• Ejecutar cálculos en datos almacenados en caché, utilizando una interfaz amigable con el programa, sin tener que pasar por un OR.

• Uniq un conjunto de datos grande utilizando columnas clave-valor simples.

• Para mantener la consulta rápida, los valores se pueden enrollar en diferentes segmentos de tiempo.

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

• A línea de tiempo ala Twitter .

Casos de uso de Redis, casos de uso de VoltDB y más encuentre aquí.