 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I must admit I have to giggle and shake my head at how many people doing
work on new database technologies try really hard to make it sound like
old database technologies only better.
Everyone is ACID, even if you have to interpret the "C" in ACID as
meaning "we don't corrupt the file system if we crash", even tho that's
implied by the A and D.
The Erlang database is an "enhanced relational model", even tho it's not
relational in any sense. You can have denormalized records,
variable-sized objects of varying types in each column, and multiple
records with the same primary key in the same table. You also don't have
any, you know, relationships(*). As in, there's no join operator. If you
want to know what departments the employee is in, you either put a list
of departments in the employee record, or manually maintain a second
table relating employees to departments.
It just cracks me up that nobody is willing to say "Yes, we don't have
ACID, and that's a *good* thing sometimes."
(*) Yes, I know "relation" doesn't mean "join", thanks.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> I must admit I have to giggle and shake my head at how many people doing
> work on new database technologies try really hard to make it sound like
> old database technologies only better.
Maybe because - you know - the old database technologies are already
well-understood?
Have you notied how Intel keep designing these new-fangled
super-mega-huper chips... and making them binary-compatible with an
ancient non-RISC design from, what, 20 years ago? I mean, a modem Intel
Core 2 Duo or something is performing all this out-of-order execution,
yet it still goes to extreme lengths to enumate a completely sequential
machine with no pipelining.
It would be a damned site *simpler* for it to not try to do all this
emulation. In fact, it would be a lot more *efficient* too. But where's
the market in that?
> It just cracks me up that nobody is willing to say "Yes, we don't have
> ACID, and that's a *good* thing sometimes."
Yes, because everybody loves having the ability to make things
unreliable and unpredictable...?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Darren New wrote:
>> I must admit I have to giggle and shake my head at how many people
>> doing work on new database technologies try really hard to make it
>> sound like old database technologies only better.
>
> Maybe because - you know - the old database technologies are already
> well-understood?
I think it's more that they're already well-approved. :-) A new swoopy
database that could store and search terabytes in parallel on disks in
cities all over the world is going to fall down the first time the DBA
says "Yes, but is it ACID?"
Much the same way that so many machines in the mid-80's failed to sell
because people asked "Is it IBM compatible?"
> Have you notied how Intel keep designing these new-fangled
> super-mega-huper chips... and making them binary-compatible with an
> ancient non-RISC design from, what, 20 years ago? I mean, a modem Intel
> Core 2 Duo or something is performing all this out-of-order execution,
> yet it still goes to extreme lengths to enumate a completely sequential
> machine with no pipelining.
Yep. Except there, it actually has practical implications. Lots of
people have binary Intel software they need to run. If you're moving to
a non-relational database, enforcing the ACID properties aren't
necessarily an important thing.
For example, is it actually important that every search on the same
keywords on Google invariable return the same result? Is it OK to update
the UK indecies an hour later than the US indecies when new web pages
show up?
Clearly, this isn't appropriate for (say) a bank's ATM network. But
there are lots of applications where nothing bad happens if there's
temporary inconsistency.
> It would be a damned site *simpler* for it to not try to do all this
> emulation. In fact, it would be a lot more *efficient* too. But where's
> the market in that?
Yeah. Some of the chips were actually RISC chips basically interpreting
x86 machine code, is my undertanding.
>> It just cracks me up that nobody is willing to say "Yes, we don't have
>> ACID, and that's a *good* thing sometimes."
>
> Yes, because everybody loves having the ability to make things
> unreliable and unpredictable...?
It's not "unreliable and unpredictable". It's just that the consistency
isn't enforced by the database system.
The "C" in ACID is really important when you have multiple tables
talking about one entity (which is what the "C" actually means). But
when you're entire customer, all his orders and configuration and
history, are all in one record, enforcing the "C" is much less
important, because the "A" takes care of it as long as your application
isn't borked.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] dev null> wrote in message
news:4853ee39$1@news.povray.org...
> > It just cracks me up that nobody is willing to say "Yes, we don't have
> > ACID, and that's a *good* thing sometimes."
>
> Yes, because everybody loves having the ability to make things
> unreliable and unpredictable...?
>
Not implementing parts of ACID doesn't make something random. There are
times and places where having all of the ACID properties is essential and
there are times when they're not necessary.
I'd be willing to bet more than half of the people who go on about whether
something is ACID don't fully understand what those 4 properties mean.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail Shaw wrote:
> I'd be willing to bet more than half of the people who go on about whether
> something is ACID don't fully understand what those 4 properties mean.
Including the people coding CouchDB, who claim it's ACID. They either
don't know what that means, or they're lying. :-) Frightening either way.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Maybe because - you know - the old database technologies are already
>> well-understood?
>
> I think it's more that they're already well-approved. :-)
Isn't that why nobody uses functional programming? Because it's not yet
well-approved?
> Yep. Except there, it actually has practical implications. Lots of
> people have binary Intel software they need to run. If you're moving to
> a non-relational database, enforcing the ACID properties aren't
> necessarily an important thing.
>
> For example, is it actually important that every search on the same
> keywords on Google invariable return the same result? Is it OK to update
> the UK indecies an hour later than the US indecies when new web pages
> show up?
On the other hand, if Google's entire database vanished... would they
care? I mean, in a day or two they can re-index all the pages and
they'll have their data back. They won't have all the old cached data,
but it's not exactly catastrophic.
Seems to me Google doesn't need a "database" at all... they just need a
reasonably reliably large-scale storage system that supports very fast
indexing.
> Clearly, this isn't appropriate for (say) a bank's ATM network. But
> there are lots of applications where nothing bad happens if there's
> temporary inconsistency.
...which is why there's all those different isolation levels and stuff.
>> It would be a damned site *simpler* for it to not try to do all this
>> emulation. In fact, it would be a lot more *efficient* too. But
>> where's the market in that?
>
> Yeah. Some of the chips were actually RISC chips basically interpreting
> x86 machine code, is my undertanding.
My understanding is that current mainstream CPUs are some weird
RISC/CISC hybrid that's so complicated that it's difficult to know
*what* to call it! o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Seems to me Google doesn't need a "database" at all... they just need a
> reasonably reliably large-scale storage system that supports very fast
> indexing.
Well, except for two things:
1) That *is* what a database is.
2) Google's job isn't to give you search results. Google's job is to
populate web pages with advertisements.
>> Clearly, this isn't appropriate for (say) a bank's ATM network. But
>> there are lots of applications where nothing bad happens if there's
>> temporary inconsistency.
>
> ....which is why there's all those different isolation levels and stuff.
But that's what the "I" is about.
> My understanding is that current mainstream CPUs are some weird
> RISC/CISC hybrid that's so complicated that it's difficult to know
> *what* to call it! o_O
I'm pretty sure the ARM machines are a lot simpler. Desktop CPUs, yeah.
But ARMs outnumber desktop machines several to one, IIUC.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On the other hand, if Google's entire database vanished... would they
> care? I mean, in a day or two they can re-index all the pages and
> they'll have their data back. They won't have all the old cached data,
> but it's not exactly catastrophic.
They'd care. They'd loose all the accumulated search history of everyone who
uses google (or at least the aggregated values), all their advertisement
records, all their page ranks (could be recalculated, but...)
There's a lot, lot more to google than just a large store of web pages and a
fast index. Have you looked at their webmaster tools?
I can get from google a history of searches that returned my site.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
