You may have seen my posting regarding "eventual consistency" some
months ago, and you may have come to the conclusion that I was
insisting that a SQL based RDBMS is the way to go for just about
anything. Tell you what, that is not so. And nether am I against
using. say, MongoDB, where it is appropriate.
The whole deal with Eventual consistency is something that I am
still opposed to, I want to know if my data is consistent. And I
am not not sure that you cannot have a fully consistent,
distributed system either. But I guess that debate goes on. And I
still want my base data to be consistent. Like in
RDBMS-SQL-Foreign-keys-all-over-the-place-and-not-a-bl**dy-bit-lost-in-the-MyISAM-swamp
consistent. That is what I want the base data to look like. And
if there are compromises …
Clients often ask what the differences are between the various InnoDB isolation levels, or what ACID means. Here are some simple explanations for those that have not yet read the manual and committed it to memory.
READ UNCOMMITTED
Every select operates without locks so you don’t get consistency
and might have dirt reads, which are potentially earlier versions
of data. So, no ACID support here.
READ COMMITTED
Has consistent reads without locks. Each consistent read, even
within the same transaction, sets and reads its own fresh
snapshot.
REPEATABLE READ
The InnoDB default isolation level for ACID compliance. All reads
within the same transaction will be consistent between each other
– ie, the C in ACID. All writes will be durable, etc etc.
SERIALIZABLE
Same as REPEATABLE READ but MySQL converts regular select …
The No-SQL tag really lumps together a lot of concepts that are in fact as distinct from eachother as they are from SQL/RDBMS.
An object store is not at all similar to Cassandra and Hypertable, which is not at all like an column store. And when looking at BigTable derivatives, it’s quite important to realise that Google actually does joins in middle layers or apps, so while BigTable does not have joins, the apps essentially do use them – I’ve heard it professed that denormalising everything might be a fab idea, but I don’t quite believe in that for all cases, just like I don’t believe in ditching the structured form of RDBMS being the solution.
SQL/RDBMS has had a few decades of dominance now, and has thus become the great “general purpose” tool. With the ascent of all the other tools, it’s definitely worthwhile to look at them, but also realise that each (inluding SQL based ones) have their place. Moving all your …
[Read more]
Shared-disk databases can be virtualized—making them
cloud-friendly—while shared-nothing databases are tied to a
specific computer and a specific data set or data
partition.
The underlying principle of the shared-nothing RDBMS is that a
single master server owns its specific set of data. That data is
not shared, hence the name shared-nothing. Because there is no
ability to share the data, there is also no ability to virtualize
the computing of that data. Instead the shared-nothing RDBMS ties
the data and the computing to a specific computer. This
association with a physical machine is then reinforced at the
application level. Applications leveraging a shared-nothing
database, that is partitioned across more than one server, use
routing code. Routing code simply directs the various database
requests to the servers that own the data being requested. In
other words, the application must know which server owns which
piece of data. …