7 ms·

How You Should Go About Learning NoSQL

81 points by latch 15y ago

perfunctory 15y ago
How can one learn something that is defined by what it is not.
- virmundi 15y ago
  This thought is not mine, but I cannot recall the source: NoSQL is a bad name; it should be NotSQL. As a result it is a very large umbrella. When one sees NoSQL it is a safe assumption to think MongoDB. But you could also think DB4O (I like this much more, in an abstract way). So you can go about learning any of these technologies since you find an instance of NotSQL. To learn NoSQL, you are really still able to learn this. You are learning a philosophy rather than a technology.
  - nickknw 15y ago
    I remember reading something by Erik Meijer where he states he also thinks it is an unfortunate name. I think he suggested coSQL, and gave an interesting perspective on the relationship between SQL and noSQL. This was the article: http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-model-of-data-for-large-shared-data-banks http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-...
rsbrown 15y ago
Very light reading, but all the same an excellent overview of MongoDB, Redis and Cassandra. Well done.
Cloven 15y ago
"Yesterday I tweeted three simple rules to learning NoSQL. Today I'd like to expand on that. The rules are: 1: Use Mon" CTRL-W
- bretthoerner 15y ago
  I originally skipped the article, and thought you were kidding... Alas...
- latch 15y ago
  What path would you suggest people take in learning something that challenges decades of best practices?
  - knieveltech 15y ago
    1st, be damned sure that decades old best practices actually aren't the best tool for your current application, developer hype be damned.
    - latch 15y ago
      Hard to know whether they aren't the best tool for the job without at least familiarizing yourself with some alternatives.
yummyfajitas 15y ago
Step 1 in learning NoSQL: learn SQL very well. There is a good chance it already solves your problems AND ensures your data makes sense.
- timanglade 15y ago
  Step 2: convince yourself that you should only use NOSQL if you absolutely have to. (Corollary: if you ask for NOSQL by name, you most probably don’t need it.)
- mtogo 15y ago
  As a bonus, SQL cares about data reliability. Not that all of "NoSQL" doesn't, but two major "NoSQL" databases, Redis and MongoDB, both seem to care more about performance than durability.
  - rbranson 15y ago
    MySQL cares about data reliability? Maybe if you spend much time agonizing over the configuration and set it to strict mode.
    - mtogo 15y ago
      I generally don't use MySQL, but iirc it confirms that nothing went wrong saving the data (whereas with mongo there is no confirmation step, you just have to hope that it was successful), and the data is written to disk. Additionally, i've heard of zero "Oh no, MySQL just lost 50% of my production database!" where it wasn't the user's fault, and i've heard enough of that from Mongo to stay away.
      - jasonmccay 15y ago
        Respectfully, this isn't true. Yes, fire and forget is the default behavior, but there is a confirmation step that you can check. It may be implemented a bit differently from driver to driver, but it is generally called a "safe insert". Numerous people use this to ensure their writes across single databases as well as multi-node master-slave and replica sets.
nkh 15y ago
From the article: A lot of NoSQL solutions are about solving specific problems. MongoDB is a general solution which can (and probably should) be used in 90% of the cases that you currently use an RDBMS. As I use don't use any NoSQL solutions today, can someone list out a few of these cases where I am using an RDBMS and I should be using MongoDB?
- latch 15y ago
  When you want to do many small real time operations against your data. The model fits well with most web sites (the unit of work for a given request tends to be quite small). Loggin also comes to mind as does some basic geospatial work. I think for most cases it does what a RDBMS can do but with less friction (you'll still use an ORM/ActiveRecord, but it'll be a much more lightweight). Why don't you check out mongly.com/tutorial/index and get a quick feel for it?
  - nkh 15y ago
    That makes sense, but it is certainly not 90% of what I use an RDBMS for as the author stated. Especially if most of the things I do are not real time web. I will take a look at the link above, as I am curious about it. But I am still struggling for use cases. By the way, thank you for your comment. I up-voted it.
