Estoy en el medio de diseñar una aplicación altamente escalable que debe almacenar una gran cantidad de datos. Solo por ejemplo, almacenará mucho sobre los usuarios y luego cosas como muchos de sus mensajes, comentarios, etc. Siempre he usado MySQL pero ahora estoy dispuesto a probar algo nuevo como couchdb o similar que no sea SQL.SQL (MySQL) vs NoSQL (CouchDB)
¿Alguien tiene alguna idea u orientación sobre esto?
Aquí hay una cita de un reciente blog post from Dare Obasanjo.
bases de datos SQL son como transmisión automática y bases de datos NoSQL son como transmisión manual. Una vez que cambie a NoSQL, se convierte en responsable de un montón de trabajo que el sistema se ocupa automáticamente en un sistema de base de datos relacional. Similar a lo que sucede cuando se elige manual sobre transmisión automática. En segundo lugar, NoSQL le permite obtener más rendimiento fuera del sistema por eliminando una gran cantidad de comprobaciones de integridad realizadas por bases de datos relacionales desde el nivel de base de datos . Nuevamente, esto es similar a para obtener más rendimiento de su automóvil al conducir una transmisión manual en comparación con un vehículo de transmisión automática .
Sin embargo, la similitud más notable es que al igual que la mayoría de nosotros no puede realmente tomar ventaja de los beneficios de un vehículo de transmisión manual porque la mayoría de nuestra conducción está sentado en el tráfico en el camino de ida y de trabajo, hay una realidad áspera similar en que la mayoría de los sitios no están en Google o escala de Facebook y por lo tanto no tienen necesidad para un Bigtable o Cassandra.
A lo que se puede agregar sólo que el cambio de MySQL, donde tiene al menos un poco de experiencia, a CouchDB, donde usted no tiene experiencia, significa que tendrá que hacer frente a un nuevo conjunto de problemas y aprender diferentes conceptos y mejores prácticas. Mientras que esto es maravilloso (estoy jugando en casa con MongoDB y me gusta mucho), será un costo que tendrá que calcular al estimar el trabajo para ese proyecto, y trae riesgos desconocidos mientras promete beneficios desconocidos. Será muy difícil juzgar si puede realizar el proyecto a tiempo y con la calidad que desea/necesita tener éxito, si se basa en una tecnología que no conoce.
Ahora, si tiene en el equipo un experto en el campo NoSQL, no dude en echarle un vistazo. Pero sin ninguna experiencia en el equipo, no se suba a NoSQL para un nuevo proyecto comercial.
Actualización: Para echar un poco de gasolina en el fuego abierto que comenzó, aquí hay dos artículos interesantes de personas en el campamento SQL.:-)
I Can't Wait for NoSQL to Die (artículo original se ha ido, he aquí una copy)
Fighting The NoSQL Mindset, Though This Isn't an anti-NoSQL Piece
actualización: Bueno, aquí es un interesante artículo sobre NoSQL
Making Sense of NoSQL
El proceso de escalado de soluciones SQL es el proceso de eliminación de características y relaciones. Entonces, no creo que esta sea una evaluación completamente justa. Además, no agruparía bases de datos NoSQL así, Cassanda, por ejemplo, se enfoca únicamente en escalar * up *, mientras que CouchDB está preocupado por escalar la API * hacia abajo * y hacerlo más fácil de usar e intenta permitir que la API escale en la medida como sea posible – mikeal
¿Podría ser este el enlace a la cita? http://www.25hoursaday.com/weblog/2010/03/29/TheNoSQLDebateAutomaticVsManualTransmission.aspx – edosoft
Ah, sí de hecho. Me perdí que él también lo hizo una publicación pública en el blog. Actualizaré la publicación. –
parece que sólo las soluciones reales de hoy giran en torno escalar o sharding. Todas las bases de datos modernas (NoSQL y NewSQL) admiten la escala horizontal desde el primer momento, en la capa de la base de datos, sin la necesidad de que la aplicación tenga código de fragmentación o algo así.
Lamentablemente, para el confiable y viejo MySQL, la fragmentación no se proporciona "de fábrica". ScaleBase (descargo de responsabilidad: yo trabajo allí) es un creador de una solución de escalamiento completo, una "máquina de fragmentación automática" si lo desea. ScaleBae analiza sus datos y secuencias SQL, divide los datos en nodos DB y agrega en tiempo de ejecución, por lo que no tendrá que hacerlo. Y es de descarga gratuita.
No me malinterpreten, los NoSQL son geniales, son nuevos, nuevos son más opciones y la elección siempre es buena. Pero la elección de NoSQL viene con un precio, asegúrese de que puede pagarlo ...
Se puede ver aquí algunos datos más sobre MySQL, NoSQL ...: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding
esperanza de que ayudó.
Una de las mejores opciones es ir por MongoDB (NOSql dB) que admite escalabilidad. Almacena grandes cantidades de datos nada más que bigdatos en forma de documentos, a diferencia de las filas y tablas en sql. Esto es ayuno que sigue a shradding del data.Uses de replicación para garantizar la garantía de los datos que mantiene varios servidores con el servidor de base de datos primaria como base. Idioma independiente. Flexible de usar
Debe hacer una copia de seguridad de su opinión como "mejor" porque Couchbase, Cassandra, AeroSpike, etc. y todas las bases de datos que admiten las funciones que menciona. –
Gah, CW. Y esperaba obtener algún representante real y algo de credibilidad callejera aquí. :-) –
¿Puedes explicar un poco más sobre tu conjunto de datos? – mikeal