Discussions

News: Perst All-Java Embedded Database Adds KD-Tree Indexes

  1. McObject has added support for the KD-Tree, a database index with uses in spatial and pattern-matching applications, to Perst, its open source, object-oriented all-Java embedded database system. For developers working with Perst, the KD-Tree expands coding efficiency and helps make Java data objects easier to use in certain types of application. The new k-dimensional tree or KD-Tree index adds a structure in Perst that stores and manipulates point objects in a k-dimensional space by partitioning that space. Practical uses include computer graphics, geographical information systems and biometric applications such as fingerprint matching. In addition to their efficiency in handling multi-dimensional data, KD-trees are useful in "normal" applications in which query predicates contain various combinations of object fields. For example, KD-Trees are used to construct Query-By-Example (QBE) features in which the user selects fields and values, and the application builds database queries based on these selections. McObject's Perst embedded database and eXtremeDB embedded database offer an assortment of index types, including:
    • B-trees for common sorting and searches, insertions, and deletions
    • R-trees for geospatial indexing (common in GPS/navigation systems)
    • T-trees for all-in-memory data storage and accessHash tables for quickly locating a single unique index entry
    • Patricia trie index, which speeds searches in networking and telephony applications
    • "Custom indexes" for b-trees that allow the application to define the collating sequence of entries; this is useful in implementing soundex algorithm searches, for example
    • Bit or bitmap indexes that are optimized for columns in which values repeat frequently (for example, fields to which only three values could apply)
    • TimeSeries class to efficiently deal with small fixed-size objects
    • Specialized versions of collections for thick indices (indexes with many duplicates), and bit indexes
    KD-Tree support is built into the latest versions of Perst for Java and .NET, available for free download from McObject’s Web site.
  2. Nice. Does it have JDBC/JPA/JDO compatibility?
  3. Does it have JDBC/JPA/JDO compatibility?
    According to the intro to Perst, the closest you'll get to those is JDO, and that's a stretch. Perst is an object database, not a relational database; you access it via query-by-example or via an object tree, not by issuing SQL queries.
  4. the closest you'll get to those is JDO, and that's a stretch
    How on Earth (java earth :) will use database if it not support enterprise standards? May be they even have JCA connector? (LOL) I feel myself here as buyer of cofe cup that doesn't fit any cofe machine.
  5. I feel myself here as buyer of cofe cup that doesn't fit any cofe machine.
    As stated above it's an object database - so where would a technology like JPA, whose purpose it is to bridge the object - relational gap come in? To take your comparison it's a beer glass not fitting a coffee machine which is true for most beer glasses.
  6. As stated above it's an object database - so where would a technology like JPA, whose purpose it is to bridge the object - relational gap come in?
    Well actually it is perfectly feasible to use the JPA API (EntityManager : persist(), merge(), remove(), find()) to handle persistence to a datastore of this type; we did the exact same thing in JPOX for allowing persistence using JDO/JPA to db4o. The part of JPA that is totally aligned to RDBMS is the query language and there you would have difficulty in providing a JPQL/SQL interface to an object datastore (but it also has to be said that such a thing is not beyond possibility, since db4o has an SQL interface plugin). The problem really is that the JPA Query API is (politically) blinkered towards RDBMS and could very easily have allowed a language attribute be specifiable in the API and hence allow all manner of query languages (just like JDO does). --Andy Java Persistent Objects (JPOX)
  7. As stated above it's an object database - so where would a technology like JPA, whose purpose it is to bridge the object - relational gap come in?
    To take your comparison it's a beer glass not fitting a coffee machine which is true for most beer glasses.
    I think that the biggest problems for gentlemen writing Object Databases is that they don't deeply look after the systems they integrated to. Yes, that is a lot of things to do - understand how JCA/JPA/JDO must be implemented on their side and how to support JDBC. (BTW, they not required support SQL. They required to recieve strings, which can be some object queries) But it's required things to do - and they just don't understand this.
  8. Agreed - while OO databases do have their use cases one of the biggest downsides is integration or external access. For me it seems to boil down to yet another embedded database with its own (more or less) proprietary API. For us SQL freaks they offer "eXtremeSQL™ embedded database SQL interface" - but if I need SQL why not use free alternatives like Derby/JavaDB? -- Markus Plesser [fleXive] core developer http://www.flexive.org