- mtogo 15y ago
  I'm wondering about this too. For almost everything i work on, the data being in the correct format, written to disk, and stored reliably is more important than the speed or other advantages of Mongo.
  - jasonmccay 15y ago
    I have a hard time understanding responses like this and, in the end, they make me think that people a) really don't understand some of these new data technologies and b) are just as much on the anti-bandwagon as those that sit on the latter. For people using MongoDB daily, their data is in the correct format, it is persisted to disk, it is stored reliably and it is fast. On top of that, it gives them flexibility as their web app changes and new features and data structures are added, it is easily viewed and manipulated in JSON-format, and if and when the day comes that they need serious scaling, it helps there as well. Also, in the world of EC2, it is straight-forward to set up replica sets to offer redundancy. All these conversations sound eerily familiar to the Java guys bashing Ruby and Ruby on Rails about five years ago. If you want to stick with what you have, then no worries. I just think people should be excited that over the last couple of years, the "golden hammer" approach to storing data has finally been overtaken and developers have a choice about what technology best solves their data problem.
br1 15y ago
In some RDBMSs, primary and secondary indexes are very different. MsSql clustered tables store the tuples themselves in the primary index B Tree. Traversing the data in the order of the primary index incurs no extra disk seeks. Also, you can add extra columns to secondary indexes to support queries without searching the primary index at all. The emulation of secondary indexes is inefficient. In a RDBMS without built in index maintenance you would create table (LeaderboardId, ScoreId), not (*LeaderboardId, ScoreIds). There's no need for comma separated fields.
Maro 15y ago
There are several different NoSQLs. For example, currently MongoDB is a good choice if you're looking for indices, ad-hoc queries and want to get up and running quickly on eg. a web project. Interestingly, with indices and ad-hoc queries, MongoDB becomes a lot like Mysql, only you're writing weird And() and Or() functions instead of "SELECT ... WHERE AND ... OR". Also, indices are tied to the documents themselves, so it's not clear how that scales. Shameless plug: Or you could go more bleeding-edge and check out ScalienDB, which is a straight key-value store built on Paxos and sharding. Nevertheless, getting started is easy: https://github.com/scalien/scaliendb/wiki I wrote ScalienDB. The plan going forward is to add a data model and distributed transactions and in general become a low level data layer substrate similar to how Google uses its databases.
noelwelsh 15y ago
My approach was to read the Dynamo paper. It's presents the goals of Dynamo and the technology from which it is constructed in a very compact form. From there you have a basis for understanding the engineering tradeoffs made by the other NoSQL databases. Then you can actually make decisions based on what fits your use case, rather than just choosing Mongo because it's popular. (Don't get me wrong, Mongo is great in its niche.) Reading the Google BigTable paper would also be a good idea, as it represents another major strand of work. My blog post on Dynamo: http://untyped.com/untyping/2011/01/21/all-about-amazons-dynamo/ http://untyped.com/untyping/2011/01/21/all-about-amazons-dyn...
timanglade 15y ago
It’s obvious the author means well — and thanks to him for plugging the NOSQL Tapes! — but there are some seriously leaky assumptions at work here about a) how Mongo, Redis (& RDBMSes) work and b) the extent to which this poorly-digested (or regurgitated) understanding applies to other NOSQL solutions. Too many shortcuts, inaccuracies, half-truths and implied errors to list here. The core idea of learning about NOSQL through first-hand experience (& dissection) of each project is sound, though.
figital 15y ago
SQL is (an expression of) relational algebra: http://en.wikipedia.org/wiki/Relational_algebra http://en.wikipedia.org/wiki/Relational_algebra. NoSQL is your (poorly named) ability to cache stuff (flat datasets) in assorted places.
JoshClose 15y ago
You don't hear as much about it, but RavenDB is an excellent No-SQL solution in MS land. It was written from the ground up with .NET instead of being ported. It's become my first choice ahead of MS-SQL Server for .NET projects. http://ravendb.net/ http://ravendb.net/
BenSS 15y ago
I've had a great experience with CouchDB as a NoSQL solution, simply because it is NOT like your traditional MySQL/Postgres. I'm not trying to map my existing knowledge to something that is fundamentally different. I think MongoDB might be a mistake in this regard, because users will attempting to deploy it similarly to a SQL solution.
akivabamberger 15y ago
The plural of index is indices, not indexes...

