Object Prevalence: Get Rid of Your Database?

A reader writes:" Persistence for object-oriented systems is an incredibly cumbersome task to deal with when building many kinds of applications: mapping objects to tables, XML, flat files or use some other non-OO way to represent data destroys encapsulation completely, and is generally slow, both at development and at runtime. The Object Prevalence concept, developed by the Prevayler team, and implemented in Java, C#, Smalltalk, Python, Perl, PHP, Ruby and Delphi, can be a great a solution to this mess. The concept is pretty simple: keep all the objects in RAM and serialize the commands that change those objects, optionally saving the whole system to disk every now and then (late at night, for example). This architecture results in query speeds that many people won't believe until they see for themselves: some benchmarks point out that it's 9000 times faster than a fully-cached-in-RAM Oracle database, for example. Good thing is: they can see it for themselves. Here's an article about it, in case you want to learn more."

Slashdotted

[Cubeman]

For a scalability test, it sure fails the Slashdotting Test.

It's about 9000 times slower right now :)

Re:Sure :P

[muyuubyou]

"10 gigs should be enough for anybody" ~Billy G

Re:gigabytes?

[AKnightCowboy]

Who uses a database small enough to fit in RAM?

The Museum of 20th Century French Military Victories in Paris could make use of this technology on my old 8086 system.

C++ soluton

[debrain]

I noticed the lack of C++ support, so I thought I'd throw my hat in. :)

template<typename O,typename T>
O&
operator <<(O&o,T&t) {
o.write(t,sizeof(T));
}

How to improve performance 9000 times

[eet23]

Make your database system boring enough that it is not linked to on Slashdot.

Re:Slashdotted

[Anonymous Coward]

Aaaah, the new TPM-/. benchmark for web server transactions...

Blazing fast

[Zayin]

This architecture results in query speeds that many people won't believe until they see for themselves: some benchmarks point out that it's 9000 times faster than a fully-cached-in-RAM Oracle database, for example. Good thing is: they can see it for themselves.

Yes, I've seen it. The page on www.prevayler.org only took about 30 seconds to load. Does that mean that a fully-cached-in-RAM Oracle database would spend 75 hours loading that page...?

Re:RAM ?

[Anonymous Coward]

You payed $59 CAD - you got ripped.
256 MB DDR RAM is $45 CAD now.
For everyone else in the world, that around $5 USD.

Re:gigabytes?

[Daniel Dvorkin]

Ever heard of a little dust-up called World War One, dumbass?

Re:gigabytes?

[Anonymous Coward]

Here's a quick history lesson for the morons here (yeah, that's you Daniel Dvorkin):

Gallic Wars: The French not only lost ... they lost to an Italian.

Hundred Years' War: Although they kinda/sorta mostly lost, they were saved by Joan of Arc (a female schizophrenic), who by accident created the First Rule of French Warfare: "France's armies are victorious only when not led by a Frenchman."

Italian Wars: France became the first and only country in history to lose not just one but TWO wars against Italians.

Wars of Religion: France was 0-5-4 against the Huguenots.

Thirty Years' War: Although not technically a principal, they did manage to get invaded anyway. Amusingly, they claim a tie on the basis that eventually the other participants started ignoring them.

War of Devolution: Tied.

Dutch War: Tied.

War of the Augsburg League: Lost, claimed tie.

King William's War: Lost, claimed tie.

French and Indian War: Lost, claimed tie.

Three ties in a row caused some deluded folks to label the period as the height of French military power.

War of the Spanish Succession: Lost.

American In a Scribean foreshadow of the future, France claims a win even though the English colonists saw way more action.

This is eventually known as "de Gaulle Syndrome."

It also establishes the Second Rule of French Warfare: "France only wins when America does most of the fighting."

French Revolution: Won, primarily due the fact that the opponent was also French.

Napoleonic Wars: Lost.

Franco-Prussian War: Lost.

World War I: Tied and on the way to losing. France was saved by the United States.

World War II: Lost. Conquered French liberated by the United States and Britain.

War in Indochina: Lost.

Algerian Rebellion: Lost. The first defeat of a Western army by a Non-Turkic Muslim force since the Crusades. It gave birth to the First Rule of Muslim Warfare: "We can always beat the French." This rule is identical to the First Rules of Italian, Russian, German, English, Dutch, Spanish, Vietnamese and Esquimaux Warfare.

War on Terrorism: France has surrendered to Germans and Muslims just to be safe.

So France's only military victory was against... the French. How quaint.

Re:The Electric Database ACID Test

[Anonymous Coward]

Things I want in a persistent datastore:
- Atomicity of transactions RAMed up your ass
- Consistency in the enforcement of my data being RAMed up your ass
- Isolation of each transaction from other competing transactions being RAMed up your ass
- Durable storage that can survive being RAMed up your ass

My experience with RAM-centeric disk-backed object storage being RAMed up your ass is that you, the developer, often have to implement the ACID features RAMed up your ass yourself, from scratch. And from-scratch implementations of complex data-integrity mechanisms tend to be RAMed up your ass and time-consuming to develop and test and often take much, much longer than you think to get RAMed up your ass

Call me old-fashioned, but I really like using data storage (database) engines that are RAMed up your ass and pass the ACID test and have already been debugged and debugged and debugged and debugged and debugged and RAMed up your ass.

-Mark RAMed up your ass

WOW! After twenty years...

[Master of Transhuman]

somebody has figured out that things in memory are faster than disk...

After twenty years, we finally get to...

the in-memory database!

Oh wait, didn't my Atari ST have that?

Re:OODB are very different from RDBMS

[Samrobb]

The 2 main problems with OODB, are:
- schema evolution
- reporting
But these can easily be solved by a good design of your application.

In other words, OODB technology is doomed.

Re:RAM ?

[kcelery]

not to forget power failure, earth quake, fire, burglar, sysadmin has a stroke, air cond failure, water main bursted, building hit by a big flying object etc....................

apparently not fast enough...

[grimani]

the slashdot effect still takes it down...

Re:One word ...er..acronym:

[Anonymous Coward]

What if the little purple elf people from the planet Ubblewappy sneak in late at night and molecularly transmute all your RAM into marshmallows? What if pigs had wings? What if frogs could do predicate calculus? What if the Earth were trapezoidal?

What if you JUST MADE BACKUPS??!?!!?!?!

Man, anything for a 40-message thread...

Re:RAM ?

[Anonymous Coward]

Unfortunately, Comp Sci cirriculums are heavy on OOP concepts but pathetically light on database theory, which is why you wind up with otherwise talented programmers who don't understand the basic fundamentals of designing solid client-server applications.

Thank you for helping me to dismiss completely the pointy headed OOP Snobs and Relational Bigots. I've had the nagging feeling for years that maybe these people using terms I didn't understand really did know something I didn't, even though I couldn't see what I was missing.

Comp Sci cirriculums are not heavy on anything. As a matter of fact, if they are heavy on anything, it is, data structures, algorithms, and working-with-pointers. And we all know that this just isn't so. So now, whenever I hear some DBA talking about normalizing his tuple or a Systems Architect implementing a pure abstract factory facade, I can tell them to stick it in their boring book that I thought I was too dumb to get all the way through, and burn it.