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

Question

La aplicación de destino 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 a edición).

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

Answer 1

Para mí, no tiene ningún problema en particular para resolver. Si necesita ACIDity, use una base de datos; si no lo haces, entonces no importa. Al final solo crea tu aplicación. Y permítanme citar NoSQL: If Only It Was That Easy:

Lo real a señalar es que si usted está siendo abstuvo de hacer algo muy impresionante porque no se puede elegir una base de datos, lo estás haciendo mal. Si conoce mysql, simplemente lo usó. Optimizar cuando realmente lo necesite. Úselo como una tienda k/v, úselo como un rdbms, ¡pero por el amor de Dios, construya su aplicación asesina! Nada de esto importará en 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 va a ser su ventaja competitiva, no va a hacer que su aplicación se caliente, y sobre todo, a sus usuarios no les importará nada de esto.

Answer 2

Digg have some interestingarticles en esta pregunta. Básicamente, está transfiriendo la carga del procesamiento a escrituras en lugar de a lecturas, lo que puede ser deseable en aplicaciones altamente escalables. Cassandra específicamente también está altamente disponible.

manera simplista, Cassandra es una base de datos distribuida con un modelo de datos BigTable se ejecuta en un Dynamo como infraestructura. Está orientado a columnas y permite el almacenamiento de datos relativamente estructurados. Tiene un modelo totalmente descentralizado ; cada nodo es idéntico y no existe un solo punto de falla . También es extremadamente tolerante a fallas; los datos se replican en nodos múltiples y en los centros de datos . Cassandra también es muy elástica ; el rendimiento de lectura y escritura aumenta linealmente a medida que se agregan máquinas nuevas .

Answer 3

Cuando dices, el modelado de datos es bastante simple, esto podría hablar de la opción NoSQL.

Cuando tiene muchos atributos para realizar selecciones, cargas de transacciones pesadas o estructuras de tablas complicadas, que hablarían en las tablas SQL tradicionales.

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

Cuando tiene dificultades con NoSQL, esto podría significar la opción de 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 se escale lo suficiente ...

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

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

Answer 4

me gusta regla de oro de Ian Eure: “si va a implementar memcache en la parte superior de su base de datos, que está inventando su propio ad-hoc, difícil de mantener el sistema de NoSQL.”

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