2011-06-10 29 views
6

Cuando se trata de NoSQL, hay un número desconcertante de opciones para seleccionar una base de datos NoSQL específica, como es evidente en el wiki NoSQL.¿Qué base de datos NoSQL usar como reemplazo de MySQL?

En mi aplicación quiero reemplazar mysql con la alternativa NOSQL. En mi aplicación, tengo una tabla de usuarios que tiene una relación de uno a muchos con una gran cantidad de otras tablas. Algunas de estas tablas están a su vez relacionadas con otras tablas. También tengo un usuario conectado a otro usuario si son amigos.

No tengo documentos para almacenar, por lo que esto elimina las bases de datos orientadas a documentos NoSQL. Quiero un rendimiento muy alto. La base de datos NOSQL debería funcionar muy bien con Play Framework y el lenguaje scala. Debe ser de código abierto y gratis.

Así que, ¿qué base de datos NoSQL debería usar?

Respuesta

1

En este punto la respuesta es ninguna, me temo.

No puede simplemente convertir su modelo relacional con combinaciones en un diseño de tienda clave-valor y esperar que sea una asignación 1: 1.Por lo que dices, parece que tienes uniones, algunas recursivas, es decir, haciendo referencia a otra fila de la misma tabla.

Puede comenzar por desnormalizar su esquema relacional existente para acercarlo más al diseño que desea lograr. Entonces, podría ver más fácilmente si lo que está tratando de hacer se puede hacer de una manera práctica y qué tecnología elegir. Incluso puede elegir continuar usando MySQL. El hecho de que pueda tener uniones no significa que deba hacerlo, lo que permite tener un diseño no relacional en un DBMS relacional como MySQL.

Además, tenga en cuenta que las bases de datos no relacionales se diseñaron para la escalabilidad, ¡no para el rendimiento! Si no tiene miles de usuarios y una granja de servidores, una base de datos relacional tradicional puede funcionar mejor para usted.

+2

Está confundiendo almacenes de datos NoSql y valor-clave. Existen bases de datos NoSql como las bases de datos Graph (Neo4J) y las bases de datos OO (db4o) que no son almacenes de datos clave-valor. Ofrecen poderosos mecanismos relacionales. –

+0

@Vagif: Honestamente, realmente no me gusta el nombre NoSQL (o no relacional) porque define lo que no es más que lo que es. Siguiendo el mismo razonamiento, creo que el sistema de archivos pasado de moda podría llamarse NoSQL porque no es SQL o relacional. OTOH, tienes razón sobre los almacenes de datos de gráficos, no había pensado en eso. –

+0

Bueno, tenemos a los ateos que se definen por lo que no tienen, en lugar de lo que tienen. En un mundo dominado por la religión, el ateísmo es una definición válida. En un mundo dominado por bases de datos SQL, supongo que NoSql tiene un significado. –

8

Creo que puede estar malinterpretando la naturaleza de las "bases de datos de documentos". Como tal, recomendaría MongoDB, que es una base de datos de documentos, pero creo que te gustará.

MongoDB almacena "documentos" que son básicamente registros JSON. La mejor parte es que entiende las partes internas de los documentos que almacena. Así que dado un documento como este:

{ 
    "name": "Gregg", 
    "fave-lang": "Scala", 
    "fave-colors": ["red", "blue"] 
} 

Se pueden realizar consultas sobre "favorito-lang" o "FAVE-colores". Incluso puede indexar en cualquiera de esos campos, incluso en la matriz "fave-colors", que necesitaría una tierra relacional de muchos a muchos.

Play ofrece un complemento de MongoDB que no he usado. También puede usar el Casbah driver for MongoDB, que he usado mucho y es excelente. La consulta DSL Rogue para MongoDB, escrita por FourSquare también vale la pena mirar si le gusta MongoDB.

MongoDB es extremadamente rápido. Además, se ahorrará la molestia de escribir esquemas porque cualquier registro puede tener los campos que desee, y aún se pueden buscar e indexar. Es probable que su modelo de datos se parezca mucho al que tiene ahora, con una "colección" de usuarios (como una tabla) y otras colecciones con registros que hacen referencia a una identificación de usuario según sea necesario. Pero si necesita agregar un campo a una de sus colecciones, puede hacerlo en cualquier momento sin preocuparse por los registros anteriores o la migración de datos. Técnicamente no hay esquema para los registros de MongoDB, pero terminan organizando registros similares en colecciones.

MongoDB es una de las tecnologías más divertidas que he encontrado en los últimos años. En ese feliz sábado decidí comprobarlo y en 15 minutos fue productivo y sentí que lo "conseguí". De forma rutinaria hago una demostración en el trabajo en la que le muestro a la gente cómo iniciarse con MongoDB y Scala en 15 minutos y eso incluye la instalación de MongoDB. enchufe descarado si estás en servicios web, aquí está mi entrada de blog sobre cómo empezar con MongoDB y Scalatra usando Casbah: http://janxspirit.blogspot.com/2011/01/quick-webb-app-with-scala-mongodb.html

usted debe por lo menos ir a http://try.mongodb.org

Eso es lo que me inició.

¡Buena suerte!

+0

Muchas gracias por los detalles. ¿Se puede usar mongodb para una relación como un objeto de usuario es amigo de otro objeto de usuario y de una a muchas relaciones? – ace

+0

Sí, hay un formato común para vincular de un objeto a otro, pero usted debe seguir los enlaces usted mismo. No hay uniones como en una base de datos relacional. –

2

Hmm, quiere un muy alto rendimiento de recorrido y usa la palabra "amigos". Lo primero que se me viene a la mente es Graph Databases. Están hechos específicamente para este caso exacto.

Trate Neo4j http://neo4j.org/

Es es gratuito, de código abierto, pero también cuenta con el apoyo comercial y las licencias comerciales, tiene una excelente documentación y se puede acceder desde muchos idiomas (interfaz REST).

Está escrito en Java, por lo que tiene librerías nativas o puede incrustarlo en su aplicación java/scala.

+0

Gracias por esta idea. ¿Puede decirme si neo4j es gratuito para uso comercial sin que mi proyecto sea de código abierto? Esto no fue claro desde su sitio web. – ace

+0

Sí. Es gratis si la aplicación es para uso interno de la compañía. Pero si está atendiendo clientes en la web, entonces debe abrir el código fuente o comprar una licencia comercial. –

0

En cuanto a MongoDB o Cassendra, ahora (diciembre de 2016, 5 años tarde) prueba longevityframework.org.

Cree su modelo de dominio utilizando expresiones estándar de Scala como clases de casos, objetos complementarios, opciones y colecciones inmutables. Cuéntanos sobre los tipos en tu modelo y proporcionamos la persistencia.

Ver "More Longevity Awesomeness with Macro Annotations!" de John Sullivan.
Proporciona un example on GitHub.

Si ha analizado la longevidad con anterioridad, se sorprenderá de lo fácil que ha sido comenzar a persistir en los objetos de su dominio. Y la mejor parte es que todo lo relacionado con la persistencia está escondido en las anotaciones. Sus clases de dominio están libres de preocupaciones de persistencia, expresan perfectamente su modelo de dominio y están listas para usar en todas las partes de su aplicación.

Cuestiones relacionadas