NoSQL – Schemaless Data-stores Not Only for the Cloud – Thomas Schank
Thomas gave an overview of some NoSQL databases and the theoretical background of it.
The main points are: SQL databases get inefficient as the data grows and if you need to split the data between instances (how do you join tables between two DB servers? Even if you can, performance is going to suffer).
But there are new problems: Data can be inconsistent for a while (keyword: MVCC).
OTOH, these databases don’t need locks and, as Amazon demonstrated, any kind of lock will eventually become a bottleneck:
Each node in a system should be able to make decisions purely based on local state. If you need to do something under high load with failures occurring and you need to reach agreement, you’re lost. If you’re concerned about scalability, any algorithm that forces you to run agreement will eventually become your bottleneck. Take that as a given.
Werner Vogels, Amazon CTO and Vice President
And since the servers can heal inconsistencies, broken connections don’t mean the end of the world. The acronym of the hour is BASE: Basically Available, Soft-state, Eventually consistent.
Interesting stuff, especially since every company owns a super-computer today. My own team has one with 64 cores, 64GB of RAM and 16TB of disk space sitting in 8 boxes spread under the desks of the developers. Not much but it only costs $8 000. And if we need more, we can simply buy another node. Unfortunately, it’s hard to leverage this power. I’ll come back to that in a later post.
One thing to take with you: If you can’t stand JavaScript but you need to write it, have a look at CoffeeScript.
Links:
- Slides
- “Why NoSQL is bad for startups” (not completely serious, of course)
Posted by digulla
Jazoon 2011, Day 2 – Java Concurrent Animated – Victor Grazi
26. June, 2011Java Concurrent Animated – Victor Grazi
One picture says more than a thousand words. Now imagine what an animation can say. Victor did several for us to better understand the classes in java.util.concurrent. You can find the software on sourceforge: javaconcurrenta
Here is an example:
Very nice. I know a lot about threads and concurrency (the Amiga had preemptive multitasking back in 1986) but even I was surprised by the ReentrantReadWriteLock example: If you have a writer waiting for the lock and another reader comes along, should it get the lock immediately or should it wait for the writer to complete?
My first instinct was to get all the (quick) readers out of the way but chances are that, when all readers have been processed, another one might have come along, effectively starving the writer.
Links:
Share this: