¿Cuáles deberían ser las consideraciones para elegir SQL/NoSQL? [cerrado

Question

La aplicación Target es un sitio web de tamaño mediano creado para admitir varios cientos a varios miles de usuarios por hora, con la opción de escalar por encima de eso. El modelo de datos es bastante simple, y el potencial de almacenamiento en caché es bastante alto (relación ~ 10: 1 de acciones de lectura para editar).

¿Cuáles deberían ser las consideraciones al elegir entre un almacén de datos relacional basado en SQL a una opción NoSQL (como HBase y Cassandra)?

Answer 1

Para mí, no tienes ningún problema en particular que resolver. Si necesita acidez, use una base de datos; Si no lo hace, entonces no importa. Al final, simplemente cree tu aplicación. Y déjame citar Nosql: si tan solo fuera tan fácil:

Lo real de señalar es que si se le impide hacer algo súper increíble porque no puede elegir una base de datos, lo está haciendo mal. Si conoces MySQL, solo uséelo. Optimice cuando realmente lo necesite. Úselo como la tienda AK/V, úsela como un RDBMS, pero por el bien de Dios, ¡construya su aplicación asesina! Nada de esto será importante para la mayoría de las aplicaciones. Facebook todavía usa MySQL, mucho. Wikipedia usa MySQL, mucho. FriendFeed usa MySQL, mucho. NoSQL es una gran herramienta, pero ciertamente no será su ventaja competitiva, no va a hacer que su aplicación esté caliente y, sobre todo, a sus usuarios no le importarán nada de esto.

Answer 2

Digg tiene algo interesante artículos Sobre esta pregunta. Esencialmente, está cambiando la carga del procesamiento a escrituras en lugar de lecturas, que pueden ser deseables en aplicaciones altamente escalables. Cassandra específicamente también está altamente disponible.

Simplistamente, Cassandra es una base de datos distribuida con un modelo de datos BigTable que se ejecuta en una infraestructura como Dynamo. Está orientado a columnas y permite el almacenamiento de datos relativamente estructurados. Tiene un modelo totalmente descentralizado; Cada nodo es idéntico y no hay un único punto de falla. También es extremadamente tolerante a fallas; Los datos se replican a múltiples nodos y en todos los centros de datos. Cassandra también es muy elástico; Leer y escribir el aumento del rendimiento linealmente a medida que se agregan máquinas nuevas.

Answer 3

Me gustó la regla general de Ian Eure: "Si está implementando memcache en la parte superior de su base de datos, está inventando su propio sistema ad-hoc y difícil de mantener el sistema NoSQL".

http://www.rackspacecloud.com/blog/2010/02/25/should-you-switch-to-nosql-too/

Answer 4

Cuando dice, Data Modell es bastante simple, esto podría hablar por la opción NoSQL.

Cuando tiene muchos atributos para hacer selecciones, carga de transacción pesada o estructuras de mesa complicadas, que hablarían por las tablas SQL tradicionales.

Recomendaría averiguar qué tan difícil sería implementar el model de datos con una o dos bases de datos NoSQL. Cuando esto es bastante difícil, también puede hacer un esquema de mesa clásico para comparar.

Cuando tiene dificultades con NoSQL, esto podría hablar por la opción SQL. Pero también podría ser que la carga pesada se maneje mejor con NoSQL, pero también podría ser que una buena base de datos SQL escala lo suficiente ...

El almacenamiento en búfer también se puede hacer con un simple servidor proxy ...

En las dificultades, también podría considerarse una mezcla de NoSQL y SQL.