Slashdot Mirror
Prevayler Quietly Reaches 2.0 Alpha, Bye RDBMS?
"We've used relational databases for years despite incompatibilities in SQL implementation. Accessing them from an OOP paradigm has been so tedious, that Object-Relational mapping technologies have sprouted all over the Open Source landscape. Some competing examples and models are Hibernate, OJB, TJDO, XORM, and Castor; which in turn have supporting frameworks such as Spring and SQLExecutor. Because SQL is the dominant form of interfacing with the data in an RDBMS, there's now a specification to offer it a friendlier OO face.
Most of the above, including the SQL-variants, arguably appear to add yet another layer of complexity (even if only at the integration level) where they should be taking complexity away. These solutions are put together by some very smart people, but it's inescapable to get that feeling someone is missing the forest (simple answer) because all the trees (incompatible models) are in the way. If there are so many after-the-fact solutions attempting to simplify relational database access and manipulation from OO, isn't it reasonable to think that there is something generally wrong with trying to cobble-together two disparate concepts with what are essentially high-caliber hacks? Is Prevayler a better way?"
Although MySQL is about 2.8 times faster for transaction processing, Prevayler retrieves 100 objects among one million 3251 TIMES FASTER than MySQL via JDBC, even when MySQL has all data cached in RAM!
Now many different people will interpret this statement differently. But, my interpretation is that under very specific circumstances it is 3000 times faster than MySQL. However, for transaction processing, which is the primary and most common role of a RDBMS, MySQL is 2.8 times faster than Prevayler.
Bottom line... For normal circumstances, MySQL is faster and many commercial SQL database servers are faster still.
Hell no! Are you stupid?
I might be.. we use an in-memory Java objectbase solution for Ganymede.. when coupled with an on-disk transaction log, we get extremely high performance, transactional integrity, and the ability to run wherever there's a Java VM.
While I wouldn't claim that this kind of solution will scale indefinitely, it works very well indeed for our application and our dataset size.
It's not Prevayler, though, so I can't comment on his API or code quality.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Their jingoism is absurd.
"We have some features that are better than relational databases. RELATIONAL DATABASES SHOULD NEVER BE USED AGAIN."
In their wiki, "When Should I Not Use Prevalence" lists three things:
When you do not know how to program.
When you cannot afford enough RAM to contain all your Business Objects.
When you cannot find a Java Virtual Machine that is robust enough.
That's obviously the stupidest thing ever. How about, "When I don't have the time and money to connect all my company's SQL DB stuff to your java stuff." Obviously my scenario encompasses a whole lot more users than their three, and perhaps explains why no one is using their product.
What assholes.
There are no trails. There are no trees out here.
Zero bugs. Ever.
No one has yet found a bug in Prevayler in a Production release. Who will be the first?
link.
I didn't know people still made such bold assertions past the dot-com era.
Thank you for the clarification.
I'm sure that, with its entire database cached in memory, MySQL's performance *does* improve dramatically. But it's still using maladapted algorithms for doing all of its queries -- the poor algorithms think they're reading blocks from a disk, not pages from memory. And of course every time the MySQL process performs a "disk" read, control reverts to the kernel and the process sacrifices the rest of its quantum. So MySQL will never be able to take full advantage of the fact that it's running with a memory backing store.
My point was simply that Prevayler is naturally going to be much faster than a MySQL database, because one of them is dealing with RAM and the other is dealing with disk. Hence, comparing Prevayler and MySQL performance is like comparing apples and oranges.
We're agreed that Prevayler is very useful, provided that your application fits its memory and reliability constraints. Thus, instead of distracting us with how much faster their orange is than the MySQL apple, they should spend their time evangelizing the "orange" way of doing things.
No incompatibility per se, but it's a rough analogy. People often use an SQL RDBMS along with some layer in between it and their OO language, the layer "flattening" objects into rows in the database, and then dynamically reinstantiating the row into an object in that language.
This is all fine and dandy when you have simple data- a "Person" object filled with nothing but integers and strings flattens fine into an SQL row. But then again, you're kind of just using that object as something not much more than a C struct.
However, when you have more active objects- which generally arise when you are actually doing good OO design and programming- the interface falls apart some. What if I've got my data objects pointing to other complex objects, rather than just elemental/translatable types like strings, numbers, and dates? What if the state of object A depends directly on what is going on in object B?
In an OORDBMS translation system, the objects are essentially dead while in storage. Object A can point to Object B - another row in a different database which holds data from a different class- but it dead.
A good object oriented database, like GemStone (for Java or Smalltalk) allows the objects to remain "alive" while in storage. I have never used or read much about this Prevayler db, so I don't know where it lies. There are some database systems which claim to be an "OODB," but are little more than an RDBMS and an object translation layer built in.
Not all applications benefit from the OODB methodology, but there are plenty which do. For an OO system which saw some decent design, an OODB is often a good fit. If all of your data is relatively simple- for instance, a customer and parts database on an e-commerce site- an SQL database will probably fit well enough.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
...the quasi religious cult sanctimonious denigration crap doesn't do much to convince either, as if storing tabular enterprise data in - GASP - "tables" is such a terrible thing to do indicative of a lower order of being in need of spiritual and philosophical cleansing and release from porridge-feeding in prison.
[Question: In SQL] Given a table of employees, and a table of offices, it's very easy to find those employees who don't have offices, and those offices who don't have employees. How can I do this in a consistent manner in Prevayler?
[Their answer:]
Trivial. But how about a query over polimorphically evaluated methods based on the current millisecond?
Talk of "trivial," you can already persist your Java objects into the same store as all your other data and access it either through EJB's, simple entity beans or straight SQL. IMHO, that is a far more useful model than locking everything into a pile of serialized object collections accessible only to a handful of Java gurus who have better things to do than write reams of application logic in order to tell Jim-Bob in accounts payable that he owes the janitor fifty bucks. If it takes less SQL than it would take to write the necessary includes in Java and I can still map everything into Java objects when necessary, why bother giving up 80% of your functionality to get only what is already there? Performance? Please. When the effort of generating a simple report exceeds the price of the CPU, just buy another CPU and save on labor. Besides, after being categorically insulted by these self-satisfied pricks, I wouldn't use their product if it would end hunger and bring about world peace.
I really appreciate the idea of a RAM targeted object repository layer, but as often happens, the Java guys tend to present their solutions as panaceias to every single application domain that slightly ressembles the problems they are attacking. I am really curious about how Prevalence compares to more naive in-RAM data storage approaches. Despite raising attention to the large quantities of memory not used in high end servers (and to the project itself), I simply can't see the point to compare it with mysql.
Furthermore, I can't avoid noticing the curious culture that has emerged with Java that you always have a single application/application instance for each machine. The dedicated server concept came to give reliability and CPU power, but WTF, do I really need a dedicated server to every application I run?