Comment Prevayler: can it work? (Score 2, Interesting) 444
From my weblog:
Could loading all your objects into memory, and keeping them there, possibly work? That's what the folks at www.prevayler.org think. Breakthroughs in memory technology, cheaper RAM, 64-bit computing, better JVMs -- all these instances of technological progress, we are told, ought to finally make it possible to keep all your domain objects in main memory. The advantages are obvious. Systems become simpler. The need for caches is all but eliminated. Performance can be enhanced dramatically as there is no longer need for expensive disk access or network communication with the database. No longer are you limited by the query language of your database; use whatever query mechanism that best suits your needs.
Wonderful! But, does it work in practice?
1. Cheaper RAM. While it is true that RAM has been getting cheaper and cheaper, the same is true of hard disks. A look at the web site of a nearby computer shop reveals that a 512MB RAM unit costs 84 euros; you can buy an 80GB hard disk suffering the same amount of monetary drain. It is not to be expected that this two-orders-of-magnitude difference would disappear anytime soon. Therefore, for large amounts of data, even if you could buy enough RAM, would you really like to?
2. 64-bit computing and JVM support. Extensions like Intel Extended Server Memory Architecture aside, 32-bit computers can address only 4 gigabytes of data. In practice the number for an individual application is less, and for a Java application even more so. Java heaps on x86 platforms were restricted to approximately 1.5GB last I looked. This is not enough for many enterprise applications. It is not nice to be running at 1GB heap utilization, knowing that users are creating new objects all the time, fast...
64-bit architectures get rid of the 4GB barrier thus carrying with them a promise of prevalence nirvana. Right now, though, all 64-bit systems are stratospherically expensive. Have you seen the prices of those Itanium 2 boxes? AMD promises to come to the rescue with x86-64, but the practical utilization of this architecture from Intel's chief rival in Java application is a little off, since there's not even a Java VM for x86-64 yet (though one has been promised to appear in 2004).
3. Simplicity. I'd love getting rid of caches. Caches suck! And don't even get started on all that pesky O/R mapping stuff. Without a query language, though, the distinct possibility exists that the magic box full of promises will turn out to be half-empty. Writing queries in SQL is, well, convenient. If you have to manually construct hashtable-based indexes, then the value proposition of object prevalence diminishes. Fortunately, there are object query languages, though none of them seems to be widely accepted as a standard. However, there should be no obstacle in principle why such standardization couldn't take place.
4. Performance. Queries from a hashtable-based index are fast. For updates the situation is different, as updates will have to be written to the command log; all in-memory indexes, too, will have to be updated. If such indices are not maintained, databases could in case of a huge data set turn out to be faster, even though they often have to access the disk to get to the data. The big performance advantage that I see coming from object prevalence is in the area of very complex, deeply-linked data structures: you can build them and still not worry, given the right combination of hashtables.
Conclusion? If an application deals with lots of data, or if the amount of data grows fast or unpredictably, object prevalence won't be viable until 64-bit architectures establish themselves in the marketplace (which should take a couple more years). Regardless, you can look for subsets of data that could be kept in memory in their entirety. The more often that data is accessed, the more performance benefits will accumulate. For example, in a server-side business application, it might be possible to store user information in memory even though doing the same for all the messages posted on the message board of the site would prove too expensive or impossible.
It is good to see fresh thinking in the object persistence area! Although O/R tools like Hibernate have considerably mitigated the pain once associated with O/R mapping, object prevalence, correctly applied, has the potential to take us to the next level of truly transparent persistence.
Could loading all your objects into memory, and keeping them there, possibly work? That's what the folks at www.prevayler.org think. Breakthroughs in memory technology, cheaper RAM, 64-bit computing, better JVMs -- all these instances of technological progress, we are told, ought to finally make it possible to keep all your domain objects in main memory. The advantages are obvious. Systems become simpler. The need for caches is all but eliminated. Performance can be enhanced dramatically as there is no longer need for expensive disk access or network communication with the database. No longer are you limited by the query language of your database; use whatever query mechanism that best suits your needs.
Wonderful! But, does it work in practice?
1. Cheaper RAM. While it is true that RAM has been getting cheaper and cheaper, the same is true of hard disks. A look at the web site of a nearby computer shop reveals that a 512MB RAM unit costs 84 euros; you can buy an 80GB hard disk suffering the same amount of monetary drain. It is not to be expected that this two-orders-of-magnitude difference would disappear anytime soon. Therefore, for large amounts of data, even if you could buy enough RAM, would you really like to?
2. 64-bit computing and JVM support. Extensions like Intel Extended Server Memory Architecture aside, 32-bit computers can address only 4 gigabytes of data. In practice the number for an individual application is less, and for a Java application even more so. Java heaps on x86 platforms were restricted to approximately 1.5GB last I looked. This is not enough for many enterprise applications. It is not nice to be running at 1GB heap utilization, knowing that users are creating new objects all the time, fast...
64-bit architectures get rid of the 4GB barrier thus carrying with them a promise of prevalence nirvana. Right now, though, all 64-bit systems are stratospherically expensive. Have you seen the prices of those Itanium 2 boxes? AMD promises to come to the rescue with x86-64, but the practical utilization of this architecture from Intel's chief rival in Java application is a little off, since there's not even a Java VM for x86-64 yet (though one has been promised to appear in 2004).
3. Simplicity. I'd love getting rid of caches. Caches suck! And don't even get started on all that pesky O/R mapping stuff. Without a query language, though, the distinct possibility exists that the magic box full of promises will turn out to be half-empty. Writing queries in SQL is, well, convenient. If you have to manually construct hashtable-based indexes, then the value proposition of object prevalence diminishes. Fortunately, there are object query languages, though none of them seems to be widely accepted as a standard. However, there should be no obstacle in principle why such standardization couldn't take place.
4. Performance. Queries from a hashtable-based index are fast. For updates the situation is different, as updates will have to be written to the command log; all in-memory indexes, too, will have to be updated. If such indices are not maintained, databases could in case of a huge data set turn out to be faster, even though they often have to access the disk to get to the data. The big performance advantage that I see coming from object prevalence is in the area of very complex, deeply-linked data structures: you can build them and still not worry, given the right combination of hashtables.
Conclusion? If an application deals with lots of data, or if the amount of data grows fast or unpredictably, object prevalence won't be viable until 64-bit architectures establish themselves in the marketplace (which should take a couple more years). Regardless, you can look for subsets of data that could be kept in memory in their entirety. The more often that data is accessed, the more performance benefits will accumulate. For example, in a server-side business application, it might be possible to store user information in memory even though doing the same for all the messages posted on the message board of the site would prove too expensive or impossible.
It is good to see fresh thinking in the object persistence area! Although O/R tools like Hibernate have considerably mitigated the pain once associated with O/R mapping, object prevalence, correctly applied, has the potential to take us to the next level of truly transparent persistence.
