Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Now that people are considering NOSQL will more people consider no-DB

martinfowler.com

Post reply on HN
Print view View original

131–140 of 147 posts

Re: Now that people are considering NOSQL will more people consider no-DB

#131

Post by zzzeek »

zwischenzug wrote: post #96

Perhaps I am an old dinosaur, but this article merely annoyed me. "The key element to a memory image is using event sourcing, which essentially means that every change to the application's state is captured in an event which is logged into a persistent store." That is a key element of a database. It's called a logical log. "Furthermore it means that you can rebuild the full application state by replaying these events…

These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation to relational concepts needed (note I am the author of a very popular object-relational library, so I'm not in any way opposed to object-relational mapping...it's just interesting to see this approach that requires none). That it's stored in memory and is reconstructed against an event log are secondary to this.

Re: Now that people are considering NOSQL will more people consider no-DB

#132

Post by freakinjoe »

wpietri wrote: post #93
jeffdavis wrote: post #86

Earlier quoted context omitted.

"All cores can read simultaneously." Unless someone is writing, of course, in which case you have to worry about isolation. So a single writer would block all readers, right? "You mean a bug in our code that causes a problem?" No, I mean like "I already wrote some data, but now a constraint has been violated so I need to undo it".

> So a single writer would block all readers, right? Correct. For the fraction of a millisecond the transaction is executing, anyhow. Since transactions only deal with data hot in RAM, transactions are very fast. > No, I mean like "I already wrote some data, but now a constraint has been violated so I need to undo it". That shouldn't happen, and I've used two approaches to make sure. One is do all your checking befor…

each transaction logged before accepted in RAM, disk is involved here. i never trust batch log commit since, each transaction might affect other operations as well in large applications.

Re: Now that people are considering NOSQL will more people consider no-DB

#133

Post by darylteo »

jeffdavis wrote: post #77

What about ROLLBACK? And no, going back in time by replaying logs is no substitute, because you lose other transactions that you want to keep (and perhaps already reported to the user as completed). What about transaction isolation? How do you keep one transaction from seeing partial results from a concurrent transaction? Sounds like a recipe for a lot of subtle bugs. And all of the assumptions you need to make for t…

My understanding of Rollback in Event Sourcing is that there IS no rollback.

If an event causes the model to be in an invalid state, another event must be triggered to rectify the model into a valid state. (Simplistically speaking)

Re: Now that people are considering NOSQL will more people consider no-DB

#134

Post by ynd »

kragen wrote: post #128
ynd wrote: post #115

Earlier quoted context omitted.

When you say old-school DB do you mean something like mysql?

Yes, MySQL is the kind of database that canonically uses approaches like physical logs and logical logs to provide ACID transactions (and, in MySQL in particular, replication.) The interesting thing that Prevayler and such things did was that they expanded the use of logical logs beyond simple relational tables to much richer sets of state.

Well I guess one difference between what he's proposing and mysql is that mysql forces you to write data abstractions that can fit into mysql. Same goes for NoSQL DBs. Using his approach you don't have to worry about that.

Not sure that justifies dumping DBs altogether, but it's still an interesting advantage.

Re: Now that people are considering NOSQL will more people consider no-DB

#135

Post by zwischenzug »

zzzeek wrote: post #131
zwischenzug wrote: post #96

Perhaps I am an old dinosaur, but this article merely annoyed me. "The key element to a memory image is using event sourcing, which essentially means that every change to the application's state is captured in an event which is logged into a persistent store." That is a key element of a database. It's called a logical log. "Furthermore it means that you can rebuild the full application state by replaying these events…

These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation to relational concepts needed (note I am the author of a very popular object-relational library, so I'm not in any way opposed to object-relational mapping...it's just interesting to see this approach that requires none). That it's stored in memory and is reco…

Well, that put it much better than the article did.

Since the points I've highlighted argue that he's talking about database features I'd call that a database without impedance mismatch, like erlang's Mnesia.

Re: Now that people are considering NOSQL will more people consider no-DB

#136

Post by fauigerzigerk »

zzzeek wrote: post #131
zwischenzug wrote: post #96

Perhaps I am an old dinosaur, but this article merely annoyed me. "The key element to a memory image is using event sourcing, which essentially means that every change to the application's state is captured in an event which is logged into a persistent store." That is a key element of a database. It's called a logical log. "Furthermore it means that you can rebuild the full application state by replaying these events…

These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation to relational concepts needed (note I am the author of a very popular object-relational library, so I'm not in any way opposed to object-relational mapping...it's just interesting to see this approach that requires none). That it's stored in memory and is reco…

Initially he makes it sound like there is no translation into a different model but at the end of the article he takes it all back and for good reason:

Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which makes it difficult to migrate the model and still process old events.

So, you're right that he doesn't envision a translation to a relational model but it's not just object structures either.

Re: Now that people are considering NOSQL will more people consider no-DB

#137

Post by badmonkey0001 »

eeperson wrote: post #62
moheeb wrote: post #57

Earlier quoted context omitted.

Ever hear of ANSI SQL?

Which is not turing complete. You need database specific extensions to get that. Edit: Also, not all databases follow the standard very closely

What have you needed out of ANSI SQL that is a gap in its Turing Completeness? Totally serious. A great many things can be dismissed as not being Turing Complete, so please provide us with some examples of why this is bad in ANSI SQL.

Re: Now that people are considering NOSQL will more people consider no-DB

#138

Post by Mordor »

kragen wrote: post #88
Mordor wrote: post #40

Why not go for NoDisk solution too - just RAID your memory and back it up with ultracapacitors?

You don't even need the capacitors or battery backup if your memory is sufficiently distributed.

Hmm, not so sure about that - power outages can affect several city blocks and then you're introducing latency?

Re: Now that people are considering NOSQL will more people consider no-DB

#139

Post by vetler »

kahawe wrote: post #33
arethuza wrote: post #11

Earlier quoted context omitted.

You mean using data stores that support access through LDAP as general purpose databases?

Under certain circumstances using LDAP as a directory or data-store and not just for authentication alone can make sense, especially if you want to benefit from the very well standardized, open and stable interface or if some sort of multi-master scenario is needed or if you want very rigid control over who can see what portion of the data then the most popular LDAP servers offer a lot of very cool ways of "modelling…

I worked with LDAP servers for a few years, but never liked it much. Perhaps I missed something. What can you do in huge directories that is so amazing?

Re: Now that people are considering NOSQL will more people consider no-DB

#140

Post by eeperson »

badmonkey0001 wrote: post #137
eeperson wrote: post #62

Earlier quoted context omitted.

Which is not turing complete. You need database specific extensions to get that. Edit: Also, not all databases follow the standard very closely

What have you needed out of ANSI SQL that is a gap in its Turing Completeness? Totally serious. A great many things can be dismissed as not being Turing Complete, so please provide us with some examples of why this is bad in ANSI SQL.

I did not mean that ANSI SQL was bad. However, by not being turning complete it has fundamental limitations that limit it from expressing certain logic (as you might need to do in a stored procedure). This frequently means that you must use proprietary extensions to SQL (such as PL/SQL) to accomplish these tasks.

My interpretation of the parent post was that it was a response to a comment about vendor lock in. I was only trying to point out that it is not always possible to ensure compatibility between databases by writing strict ANSI SQL.

Post reply on HN