2012-07-03 12 views
7

Estoy desarrollando un nuevo proyecto en Scala. Es solo una aplicación para un montón de operaciones CRUD, sin embargo, debido a algunos requisitos excéntricos, Play2 o Lift no se ajustan a la ley, por lo que voy a desarrollar la aplicación desde cero. Esto significa que Anorm o ScalaQuery se convierten en opciones menos obvias para la integración de bases de datos, y me deja con la pregunta: ¿es hora de probar algo nuevo?NoSQL (por ejemplo, MongoDB) o RDMS (por ejemplo, PostgreSQL) para el nuevo proyecto de Scala?

Mis últimas pilas de tecnología incluyen Java y PostgreSQL y tengo experiencia con ORM y SQL simple. ¿Los sistemas de administración de bases de datos NoSQL como MongoDB son un buen reemplazo para un RDBMS típico o son tiendas de datos de aplicación de casos especiales? Además, ¿cómo afecta la elección de la base de datos al mayor diseño del sistema Scala (si es que lo hace)? Por ejemplo, el hecho de que esté utilizando una interfaz similar a JSON para hablar con la base de datos, y JSON entre la web y un servicio REST, no significa mucho si todo en el medio se convierte en objetos Scala, ¿o no?

Básicamente, estoy solicitando la experiencia de alguien al pasar de bases de datos relacionales a objetos/documentos, utilizando Scala en particular. Sé que se promete una buena integración RDBMS en el próximo lanzamiento de SLICK. Entonces, si una compañía como TypeSafe decide hacer una integración RDBMS como parte de la pila de TypeSafe, entonces ¿estaré nadando río arriba integrándola en MongoDB usando Casbah, por ejemplo?

Disculpas si esta pregunta parece un poco vaga. Sin embargo, espero que alguien con los conocimientos o la experiencia adecuada pueda ayudar.

Actualización:

Disculpas por no añadir enlaces a PAREJO (siendo bastante nuevo). Aquí va:

Actualización 2:

Mi primera victoria personal para una tecnología es por lo general la productividad desarrollador - esto se traduce en ligero y sencillo: rápida a aprender, fácil de mantener, sin magia

+0

Por cierto, gracias por mencionar SLICK, no sabía nada al respecto. –

+1

Slick es el antiguo "scalaquery" que pronto se incluyó en la pila typesafe – iwalktheline

+0

¿Qué decidiste? ¿Como le fue? – ballmw

Respuesta

5

Actualmente estoy En una situación similar, y dado que tengo cierta experiencia con el desarrollo web y bases de datos SQL, lo tomé como una oportunidad para trabajar con MongoDB, Cashbah (y Scalatra). Mi experiencia es muy limitada y el proyecto y la cantidad de datos con los que estoy trabajando son muy pequeños, pero aquí hay algunas observaciones que hice.

  • Para los pocos conjuntos de datos que tengo, el rendimiento no parece motivar ni a SQL ni a NoSQL. Sin embargo, el rendimiento en presencia de grandes cantidades de datos a menudo aparece como una razón para usar NoSQL, por ejemplo, by Wikipedia

  • Mis documentos (entradas en la base de datos) surgen de los trajes de prueba de benchmarking, y principalmente tienen una estructura estática, y soy optimista de que podría almacenarlos en una base de datos SQL de esquema fijo. Sin embargo, algunas subestructuras no son estáticas, por ejemplo, se agregan nuevos casos de prueba, se rastrean nuevas estadísticas y se eliminan otras. Esta fue mi motivación principal para probar una base de datos NoSQL sin esquema. Además, porque tenía la sensación de que el enfoque documental de MongoDB hace que sea mucho más obvio qué datos pertenecen juntos (es decir,, a un documento), a diferencia de las entradas en una base de datos relacional, donde los datos se distribuirán en varias tablas y filas, y donde un "documento" completo tendría que ser reconstruido mediante combinaciones.

  • Herramientas como Lift-Json o Rogue le permiten trabajar con objetos normales Scala de un tipo seguro, aunque los datos son regularmente (des) serializado como JSON (desde). Sin embargo, esto funciona naturalmente mejor si la estructura de sus datos es principalmente estática, de lo contrario, le quedan cadenas de caracteres para acceder a sus datos (por ejemplo, para expandir los resultados de una consulta con Cashbah).