81 points by latch 15y ago

perfunctory 15y ago

How can one learn something that is defined by what it is not.

virmundi 15y ago
This thought is not mine, but I cannot recall the source: NoSQL is a bad name; it should be NotSQL. As a result it is a very large umbrella. When one sees NoSQL it is a safe assumption to think MongoDB. But you could also think DB4O (I like this much more, in an abstract way). So you can go about learning any of these technologies since you find an instance of NotSQL. To learn NoSQL, you are really still able to learn this. You are learning a philosophy rather than a technology.
- nickknw 15y ago
  I remember reading something by Erik Meijer where he states he also thinks it is an unfortunate name. I think he suggested coSQL, and gave an interesting perspective on the relationship between SQL and noSQL. This was the article: http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-model-of-data-for-large-shared-data-banks http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-...

rsbrown 15y ago

Very light reading, but all the same an excellent overview of MongoDB, Redis and Cassandra. Well done.

Cloven 15y ago

"Yesterday I tweeted three simple rules to learning NoSQL. Today I'd like to expand on that. The rules are: 1: Use Mon" CTRL-W

bretthoerner 15y ago
I originally skipped the article, and thought you were kidding... Alas...
latch 15y ago
What path would you suggest people take in learning something that challenges decades of best practices?
- knieveltech 15y ago
  1st, be damned sure that decades old best practices actually aren't the best tool for your current application, developer hype be damned.
  - latch 15y ago
    Hard to know whether they aren't the best tool for the job without at least familiarizing yourself with some alternatives.

yummyfajitas 15y ago

Step 1 in learning NoSQL: learn SQL very well. There is a good chance it already solves your problems AND ensures your data makes sense.

timanglade 15y ago
Step 2: convince yourself that you should only use NOSQL if you absolutely have to. (Corollary: if you ask for NOSQL by name, you most probably don’t need it.)
mtogo 15y ago
As a bonus, SQL cares about data reliability. Not that all of "NoSQL" doesn't, but two major "NoSQL" databases, Redis and MongoDB, both seem to care more about performance than durability.
- rbranson 15y ago
  MySQL cares about data reliability? Maybe if you spend much time agonizing over the configuration and set it to strict mode.
  - mtogo 15y ago
    I generally don't use MySQL, but iirc it confirms that nothing went wrong saving the data (whereas with mongo there is no confirmation step, you just have to hope that it was successful), and the data is written to disk. Additionally, i've heard of zero "Oh no, MySQL just lost 50% of my production database!" where it wasn't the user's fault, and i've heard enough of that from Mongo to stay away.
    - jasonmccay 15y ago
      Respectfully, this isn't true. Yes, fire and forget is the default behavior, but there is a confirmation step that you can check. It may be implemented a bit differently from driver to driver, but it is generally called a "safe insert". Numerous people use this to ensure their writes across single databases as well as multi-node master-slave and replica sets.

nkh 15y ago

From the article: A lot of NoSQL solutions are about solving specific problems. MongoDB is a general solution which can (and probably should) be used in 90% of the cases that you currently use an RDBMS. As I use don't use any NoSQL solutions today, can someone list out a few of these cases where I am using an RDBMS and I should be using MongoDB?

latch 15y ago
When you want to do many small real time operations against your data. The model fits well with most web sites (the unit of work for a given request tends to be quite small). Loggin also comes to mind as does some basic geospatial work. I think for most cases it does what a RDBMS can do but with less friction (you'll still use an ORM/ActiveRecord, but it'll be a much more lightweight). Why don't you check out mongly.com/tutorial/index and get a quick feel for it?
- nkh 15y ago
  That makes sense, but it is certainly not 90% of what I use an RDBMS for as the author stated. Especially if most of the things I do are not real time web. I will take a look at the link above, as I am curious about it. But I am still struggling for use cases. By the way, thank you for your comment. I up-voted it.
