Je développe un nouveau projet à Scala. C'est une application pour un groupe d'opérations de CRUD, cependant, en raison de certaines exigences excentriques, la lecture2 ou l'ascenseur ne convient pas à la facture, je vais donc développer l'application à partir de la terre. Cela signifie que Anorm ou Scalaquery devient moins évident pour l'intégration de la base de données et me laisse avec la question: est-il temps d'essayer quelque chose de nouveau?
Mes piles technologiques antérieures incluaient principalement Java et PostgreSQL et j'ai une expérience avec OrM et SQL uni. Les systèmes de gestion de la base de données NOSQL sont-ils comme MongoDB un bon remplacement pour un SGBDM typique ou sont-ils des magasins de données d'application spéciaux? En outre, comment le choix de la base de données effectue-t-il la conception du système de Scala Grand Scala (si du tout)? Par exemple, le fait que vous utilisiez une interface de type JSON pour parler à la base de données et Json entre le Web et un service de repos ne signifie pas que beaucoup si tout au milieu devient des objets Scala, ou le fait-il?
Je demande essentiellement l'expérience de quelqu'un pour passer de bases de données relatives à l'objet / type de document, à l'aide de Scala en particulier. Je sais que la bonne intégration RDBMS est promise dans la prochaine version de Slick. Donc, si une entreprise comme Typeafe décide de faire une partie intégration de la SJB de la pile Typeafe, puis-je nager en amont en s'intégrant à MongoDB à l'aide de Casbah par exemple?
excuses si cette question apparaît un peu vague. J'espère que quelqu'un avec les bonnes perspectives ou l'expérience sera en mesure de vous aider.
mise à jour:
excuses pour ne pas ajouter de liens à Slick (il est assez nouveau). Voici:
mise à jour 2:
Ma première victoire personnelle pour une technologie est généralement productivité du développeur - cela se traduit par la légère et simple: rapide à apprendre, facile à entretenir, pas de magie
3 Réponses :
Je suis actuellement dans une situation similaire, et puisque j'ai une certaine expérience avec le développement Web et les bases de données SQL, je l'ai prise comme une opportunité de travailler avec MongoDB, Cashbah (et Scalatra ). Mon expérience est toujours très limitée et le projet et la quantité de données que je travaille sont assez petites, mais voici quelques observations que j'ai faites.
Pour les quelques séries de données que j'ai, les performances ne semblent pas motiver SQL ou NOSQL. Toutefois, la performance en présence d'énormes quantités de données est souvent inscrite comme une raison pour utiliser NOSQL, par exemple par Wikipedia < / p>
Mes documents (entrées de la base de données) découlent des combinaisons d'essai d'analyse comparative et possèdent principalement une structure statique et je suis optimiste que je pouvais les stocker dans une base de données Schema SQL fixe. Cependant, quelques sous-structures ne sont pas statiques, par exemple, de nouveaux cas de test sont ajoutés, de nouvelles statistiques sont suivies, d'autres sont supprimées. C'était ma principale motivation pour essayer une base de données NOSQL sans schéma. En outre, parce que j'avais le sentiment que l'approche du document de MongoDB rend cela beaucoup plus évidente quelles données appartiennent ensemble (c'est-à-dire à un document), contrairement aux entrées dans une base de données relationnelle, où les données seraient distribuées sur diverses tables et lignes et où un "document" complet devrait être reconstruit par des jointures.
outils tels que ascenseur-json ou Rogue vous permet de travailler avec des objets Scala réguliers dans un type de sécurité, bien que les données soient régulièrement (de) sérialisées (de ) JSON. Cependant, cela fonctionne naturellement mieux si la structure de vos données est principalement statique, sinon, vous vous trouvez à l'aide de chaînes pour accéder à vos données (par exemple, pour élargir les résultats d'une requête en utilisant Cashbah).
Si vous êtes principalement préoccupé par une représentation cohérente des données sur le serveur et la clientèle, des langues telles que opa ou Haxe pourrait être d'intérêt, car ils compilent le code qui peut être exécuté des deux côtés. Voir Cette page pour "Multitarget" ou "Netlessless "Langues.
Des points valables, merci. Sur votre troisième point, j'ai le sentiment que l'on sent qu'un type de négociation de l'une des raisons réelles d'aller à la première place si vous souhaitez rester en sécurité. La sécurité et la structure dynamique sont-elles une correspondance difficile?
Supposons que vos données soient d'une structure partiellement statique, par ex. {x: _, y: _, z: {A: _, b: _}}, où x, y, z sont les seuls éléments de niveau supérieur et leur existence est garantie, mais la structure de Z n'est pas statique. Si tel est le cas, vous pouvez essayer de trouver une tache sucrée en utilisant des classes (cas) où les parties statiques de la structure sont mappées dans des champs de types de béton (INT, de chaîne, etc.), et ceux avec une structure inconnue sont mappés sur la carte. [Chaîne, tout]. La cartographie peut être effectuée via Ascenseur-Json ou Roque.
Trop longtemps pour un commentaire. J'essaie juste de relier ma courte expérience avec Scala (environ 6 mois maintenant, puisque quand jouer2 est sorti - il est rapidement devenu mon aller à la langue).
J'ai aimé utiliser Salat / Casbah avec Mongodb dans mes derniers projets; La plupart ont été en jeu2, mais le dernier était sans cadre WebApp. Il n'a certainement pas eu l'impression de nager en amont.
Je dirais qu'il existe des cas d'utilisation particuliers pour lesquels je n'utiliserais pas de Mongo, mais cela fonctionne bien comme un magasin d'objet d'objet à usage général, surtout si vous vous attendez à interroger par ID ou index et que vous n'avez pas besoin de transactions ( et aura besoin de type d'agrégation ad-hoc minimale).
Attendez-vous à exiger un ensemble séparé de serveurs dédié à mongodb (ou d'utiliser un service dédié à MongoDB), mais je suppose que c'est normal pour la plupart des applications de base de données sérieuses.
J'ai aussi utilisé la lecture2 / Anorm, qui était étonnamment agréable à utiliser pour certaines pages de rapport de style Dashboard de la requête ad-hoc. J'ai commencé à essayer d'aller à l'itinéraire Squaryl, mais que Anorm semblait plus facile à utiliser pour des requêtes d'agrégation one-off. Je n'ai pas regardé Slick, mais cela semble intéressant.
J'apprécie l'entrée (long commentaire ;-), merci. Intéressant que vous avez mentionné un serveur dédié. Les ressources matérielles sont quelque chose que l'on épait facilement ces jours-ci, mais cela peut parfois être une vraie préoccupation.
Eh bien, j'accueille une petite lampe de petite lampe sur une boîte, ce qui tend à garder la raccourcie, mais même pour de petites choses, je dirais que vous avez un Mongo dédié; Cela n'aime pas partager la RAM de manière gérable. J'adore toujours l'utiliser, mais je l'avais tué de ma boîte A Apache plus d'une fois (a finalement dû le déplacer vers sa propre réplique, ce qui est mieux à long terme, de toute façon).
Il est vraiment difficile de dire sans savoir quels problèmes vous souhaitez que l'application résolve.
J'ai personnellement trouvé ma productivité augmentait à l'aide de NOSQL DBS via REST / JSON. Bien que la plupart des DD de Nosql offrent des interfaces de repos qui empêchent le besoin de middleware, de Scala ou non, sauf si vous avez l'intention d'écrire une webApp avec une interface utilisateur.
S'il s'agit d'un exercice d'apprentissage, je vous recommande d'essayer de multiples choses, car chaque DB NOSQL a quelque chose de différent à offrir à votre boîte à outils et a personnellement trouvé Couchdb, Riak, Neo4J et MongoDB avec différents plans et inconvénients et bon à des fins différentes.
J'espère que cela vous aide, bonne chance.
BTW, merci d'avoir mentionné Slick, je ne le savais pas.
Slick est l'ancienne "scalaquery" bientôt incluse dans Typeafe Stack
Qu'avez-vous décidé? Comment c'était?
@ballmw j'ai fini par utiliser Slick avec PostgreSQL. La documentation sur Slick est un peu mince, mais ça va mieux. Il existe des options plus faciles que Slick, et les messages d'erreur de Slick sont actuellement assez cryptiques, mais cela vous donne des tonnes de liberté et vous permet de composer des requêtes complexes des plus simples, ce qui est une grande victoire. C'est une solution solide. Je suis heureux.