You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Django nonrel (noSQL) (app engine)

June 28, 2013 — JaZahn

I’ve been working with this for the last couple weeks. I have been doing this for a couple reasons.
1) I wanted to play with noSQL
2) I’m developing and deploying with the google app engine — the app engine does have a mySQL option (Cloud SQL), but they have no free version of this — so to do a GAE app (entirely (including data) in GAE), you have to use the google data store or pay for SQL.

Now doing the design in a key-value noSQL wasn’t too bad. I just had a design that had each object containing the ids of the other objects that were associated with it both ways. This was somewhat redundant she thinking about it in a relational way, but it made queries simple and fast. The overhead is making sure the software keeps the ids updated in all related objects I.e. if something is deleted.

That wasn’t so bad. It was a fun to design things differently than I’m used to. Then I fleshed out the models in django.

The issue I ran into was django-nonrel. This is the project that converts django to be able to deal with non relational DBs. This changes core django abstraction models and consists of apps that can be installed locally or globally. So I installed them locally because I don’t like the idea of altering the framework globally.

It did not work with the latest version of django.

So I read through the docs a little more carefully to discover the core team quit this project over a year ago. Because noSQL wasn’t right for their projects and Cloud SQL was now available for app engine. The guy who took it over isn’t keeping it up to date with django. He’s about a year behind. It’s working with django 1.3. Current version right now is 1.5.1. That is enough to throw errors.

If django is making changes in point releases that cause the django-nonrel to become out of date, either django isn’t doing a good job at maintaining backwards compatability or (much more likely) django-nonrel project isn’t doing a good job keeping away from hacky implementations that rely on very specific django references.

I don’t have the time to debug django-nonrel. It’s like 4 apps that go in your django project.

Additionally I worked out what the cost of Cloud SQL would be for development and I can deal with less than $2 a month. When it goes production I can worry about dealing with my teams extremely poor mysql management or get my group to pay for a more substantial Cloud SQL instance.

Posted in ATG, Flashcards. Tags: , , , , , , , . Comments Off on Django nonrel (noSQL) (app engine) »

noSQL vs Relational DB

June 26, 2013 — JaZahn

There are a billion articles on this, but having read half of them, I’d like to vomit what I’ve taken away as important from them.

Relational databases are integral to any software developer. We’ve been working with them since day 1 of our career. Now comes mongoDB and the appengine Datastore, and there is a ton of hype behind it. But what are the actual benefits?

The big thing you lose with noSQL is joins. If you’re not doing joins noSQL will probably outperform a relational db. So if you don’t need reporting, if there’s no complexity needed for the data, noSQL is actually a fine solution. That’s not to say you can’t do joins. They’re just different and much slower to perform. So you end up with a bunch of data redundancy, which makes changes to that redundant data much more difficult, but eh, if that data barely ever changes, it ain’t no thang.

Another thing you lose that are the constraints on data, foreign keys, data type constraints. All of that has to be handled in the application layer. Which it should be anyway, but having a second line of defense for validation is nice. We all tend to think in terms of objects. Set objects with clear constraints, so having things set from the get go is understandable. The gain of data amorphism, I haven’t really been able to imagine a real world situation where that’s an actual plus.. which could be due to lack of imagination because that’s what I’ve done forever.

The big thing you gain with noSQL is ‘elastic scaling’. When a relational db starts to get huge, the db gets bigger. The single server that’s running the db has to be bigger and badder, and all replication has to be just as big. With noSQL, you can break up the data between servers. This is especially useful in the cloud, and when trying to cut costs in general. 5 small-medium servers can be dirt cheap compared to 1 huge server.

Posted in Databases, Design & Modeling. Tags: , , , , , . 1 Comment »
«
»