mtogo 15y ago
I'm wondering about this too. For almost everything i work on, the data being in the correct format, written to disk, and stored reliably is more important than the speed or other advantages of Mongo.
- jasonmccay 15y ago
  I have a hard time understanding responses like this and, in the end, they make me think that people a) really don't understand some of these new data technologies and b) are just as much on the anti-bandwagon as those that sit on the latter. For people using MongoDB daily, their data is in the correct format, it is persisted to disk, it is stored reliably and it is fast. On top of that, it gives them flexibility as their web app changes and new features and data structures are added, it is easily viewed and manipulated in JSON-format, and if and when the day comes that they need serious scaling, it helps there as well. Also, in the world of EC2, it is straight-forward to set up replica sets to offer redundancy. All these conversations sound eerily familiar to the Java guys bashing Ruby and Ruby on Rails about five years ago. If you want to stick with what you have, then no worries. I just think people should be excited that over the last couple of years, the "golden hammer" approach to storing data has finally been overtaken and developers have a choice about what technology best solves their data problem.

br1 15y ago

In some RDBMSs, primary and secondary indexes are very different. MsSql clustered tables store the tuples themselves in the primary index B Tree. Traversing the data in the order of the primary index incurs no extra disk seeks. Also, you can add extra columns to secondary indexes to support queries without searching the primary index at all. The emulation of secondary indexes is inefficient. In a RDBMS without built in index maintenance you would create table (LeaderboardId, ScoreId), not (*LeaderboardId, ScoreIds). There's no need for comma separated fields.

Maro 15y ago

There are several different NoSQLs. For example, currently MongoDB is a good choice if you're looking for indices, ad-hoc queries and want to get up and running quickly on eg. a web project. Interestingly, with indices and ad-hoc queries, MongoDB becomes a lot like Mysql, only you're writing weird And() and Or() functions instead of "SELECT ... WHERE AND ... OR". Also, indices are tied to the documents themselves, so it's not clear how that scales. Shameless plug: Or you could go more bleeding-edge and check out ScalienDB, which is a straight key-value store built on Paxos and sharding. Nevertheless, getting started is easy: https://github.com/scalien/scaliendb/wiki I wrote ScalienDB. The plan going forward is to add a data model and distributed transactions and in general become a low level data layer substrate similar to how Google uses its databases.

noelwelsh 15y ago

My approach was to read the Dynamo paper. It's presents the goals of Dynamo and the technology from which it is constructed in a very compact form. From there you have a basis for understanding the engineering tradeoffs made by the other NoSQL databases. Then you can actually make decisions based on what fits your use case, rather than just choosing Mongo because it's popular. (Don't get me wrong, Mongo is great in its niche.) Reading the Google BigTable paper would also be a good idea, as it represents another major strand of work. My blog post on Dynamo: http://untyped.com/untyping/2011/01/21/all-about-amazons-dynamo/ http://untyped.com/untyping/2011/01/21/all-about-amazons-dyn...

timanglade 15y ago

It’s obvious the author means well — and thanks to him for plugging the NOSQL Tapes! — but there are some seriously leaky assumptions at work here about a) how Mongo, Redis (& RDBMSes) work and b) the extent to which this poorly-digested (or regurgitated) understanding applies to other NOSQL solutions. Too many shortcuts, inaccuracies, half-truths and implied errors to list here. The core idea of learning about NOSQL through first-hand experience (& dissection) of each project is sound, though.

figital 15y ago

SQL is (an expression of) relational algebra: http://en.wikipedia.org/wiki/Relational_algebra http://en.wikipedia.org/wiki/Relational_algebra. NoSQL is your (poorly named) ability to cache stuff (flat datasets) in assorted places.

JoshClose 15y ago

You don't hear as much about it, but RavenDB is an excellent No-SQL solution in MS land. It was written from the ground up with .NET instead of being ported. It's become my first choice ahead of MS-SQL Server for .NET projects. http://ravendb.net/ http://ravendb.net/

BenSS 15y ago

I've had a great experience with CouchDB as a NoSQL solution, simply because it is NOT like your traditional MySQL/Postgres. I'm not trying to map my existing knowledge to something that is fundamentally different. I think MongoDB might be a mistake in this regard, because users will attempting to deploy it similarly to a SQL solution.

akivabamberger 15y ago

The plural of index is indices, not indexes...