score:0

well, mongodb and mysql are both gpl, and apart from the way you query the mongodb there are performance advantages in the way data is stored.

in mongodb , data is stored as data pages, which is a stuctured substitution of many dozens of tables in mysql, hence when you query the mongodb, you access the index lookup and retrieve data from the one page.

in mysql, for the same data, because it is laid out in a few dozens of tables, you would be doing dozens of index lookups, dozens of range lookups and dozens of data lookups.

hence, winner of the first round is mongodb.

i don't know much about hbase, but there is this great comparison graphs shown here where again, mongodb seems to have the upper hand.

score:0

perhaps a use case would be in order for answers to be more appropriate. generally the type of data and its use would dictate whether one uses sql(relational e.g. mysql) or nosql architecture(e.g. mongodb).

this article might help give direction.

....as programmers we can embrace what we’re given. most likely we’ll have our own opinions. i sure do. but if you’re doing something that lends itself nicely to sql tables, then we can get our job done. if you’re doing something that requires complex data structures and lends itself nicely to a nosql database, then we can similarly get our job done....

score:0

these days, happily, choosing a database can be an challenging exercise, because of the incredibly diverse landscape. here's a fun visual which highlights this point:

http://blogs.the451group.com/information_management/files/2013/02/db_map_2_13.jpg

the choice should really be driven by what's easiest to use from a developer skill and api perspective, the structure and size of your data, how often you write your data versus how often you read your data, what kind of acid requirements you need and lastly how your application needs to scale. i put scalability last, because in most cases, when you put scalabilty first the result is a solution without a problem. if it's a new application, you may not, in fact, really know anything about scalability requirements, so i would choose something that fits your other needs. since your application is built in scala might also consider the maturity and quality of scala-friendly wrappers available for the technology under consideration. this is especially important to think about if you decide to adopt a non-relational database, because you may have to give up the unifying jdbc api for which there already exist many scala-friendly wrappers.

since you specifically mention mongodb and hbase, i'm assuming you might have a reason to use a non-relational database. in fact, at this early stage, the hard choice you're faced with is really whether to adopt a relational or non-relational solution. if you choose a relational solution, then moving from one relational database to another can be relative easy. this is less true if you choose a non-relational database, because the apis differ greatly from one type non-relational database to another.

so how do know whether you need to adopt a non-relational database?

  1. do you have tables with many columns?
  2. do you have tables with few columns but many relations?
  3. do you have tree-like data where there are children with parents and ancestors?
  4. are you planing on storing structured data formats such as xml or json?
  5. do you foresee the need to frequently change the database schema?

if you answered yes to any of these questions you may be non-relational, but you're probably not a redneck. in this case, the second hardest question is which non-relational database to choose. again, choose based on your data structure and how well they fit with other technology choices, what acid properties you need, where your skills lie and what's easiest.

score:1

first of all, as others have said, the choice of your persistence layer depends on your use case.

in case you are looking for a sql solution, take a look at the overview on the so answer to "good examples of scala database persistence", which gives examples for:

you might also want to look at the sorm framework.

for slick, there is a promising project, play-slick, that helps integrate it into the play framework.


Related Query

More Query from same tag