Perst, Open Source Embedded Database for Java, Released

Home

News: Perst, Open Source Embedded Database for Java, Released

  1. McObject LLC has released Perst v2.64, an open source, object-oriented embedded database for Java that offers transparent persistence and ease in working with objects.

    McObject is offering Perst as a free download for evaluation and non-commercial use, and spearheading its development in the open source community. McObject also now sells Perst support as well as commercial licenses.

    Under Perst's dual license, users can modify database source code and use it freely in non-commercial applications (software that is neither sold nor used internally by a business, and for which source code is made available) under the GNU General Public License (GPL). McObject's commercial license is required if Perst-based software will be sold or used for business, or if source code is to be withheld.

    Perst is ideal for Java applications requiring a modest footprint and fast, multi-platform data management - typical uses include packaged software, mobile and embedded applications, Web services and industrial systems. With a run-time code footprint of between 30K and 300K, Perst fits well within the resource constraints of many embedded systems applications.

    Perst's fundamental achievement lies in making persistent Java objects as efficient and easy to use as possible. In most cases, Perst automatically loads the persistent objects without explicit programmer command. When used with aspect-oriented tools such as AspectJ and JAssist, Perst provides completely transparent persistence.

    Perst classes enable efficient filtering of collection elements. For efficient access to persistent objects, Perst also implements specialized collection classes optimized for different data layouts and access patterns, including: a classic B-Tree implementation; R-tree indexes for spatial data representation; main-memory database containers, based on T-Tree indexes, optimized for memory-only access; the Patricia Trie index to support IP address data; a TimeSeries class to efficiently deal with small fixed-size objects; specialized versions of collections for thick indices (indices with many duplicates), and bit indices (keys with a restricted number of possible values).

    In contrast to object/relational databases, or tools that provide object/relational mapping, Perst stores data directly in Java objects. This eliminates the need for expensive (in performance terms) run-time conversions between the database representation of the data and the Java representation.

    Unlike many other object-oriented databases, Perst requires no dedicated compiler, byte code processor or specialized Java run-time environment, yet provides a high degree of application transparency. The Perst API is convenient, flexible and easy to use. Perst requires no end-user administration, and along with its simplicity, Perst ensures integrity via transactions that adhere to the ACID properties (Atomicity, Consistency, Isolation and Durability) with very fast recovery.

    Perst also provides features such as garbage collection, detection of hanging references, automatic schema evolution, XML import/export utilities, master-slave replication support (with the option to run read-only queries on slave nodes), and integration with AspectJ and JAssist AOP tools.

    Threaded Messages (19)

  2. db4o[ Go to top ]

    How does this database compare to db4o?
  3. db4o[ Go to top ]

    How does this database compare to db4o
    On a quick glance, Perst requires you to inherit all persistent classes from org.garret.perst.Persistent. db4o can store objects of any class.
    Querying functionality in Perst seems very rudimentary, nothing nearly as sophisticated as db4o native queries.
  4. We are using db4o as a "real time database", that is, in memory, not as a classic "hard" persistence.
    Of course, you can persist objects, but we think it's not really oriented to do it.
  5. I should note before that to solve "classic" persistence, we are very interested in Hibernate replication, a feature recently released. Until now, we were using an ad-hoc Oracle mapping.
  6. Under the GPL, you may download and evaluate the source code free of charge and you may use McObject Open Source Databases free of charge in a non-commercial application

    Apologies in advance if this turns into a licensing discussion, but if a company uses the GPL, aren't you entitled to use under the conditions in the GPL license itself? If I used this for a commercial product that I hosted myself (i.e. didn't distribute) and didn't make any changes to the code or use the libraries directly, wouldn't I be protected by the GPL?
  7. I was thinking about posting a rant about that kind of licensing myself. If it were real GPL you would be right. But this is "only GPL for non-commercial and for the rest payware". In my book that doesn't even deserve the name opensource because the source is not generally open. I won't even take a look at it.
  8. Is not your statement is copyright violation ? GPL license is protected by law itself and as I understand you can not use it to promote your mofified license.
  9. According to the site, http://www.mcobject.com/perst/perstlic.shtml, it's GPL.

    Do with it what you want.

    They seem to be under the impression that GPL and Commercial are mutually exclusive. They're in for a rude shock.

    I tried to download it, but their PHP based reg system is honked at the moment.
  10. Db4o also has a similar, dual licensing. Recently, I had an email exchange with one of the Db4o marketing guys and the outcome is that, if you are using it in a commercial product, then you have to buy their commerical license, unless you publish your code. So, unless you are writing some kind of open source framework, which you are going to publish anyway, you cannot use their GPL license.

    I wasn't able to compare Perst with Db4o, but Db4o lets you download and evaluate the product without any registration requirements. So, at least, it has one simple step :-)
  11. Db4o also has a similar, dual licensing. Recently, I had an email exchange with one of the Db4o marketing guys and the outcome is that, if you are using it in a commercial product, then you have to buy their commerical license, unless you publish your code. So, unless you are writing some kind of open source framework, which you are going to publish anyway, you cannot use their GPL license.

    *sigh*

    There's nothing stopping you from creating a product, selling that product, and distributing it with the source code under the GPL. You can then have support agreements, updates, etc. etc., just like any other software package.

    If the distinction between "commercial" and "GPL" is getting the source code, then you're mistaken.

    MOST commercial companies choose to not do this, thinking I guess that most car dealers, toy stores, public warehousing centers, and cemetaries want to be in their own business as well as in the distributing source code business.

    As a GPL licensee I am not obligated to give the source to code to anyone, only the people I choose to give the programs too. Now, there's nothing stopping those people from giving it to whoever they want, as they are free to do so, but in many businesses, it's not really a big deal. Setting up FTP servers with tarballs just really isn't in their mission statement.

    So, to be clear. I can create "Frank's Cemetary and Fast Chinese Food Management System" providing entire systems with hacked Linux kernels, changed GNU C libraries, GNU Classpath and Perst. All GNU things, all "open source".

    I am under no obligation to post that system on a public server, make CD's available to anyone who asks, or any other such thing.

    If "Howies Memorial Chinese Garden" would like to buy that software system from me, and I distribute it to him, then I am obligated to make the source code available to HIM, and he is free to do with it whatever he likes (including redistribute it). If I ship him a server filled with binaries running FCFCFMS v2.7 with the source on the hard drive, I've met my obligation under the GPL. If I post the source code under a password protected login that only HOWIE knows, and make that login valid for 3 years, I have met my obligation to the GPL as well.

    So, again, Commercial and GPL can be perfectly compatible.
  12. There is no problems to distribute software with source code with open source license. If somebody forks your code then you are very lucky, it means your source code is usefull and it will help to sell orinal product.
  13. HSQLDB is really open sourced[ Go to top ]

    As far as I know, HSQLDB is a real open-source project. And moreover, it seems to be one of the best in terms of performance if I believe the performance benchmark I found on the perst website (poleposition).
    I have used HSQLDB for tests and developpement and did not face any specific issue.
    Please note that Perst does not publish any performance data on their website. Perst is not included in the poleposition benchmark and they did not publish their own results (the link say : "comin' soon").
    The dual license seems weird to me. Maybe a new kind of license is more adapted (something like : open source, free for students, training and test purposes but you have to pay if you use it on production).
    I wonder how many commercial licenses they can sell.
    Why should I pay for something I can have for free?
    In other terms what are the advantages of Perst vs HSQLDB?
  14. GPL vs LGPL and Java[ Go to top ]

    This is exactly how MySQL is licensed. So, as long as the product is compelling, I doubt the license will get in the way of their success. However, there is an IP issue here for companies that want to use the product.

    The issue surrounds the GPL and whether or not it taints your own source code. In MySQL, you have to link against their JDBC driver, which you can get under two licenses, one a commercial license, that lets you use it in commercial situations, and the other GPL. Perst seems to be doing the same thing, except that you have to link against their embedded db JAR. If you try and use the GPL license in a commercial context, of course you can, but the result is that your own source code then is GPL'd.

    This is the difference between the LGPL and the GPL. If you link against a JAR that is LGPL'd, your code is not affected. If you link against a JAR is that GPL'd, your code has to be available as per the GPL, ie anyone can ask you for it and you have to provide it.

    IANAL, but this is what several lawyers have independently understood when they were assisting with technical due diligence that I happened to be a part of.
  15. GPL vs LGPL and Java[ Go to top ]

    In MySQL, you have to link against their JDBC driver, which you can get under two licenses, one a commercial license, that lets you use it in commercial situations, and the other GPL. [..] This is the difference between the LGPL and the GPL. If you link against a JAR that is LGPL'd, your code is not affected. If you link against a JAR is that GPL'd, your code has to be available as per the GPL, ie anyone can ask you for it and you have to provide it.

    The problem that MySQL has is that the applications link to JDBC, which has a license that does NOT force them to publish their code. The MySQL JDBC driver is a runtime binding (e.g. a line in a config file on an app server), so the intent of the GPL is likely unenforceable in this case.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  16. GPL vs LGPL and Java[ Go to top ]

    >The problem that MySQL has is that the applications link to JDBC, which has a license that does NOT force them to publish their code. The MySQL JDBC driver is a runtime binding (e.g. a line in a config file on an app server), so the intent of the GPL is likely unenforceable in this case.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    This is how I've always viewed it too but I'm really not sure anymore. In a scenario where I'm not distributing software: If I build a departmental application that connects to MySql through a JDBC driver, then I should be within my rights to use this without obtaining a license and I should not be forced to GPL my application.

    From what I read, there are obviously different opinions on whether this is legal or not. This sort of thing, in my mind, makes the other open-source database alternatives all the more appealing. Who wants to deal with those issues when they don't have to? I should think that companies like MySql would want to make these matters crystal clear because ultimately the uncertainty is what will keep customers and future customers away.

    Mike
  17. GPL vs LGPL and Java[ Go to top ]

    The problem that MySQL has is that the applications link to JDBC, which has a license that does NOT force them to publish their code. The MySQL JDBC driver is a runtime binding (e.g. a line in a config file on an app server), so the intent of the GPL is likely unenforceable in this case.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    IANAL, but IIRC, GPL is more concerned with distribution than linking. You can link to whatever GPLed software you want, as long as you don't distribute it. Also, if you do distribute your software and it is not able to run without being linked to the GPLed software I'm sure they could argue that this constitutes a "derivative work". GPL v3 is supposed to clarify these issues.
  18. GPL vs LGPL and Java[ Go to top ]

    This is exactly how MySQL is licensed. So, as long as the product is compelling, I doubt the license will get in the way of their success. However, there is an IP issue here for companies that want to use the product.The issue surrounds the GPL and whether or not it taints your own source code. In MySQL, you have to link against their JDBC driver, which you can get under two licenses, one a commercial license, that lets you use it in commercial situations, and the other GPL. Perst seems to be doing the same thing, except that you have to link against their embedded db JAR. If you try and use the GPL license in a commercial context, of course you can, but the result is that your own source code then is GPL'd. This is the difference between the LGPL and the GPL. If you link against a JAR that is LGPL'd, your code is not affected. If you link against a JAR is that GPL'd, your code has to be available as per the GPL, ie anyone can ask you for it and you have to provide it.IANAL, but this is what several lawyers have independently understood when they were assisting with technical due diligence that I happened to be a part of.

    That is also my understanding with one caveat. The GPL only kicks in when you redistribute the GPL'd code. So whether or not something is "commercial" is irrelevant from the standpoint of the GPL. I can base my entire business on an application which uses GPL code and, as long as I don't redistribute that application outside of the company, I don't need to give the code to anyone. Or I could write a commercial web application which uses GPL code and never need to distribute the code because I'm not distributing the application.
  19. Another embedded DB[ Go to top ]

    For those interested in the subect, Jalisto, an open source component from ObjectWeb developed by Xcalia, proposes another approach to embedded Java databases:

    * non-relational database
    * minimal memory footprint
    * very efficient execution
    * fullt transactional
    * Query language (SODA based)

    Jalisto (JAva LIght STOrage) is a modular database so that you can activate only the modules you need:
    * single or multi-user
    * single or multiple files
    * logging or not
    * JMX admin or not
    * run in the same JVM as the application or remote server with client-server protocol
    * you can plug another physical layer
    * ...

    You can use your favorite persistence API/layer on top of Jalisto. So Jalisto is not Yet Another Java ODBMS, it is really a minimal efficient storage component you can tailor to your own needs.

    Best Regards, Eric.
  20. We are contributing to this discussion in the hope that we can address some of the concern about our open source/dual license business model, the GPL, and to position Perst relative to other OODB.

    With respect to the business model: We elected to follow the same licensing philosophy as MySQL, Sleepycat, db4o and others. Further, we elected to use the GPL rather than invent some new open source license that would need to be vetted by the open source community. The GPL is well established, if not well understood. We are also not going to use this forum to argue about what is and what is not a “commercial use” or what constitutes “distribution”. The aforementioned vendors and McObject all pretty much agree on what our intent is.

    There is some justification for the consternation about the use of the term “open source” for technology that isn’t entirely “free as in free beer”. However, in our defense, it should be noted that the industry has come down on the side of Open Source meaning just that, and nothing more (as evidenced by the fact that some of the most popular open source products are “dual license” but we (the community) and the media all still refer to them as Open Source. In summary, Perst is Open Source. You can download the source code free of charge (we don’t even require that you provide valid contact information in the registration form; it’s voluntary) and use it in accordance with the terms of the GPL unless you don’t want to conform to the GPL, in which case you can buy a commercial license from McObject.

    With respect to positioning: Perst is an embedded database in the true sense of the term, meaning that it is embedded into a single application and can be shared by multiple threads within that application, but has no means for multiple processes, even on the same host, to share a database. If that is a requirement, then Perst is not a solution for you.

    That context makes possible some optimizations for Perst that are not possible, or would be exceptionally difficult (and probably unjustified) for embedded databases that do support multiple concurrent processes. Most notably, the implementation of transactions via index pages instead of transaction logs affords a tremendous performance advantage. (This is more fully described at http://www.mcobject.com/perst/persttheory.shtml under the heading “Transaction Model”.) And not having the overhead of a client/server architecture also lends a tremendous performance advantage.

    Perst is also not an SQL database. It is possible to implement complex lookups (filters), as illustrated on http://www.mcobject.com/perst/perstarch.shtml under the heading “Projection”. Granted, it is “different” than SQL, but takes about the same amount of effort to code and accomplishes the same result without the overhead of SQL.

    In short, if you need to manage persistent collections of objects within a single- or multi-threaded application, Perst may be an excellent choice for you.

    With respect to performance:

    1. We have recently been asked to add Perst to the popular PolePosition benchmark. PolePosition is a benchmark test suite that compares a number of database engines and object-relational mapping technology. By the originators own admission, it is not complete, but we believe it is a reasonable starting place to compare object database technologies and have therefore agreed to support the effort.
    The original PolePosition test suite did not include a Perst implementation, so we have created a Perst “team” for PolePosition. Due to how Perst works, we copied some files from the PolePosition framework and made local copies of them (because Perst requires all persistent capable classes to be derived from the Persistent base class). It is possible to avoid this requirement, using either the AspectJ or JAssist reflection packages, but it will significantly complicate the integration of Perst in the test suite and we preferred that the Perst implementation be as straightforward as possible. The source code for the Perst team can be downloaded from here. We’ve performed the comparison only with db4o because it seems to be the closest competitor for Perst. Please check out the results.
    Please note that there are two variations of the Perst results: with ACID transactions and with asynchronous transactions. By default, Perst implements transactions that fully support the ACID properties (Atomicity, Consistency, Isolation, and Durability). The ‘Durability’ property requires that each and every transaction commit be written through the file system cache to ensure that each transaction can be recovered. This is tremendously costly in terms of performance (it is a mechanical operation, physically writing on the media, and out of Perst’s control). Asynchronous transactions relax the adherence to the Durability property, and thus gain a tremendous performance advantage, and we have implemented a Perst variation of PolePosition in this mode for a direct ‘apples-to-apples’ comparison with db40.
    2. Another benchmark available for your consideration is called the OO7 benchmark. OO7 is a simple and popular benchmark for object oriented databases. A port of this benchmark to the Java environment is included in Ozone (a pure Java OODBMS) distributions. We have ported the benchmark for Perst and also made some changes and bug fixes in the original Ozone OO7 implementation. The changes that were made are:
    1. Added a missing file in the preprocessor list in build.xml
    2. Fixed a bug in the "query match" implementation
    3. Increased the number of the searched objects in the "query match"
    4. Removed all trace messages to stdout,


    Please request the patched version of the OO7 benchmark for Ozone from us by sending e-mail to support at mcobject dot com

    The benchmark results (measured in milliseconds) are as follows:
    Product create small query traversal query match
    Perst 1 041 1 352 0 431
    Ozone 112 732 13 680 0 591

    Andrei Gorine
    McObject