How You Should Go About Learning NoSQL

http://openmymind.net/2011/8/15/How-You-Should-Go-About-Learning-NoSQL

by latch • 15 years ago

81 46 15 years ago

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

virmundi• 15 years 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• 15 years 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-...

rsbrown• 15 years ago

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

Cloven• 15 years 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• 15 years ago

I originally skipped the article, and thought you were kidding... Alas...

latch3• 15 years ago

What path would you suggest people take in learning something that challenges decades of best practices?

knieveltech• 15 years ago

1st, be damned sure that decades old best practices actually aren't the best tool for your current application, developer hype be damned.

yummyfajitas• 15 years 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.

mtogo5• 15 years 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.

rbranson2• 15 years ago

MySQL cares about data reliability? Maybe if you spend much time agonizing over the configuration and set it to strict mode.

nknight• 15 years ago

It's pretty easy to make Redis basically ACIDic (use MULTI/EXEC and WATCH with AOF on and fsync on every command) if you really need to.

In practice you probably don't. Financial transactions should take another path, but for almost everything else, you can probably afford the few seconds of data loss you may encounter.

jasonmccay5• 15 years ago

Would you mind elaborating on why MongoDB cares about speed over reliability. Sure, you can go that route (and sometimes that is what developers want to do), but MongoDB, as a database, reliably stores and persists your data.

Just curious what your experiences were that made you think MongoDB isn't a reliable data store.

njharman• 15 years ago

I really absolutely do not understand "verses" mentality and that if everything must support same feature set or it's "bad".

You shouldn't choosing SQL over noSQL, you choose both (or none, or other stuff as your problem requires) and use them in appropriate places in your infrastructure. Sometimes you want performance over durability.

rbranson2• 15 years ago

Not just that, but getting a deep understanding of how the RDBMS (or NoSQL solutions, for that matter) implements the database is important as well is very important. It requires a low level understanding of how the implementations write things to disk, perform indexing, structure data in memory, and their characteristics when distributed to make truly informed, non-cargo-cult decisions about database technologies. Otherwise you're just shooting in the dark.

nkh2• 15 years 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?

latch3• 15 years 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?

nkh2• 15 years 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.

mtogo5• 15 years 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.

jasonmccay5• 15 years 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.

gaius• 15 years ago

Because it's "web scale".

br1• 15 years 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• 15 years 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• 15 years 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-dyn...

figital• 15 years ago

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

JoshClose• 15 years 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/

BenSS• 15 years 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• 15 years ago

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

How You Should Go About Learning NoSQL

Related Stories