Si usted está preocupado principalmente por una representación coherente de los datos en el servidor y en el cliente, idiomas como el Opa o Haxe podría ser de interés, ya que compilar a código que se ejecuta en ambos lados. Consulte this page para idiomas "multitarget" o "sin niveles".

+0

Algunos puntos válidos, gracias.En su tercer punto, me da la sensación de que uno de los tipos tiene que cambiar uno de los motivos reales para ir a no relacional en primer lugar si desea permanecer seguro. ¿Es la seguridad de tipo y la estructura dinámica una coincidencia difícil? – Jack

+0

Supongamos que sus datos tienen una estructura parcialmente estática, p. {x: _, y: _, z: {a: _, b: _}}, donde x, y, z son los únicos elementos de nivel superior y su existencia está garantizada, pero la estructura de z no es estática. Si es así, puede intentar encontrar un punto óptimo usando clases (caso) donde las partes estáticas de la estructura se asignan a campos de tipos de concreto (Int, String, etc.) y aquellas con una estructura desconocida se asignan a Map [String, Cualquiera]. El mapeo se puede hacer a través de Lift-Json o Roque. –

+0

Ahora Scala tiene el objetivo JS también (: http://www.scala-js.org/ – uhbif19

3

Tengo demasiado tiempo para un comentario. Solo estaba tratando de relatar mi corta experiencia con Scala (hace unos 6 meses, aproximadamente cuando salió Play2, se convirtió rápidamente en mi idioma).

He disfrutado usando Salat/Casbah con MongoDB en mis últimos proyectos; la mayoría han estado en Play2, pero la última fue sin un framework webapp. Definitivamente no ha sentido ganas de nadar río arriba.

Yo diría que hay casos de uso particulares para los que no usaría mongo, pero funciona muy bien como un almacén de datos de objetos de propósito general, especialmente si espera consultar por id o índice y no necesita transacciones (y necesitará un tipo mínimo de agregación ad-hoc)

Espere requerir un conjunto separado de servidores dedicados a mongodb (o para usar un servicio dedicado a mongodb), pero supongo que eso es normal para la mayoría de las aplicaciones de bases de datos serias.

También he usado Play2/Anorm, que fue sorprendentemente agradable de usar para algunas páginas de informes de estilo ad hoc del panel de control. Empecé a tratar de ir a la ruta Squeryl, pero parecía más fácil de usar para las consultas de agregación únicas. No he mirado SLICK, pero parece interesante.

+0

Agradezco la entrada (comentario largo ;-), gracias. Es interesante que haya mencionado un servidor dedicado. Los recursos de hardware son algo que uno fácilmente encoge de hombros fuera de estos días, pero a veces puede ser una preocupación real. – Jack

+0

Bueno, tengo cosas pequeñas LAMP en una caja, que tiende a seguir resoplando, pero incluso para cosas pequeñas, yo diría que asegúrate de tener un mongo dedicado; Me gusta compartir RAM de una manera manejable. Todavía me encanta usarlo, pero he tenido que matar a mi caja de apache más de una vez (eventualmente tuve que moverla a su propio conjunto de réplicas, que es mejor a la larga , de todas formas). –

2

Es realmente difícil de decir sin saber qué problemas le gustaría que resolviera la aplicación.

Personalmente, he visto aumentar mi productividad usando NoSQL DB mediante REST/JSON. Sin embargo, tenga en cuenta que la mayoría de los DB NoSQL ofrecen interfaces REST que excluyen la necesidad de mucho middleware, Scala u otros, a menos que tenga la intención de escribir una aplicación web con una IU.

Si se trata de un ejercicio de aprendizaje, recomiendo probar varias cosas, ya que cada base de datos NoSQL tiene algo diferente que ofrecer a su conjunto de herramientas, y personalmente han encontrado CouchDB, Riak, Neo4j y MongoDb con varias ventajas y desventajas y bueno para diferentes propósitos.

Espero que esto ayude, buena suerte.

Cuestiones relacionadas