Después de haber entendido algunas de las ventajas que ofrece NoSQL (escalabilidad, disponibilidad, etc.), todavía no tengo claro por qué un sitio web querría usar una base de datos no relacional. ¿Puedo obtener ayuda sobre esto, preferiblemente con un ejemplo?¿Por qué exactamente usamos NoSQL?
Mejor rendimiento
bases de datos NoSQL a veces tienen un mejor rendimiento, aunque esto depende de la situación y se disputa.
Adaptabilidad
Puede añadir y eliminar "columnas" sin tiempo de inactividad. En la mayoría de los servidores SQL, esto lleva mucho tiempo y requiere una carga de carga.
Diseño de aplicaciones
Es deseable separar el almacenamiento de datos de la lógica. Si se une y selecciona cosas en las consultas SQL, está mezclando la lógica empresarial con el almacenamiento.
+1 por mencionar algo más que el rendimiento – tawmas
La razón principal para no usar una base de datos SQL es la escalabilidad. Las garantías transaccionales y el modelo relacional hacen que sea casi imposible escalar una base de datos de manera útil en más de unas pocas máquinas, especialmente dadas las cargas de trabajo pesadas en escritura generadas por las aplicaciones web modernas.
Una aplicación como Facebook no se puede hacer funcionar en una base de datos SQL directa, excepto por partición masiva y fragmentación, que también requiere ajustes significativos en la lógica de la aplicación. Es por eso que Facebook desarrolló a Cassandra.
NoSQL básicamente significa que prescindir de algunas características típicas de SQL como la consistencia inmediata o las combinaciones fáciles, a cambio de poder usar una base de datos que se escale mucho mejor.
Por el contrario, no tiene sentido utilizar NoSQL si su sitio web nunca tiene más de una docena de usuarios simultáneos (lo que es cierto para la gran mayoría de los sitios).
Aquí es un testimonio:
7 Lessons Learned While Building Reddit to 270 Million Page Views a Month
Otro argumento para NoSQL es la "Data first, structure later" -enfoque.
bases de datos NoSQL son ahí para resolver varias cosas, principalmente:
(zumbido) bigdata => pensar TB, PB, etc ..
Trabajar con Sistemas Distribuidos/datasets => dicen que tienes 42 productos, por lo que 13 de ellos vivirán en el centro de datos de Chicago, 21 en NY y 8 en algún lugar de Japón, pero una vez que consultes los 42 productos, no necesitarás saber dónde están ubicados: NoSQL DB lo hará.Esto también permite a participar mucho más el poder del cerebro (servidores) para resolver problemas computacionales difíciles [no parece que encajaría su caso de uso, pero es una cosa interesante notar]
Partición => tener su DB se distribuirá fácilmente, además de esos 8 productos geniales en Japón, también permite una replicación de datos fácil, por lo que esos 42 productos se replicarán con un factor de 3, por ejemplo, lo que significaría que DB tendría 3 copias para cada producto. Por lo tanto, si algo falla, no hay problema => aquí hay una réplica disponible. Aquí es donde realmente brillan las bases de datos NoSQL vs. RDBMS. Concedido, puedes fragmentar, particionar y agrupar Oracle/MySQL/PostgreSQL/etc. PERO es un proceso de varias magnitudes más complicado y generalmente un dolor de cabeza de mantenimiento para la mayoría de las personas que emplearías.
PERO a su pregunta:
Cuando la mayoría de la gente, trabajé con/met/chatted, elija NoSQL para su "sitio web", lamentablemente NO es por las razones anteriores, sino simplemente porque es COOLER para hacerlo. Y, de hecho, muchos proyectos NO/tienen dificultades extremas debido a esta razón.
Si la mayoría de los gurús NoSQL toman sus máscaras fuera, que todos estarán de acuerdo que la mayoría de los problemas (o como la gente los websites llaman) que los desarrolladores resuelven día a día, se puede y se en lugar ser resuelto con una solución de SQL, como PostgreSQL, MySQL, etc. con una buena capa de caché Redis encima. Y solo un pequeño subconjunto de problemas REALMENTE se beneficiaría con NoSQL.
Acepto personalmente Riak, ya que soy un firme creyente de que un DB tolerante a errores NoSQL debe tener una base extremadamente fuerte, flexible y distribuida naturalmente => como Erlang OTP. Además, soy un fanático de la simplicidad. Pero, de nuevo, dado el problema, elegiría lo que funcione mejor, y la mayoría de las veces NECESITO esa coherencia (especialmente si somos talking about money/mundo financiero/misión crítica/etc.).
Aquí hay una charla técnica sobre las razones para usar diferentes bases de datos NoSQL y comparaciones entre diferentes tipos de bases de datos NoSQL: NoSQL comparison tech talk.
Necesitamos entender cuál es su problema en la aplicación actual?
NoSQL resuelve los problemas de escalabilidad y disponibilidad frente a la de la atomicidad o consistencia.
Teorema básico de la unidad de disco a CAP.Eric Brewer también señaló que De las tres propiedades de los sistemas de datos compartidos - Consistencia, disponibilidad y tolerancia a las particiones de red - solo se pueden lograr dos en un momento determinado. (Teorema CAP)
Enfoque NOSQL
Hay muchos tipos de bases de datos NoSQL. Las aplicaciones web utilizan bases de datos basadas en documentos. El documento db nos permite almacenar documentos JSON, XML, YAML e incluso Word y manipularlos. Por lo tanto, NoSQL es la elección obvia, especialmente MongoDB, que es una base de datos de documentos que admite el formato JSON de forma predeterminada es la elección preferida de los desarrolladores y diseñadores.
Aunque puedo ver muchas respuestas aquí, siento que puedo agregar algo que sea nítido y al grano. Algunos ejemplos simples que justifican el uso de NoSQL se representan utilizando estas imágenes. No estoy autorizado a publicar las fotos sin embargo, como soy corto de puntos que abriría esa característica para mí, así que por favor ver los enlaces:
si se debe usar RDBMS o NoSQL, depende de su objetivo y la escala del sitio web que está construyendo. Las bases de datos NoSQL se pueden dividir ampliamente en 4 categorías distintas: almacén de clave-valor, almacén de documentos, base de datos en columnas y base de datos de gráficos. Cada tipo de sistema de gestión de bases de datos es adecuado para un escenario de caso de uso particular.
simple aplicación o sitio web de pequeña escala
RDBMS es el mejor candidato. Es un sistema maduro con toneladas de soporte disponibles en línea. Los datos están organizados lógicamente, por lo que es bastante fácil de aprender en comparación con otros tipos de bases de datos.No importa qué tecnología RDBMS elija, el núcleo de la sintaxis SQL y las mejores prácticas serán aplicables a cualquier. Se espera
estructura de los datos que cambian con frecuencia
tablas RDBMS tiene bien definidos y un estricto esquema, por lo que pueden no ser muy fácil de alterar si un requisito para ello surgirá. Por lo tanto, la base de datos NoSQL sin esquema es la mejor opción de tecnología aquí.
sistema a gran escala que genera una gran cantidad de datos
almacén de documentos de base de datos NoSQL es el más adecuado aquí, ya que los sistemas RDBMS no están diseñados principalmente para ser fácilmente escalables.
sistema de contabilidad o gestión de pagos
RDBMS es la mejor elección de la tecnología aquí, ya que emplea las transacciones ACID (es decir, cuando ocurre la actualización, todos los datos relacionados se vuelve constante). La mayoría de los sistemas NoSQL emplean consistencia eventual, lo que significa que, después de la actualización, tomará algún tiempo para que se actualicen los datos relacionados y las réplicas de la base de datos. Los datos a veces se pierden en su proceso. No es bueno si necesita mantener sus registros precisos.
El análisis empresarial
Si va a ejecutar análisis complejos, RDBMS es la mejor opción de la plataforma, ya que permite una disposición muy lógica de almacenamiento de datos y es el mejor tipo de base de datos para ejecutar consultas complejas. Si los análisis tienen la intención de ser simples (por ejemplo, cuántos clientes han gastado más de una cantidad determinada), la base de datos en columnas sería la mejor opción, ya que sería capaz de escanear una columna individual en una tabla sin realizar una exploración de tabla completa.
red social
base de datos de gráfico es el más adecuado para la construcción de la parte central de una red social, ya que este tipo de datos que almacena datos en una forma de red ya. Ambos nodos (por ejemplo, perfiles de usuario) y gráficos (por ejemplo, relaciones) se tratan como tipos de entidad, por lo que los datos de relación se desacoplarán de los datos de perfil de usuario.
Para la funcionalidad de mensajería en la red social, la tienda de documentos es la mejor solución, ya que cada conversación y respuestas posteriores se pueden almacenar en un documento con una estructura lógica secuencial.
La detección del fraude
base de datos de gráfico es la mejor elección de la tecnología aquí.
Juego multijugador
tienda de valor-clave para mantener el estado del jugador.
de comercio electrónico sitio web
Almacén de claves-valor para la cesta de la compra. Almacén de documentos para los productos que se mostrarán en el sitio web. RDBMS para el procesamiento de pagos. Base de datos de gráficos para el motor de recomendaciones.
Para obtener información más detallada, se puede visitar esta página:
Quizás es mejor mirar a algunas otras preguntas relacionadas http://stackoverflow.com/questions/2875432/use-cases-for -nosql –
NoSQL no implica "sin relaciones". En todo caso, simplemente permite formas diferentes (modos RDBMS no tradicionales) de definir datos, relaciones y operadores. db4o, neo4j, e incluso Tutorial D (!) son "NoSQL". Una gran ventaja de estas alternativas es que, en ciertos casos, permite * mucho mejor rendimiento *, especialmente el de las actualizaciones. Otra ventaja es que algunas relaciones simplemente no se ajustan al modelo de SQL: considere un gráfico de objetos, por ejemplo (¡y especialmente uno que sea cíclico!). (Compare esto con algunos motores "RDBMS" que simplemente no proporcionan las restricciones relacionales adecuadas). –
Utilizaría una alternativa NoSQL porque un enfoque tradicional simplemente no manejaría la carga en un sitio web. Aquí hay una discusión sobre NoSQL en Twitter: http://www.computerworld.com/s/article/9161078/Twitter_growth_prompts_switch_from_MySQL_to_NoSQL_database –