From: sss@world.std.com (Sergiu S Simmel)
Newsgroups: comp.object
Subject: Notes on Kala vis-a-vis Versant
Date: 17 Oct 92 03:37:11 GMT
Article-I.D.: world.SSS.92Oct16223711
Organization: Penobscot Development Corporation, Arlington MA




===========================================================================
                              Kala In Contrast

                        01 -- Kala vis-a-vis Versant
---------------------------------------------------------------------------



A while ago, Anthony Flynn (Technical Account Manager with Versant 
Corporation) posted a brief list of what he believed were the key
features of Versant. In his own words:

AF| [...] we think it's important that people be aware of the BEST 
AF| OODBMS on the market when making a decision)...
AF| 
AF| At Versant, we build, sell and support the following:

Comparing Kala to Versant is like comparing an engine to a car: sure
they have something in common (somewhere in its guts, the car does have
an engine), but an engine could also power a water pump, a boat, or a
sewing machine. However, there are functional issues that apply to
both, such as what kind of gasoline they use, and how much.

With that in mind, here is a brief commentary on where Kala stands 
with respect to the issues Mr. Flynn raised.

---------------------------------
Transparent Linguistic Interfaces
---------------------------------------------------------------------
AF| 1.  VERSANT ODBMS.  A high-performance, distributed ODBMS for 
AF| client-server environments.   Transparent interfaces are 
AF| supported from C, C++, Smalltalk , and Object SQL, with others 
AF| in the works.

While not entirely sure what Mr. Flynn truly means by "transparent
interfaces", one thing is clear: we are all evolving towards database
languages that are tightly integrated with programming languages. Now,
we achieve that by either extending the semantics of existing
programming languages to accommodate persistence semantics (a hybrid
solution) or we create new languages that are designed from the
beginning along these lines.

The debate as to which alternative should one pursue is way outside
the scope of this note. What's important here is no matter what the
path is, we'll end up with a language with persistence of some sort.
And ending up with a language implies standardization and widespread
acceptance of that language. Otherwise, we would be getting back to
the fragmented situation of the 1960's and 1970's when each product
had its own independent language.

Creating a language with persistence, no matter where you start, is a
difficult design task. Agreeing on one is even more difficult.  Both
require long evolution and substantial experience. I see the industry
nowhere near the end of that process.

Versant's 'transparent interface' is not just an interface, it is a
programing language as much as COBOL. True, the interface language is
a superset of an existing (somewhat standard) language, and it uses
(somewhat standard) compilers. But it is in fact a proprietary
language because it supports only Versant, as you will discover if you
try to run a Versant program against e.g. a GemStone OODB.

From a user's perspective, the situation is as bad as deciding to
program an entire product in a hardware vendor's proprietary language,
such as SAIL, PL/S, or one from a software vendor such as Visual
Basic.  I become captive to a monopolized semantics, since the
likelihood today of two vendors with identical or at least similar
views on the best integrated OO database language is a big zero. In
this the relational world is way ahead of the objects.

Moral: it is wise to be very cautious with adopting any such
"transparent interfaces" too broadly until the problem they are trying
to solve is treated comprehensively and the solution emerges as an
accepted one.

Meanwhile, users do need support for persistence services. They cannot
really wait until the industry gets its act together.

The solution to the dilemma: 

(a) devise an application architecture where the support for
    persistence is totally independent from any linguistic issues,     

(b) isolate the interaction with that support into a manageable 
    area of your application code, and 
    
(c) use the simplest and most generic (unlikely to change) means 
    for accessing that functionality.
    
Kala supports you remarkably well in all three aspects.

--------------------
Development Tool Set
---------------------------------------------------------------------

AF| 2.  VERSANT C++ Application ToolSet.  A set of application 
AF|     development tools for graphical ODBMS applications. 
AF|     (Though common with RDBMSs, integrated tools are
AF|     the exception rather than rule when looking at ODBMSs).  
AF|     This toolset includes:
AF|
AF|         -  VERSANT Screen.  Screen builder and scripting 
AF|            language.
AF|         -  VERSANT Report.
AF|         -  VERSANT Object SQL.
AF|
AF| VERSANT is also integrated with many third-party tools, 
AF| from companies like CenterLine, ParcPlace, ProtoSoft, 
AF| Rational, and others.

Versant is a total environment. You buy into it, and you stick with
it. If you need screen designers and report designers, *and* the ones
from Versant satisfy you -AND CAN BE EXPECTED TO CONTINUE TO DO SO FOR
THE LIFE OF THE APPLICATION HOWEVER IT EVOLVES-, then by all means go
with` Versant. You'll probably get a good value for your dollar.

But if you're just programming an application in C or C++, and your
problem is to simply store your data persistently, access it quickly,
and control its visibility among all other clients, then what you get
from such a vendor likely will be too different and way too complex
than what you need for the task at hand.

The integrated tools of Versant (or any other vendor) are as valuable
as your need for these particular tools is. If your need, however, is
simply SUPPORT FOR PERSISTENCE, then no report generator will help
you; it may stay in your way!

With Kala, you can use ANY tool that knows about ANSI C libraries.
So, if you work on a graphics intensive application today, you'll use
the graphics tools; you work on a real-time system tomorrow, you'll
switch to the tools for that domain. Across an organization, you'll be
able to mix and match whatever tools are best for the project at hand.
Kala remains simply a common resource, whose job is to let you manage
persistent data well, at low cost and high performance. No more, no
less.

-----------
Scaleability
---------------------------------------------------------------------
AF| VERSANT is designed with three goals in mind:
AF|
AF| *  Scaleability.  Goal is to let users scale across hardware 
AF|    (uni- and symmetric multi-processors), scale across nodes 
AF|    (transparent relocation of data, sometimes called object 
AF|    migration), scale across platforms (from desktop to big 
AF|    servers), scale across time (dynamic schema evolution so 
AF|    you can modify schema without unload/reload), and "scale"
AF|    across different networking configurations (host-based 
AF|    to client-server to "disconnected" client-server 
AF|    (e.g., laptops)).

This is a tricky and somewhat misleading use of the word
"scaleability", which in its sense of "ability to scale up" should
simply mean "the ability to maintain quality in the presence of
progressively higher quantity."

Mr. Flynn could have used conventional terminology, such as simply
*portability* for his "scaling across hardware", *distribution* for
his "scale across nodes", etc.

So, when it comes to scaleability in the conventional sense of the
word, the question is whether a product can maintain its qualities
(such as functionality, performance) in the presence of large amounts
of data or large numbers of simultaneous clients or large numbers of
interconnected servers, etc., etc.

For example, a scalable product should be able to support 10,000
communicating servers, each managing 50 gigabytes of data in its store
and serving thousands of clients over a continuously changing network
configuration, and deliver performance on the average equal to what a
single server on a single machine could do.

Is that what Versant can do today? Kala could ... by design.

Versant's scaling goals are admirable. After cutting out the fluff,
the claims reduce to three: Versant runs on lots of platforms; Versant
supports object migration, and Versant supports a limited form of
schema evolution. Let's consider each in turn.

Today, Versant runs on more platforms than Kala. However, we stand
ready to port Kala to an arbitrary platform of your choice on 60 days
delivery. Still, one point for Versant. However, Mr. Flynn's claim
be the BEST is not supported, as other OODBMSs (e.g. GemStone) are
more widely implemented.

Kala also does object migration, as does every other OODB except the
limited-function dedicated systems like ObjectStore. No points.

Schema migration in the Versant sense is inherently not part of a
persistence server like Kala, so the systems are intrinsically
incomparable. No points either way. 

So much for the claims behind the puff. If you consider the more
conventional meaning of 'scalable', Kala wins hands down - number of
clients, size of name space, architectural complexity supported, size
and size range of objects, DBA facilities, etc.  To cut back to
practical examples, we question whether Versant can handle 500
simultaneous TP clients from a single Unix server, or drop a disk from
use on a running system without rebuild.  These little things are what
determines the limits of scaleability, because you can always scale up
only until the first 'gotcha!'.

-----------
Performance
---------------------------------------------------------------------

AF| *  Performance.  Object databases are fast.  When we moved 
AF|    from NDBMS to RDBMS, everyone took a big performance hit to 
AF|    gain relational flexibility.  Many people expect a similar 
AF|    hit when they move from RDBMS to ODBMS.  It's just the
AF|    opposite:  ODBMSs -- all of them -- are fast.  While some 
AF|    vendors optimize for isolated users with lots of smaller 
AF|    objects (e.g., CAD), Versant is optimized for many users, 
AF|    in the distributed environments, with larger objects.  
AF|    Versant uses object-level locking (like row-level locking 
AF|    in RDBMSs, such as Oracle) to reduces contention.  In 
AF|    addition, VERSANT does well on basic tasks like online
AF|    space compaction and re-use.

OODBMSs may be faster than RDBMSs for some applications, but not as
fast as the vendors would like you to believe. I know of one large
application being in advanced stages of being build atop a commercial
OODBMS, and which displays severe performance problems to a large
extent due to the overhead introduced by the OODBMS.

Like Versant, Kala shines when it comes to distributed, multi-client
environments. Unlike Versant, it does so for objects of any size -- as
small as one byte and as large as you want.

Given the lower-than-object level of Kala, you can get the unit of
locking to be whatever your application semantics requires: an object,
a portion of an object, or a cluster of objects. It all boils down to
your decision on how to map your higher level object (or application)
semantics onto Kala's lower level persistent datum (or monad in Kala's
terms) semantics. The decision is that of establishing a unit of
transfer between virtual memory and persistent store, which also
becomes a unit of locking. That decision is inherently application
dependent, so the best place for it is within a layer above the
general purpose persistent data server, i.e. above Kala.  Versant's
choices for their system are no doubt reasonable for the typical
application - and since when are your applications typical?

The interaction between Versant's optimization for larger objects and
its object-based locking granularity implies that in practice what you
end up is larger grain locking units. Not so with Kala, where smaller
objects are as common (and optimized for) as larger.

Finally, it appears that Versant does some amount of persistent store
garbage collection (Is that true, Versant?). Since no clear picture
exists of how much is that, it is impossible to compare or contrast
that against Kala's very extensive and highly performant Scavenger,
which does garbage collection, physical storage compaction, automatic c
archiving, automatic clustering -- all in a server load balanced
manner.

----------------------------
Fast Application Development
---------------------------------------------------------------------

AF| *  Fast application development.  Goal is to let people build 
AF|    apps in just about any OO language (some ODBMSs are hard-
AF|    linked to a single language) that they want to use -- C, 
AF|    C++, Smalltalk, Object SQL, and others.  They can build apps
AF|    using Versant's C++ Tools (in conjunction with tools like 
AF|    ObjectCenter), tools from third parties, or a combination 
AF|    of the two.  Versant has an open tools philosophy, and 
AF|    offers its own tools to fill a specific niche in the C++ 
AF|    world.

Like Versant, Kala is language independent. Furthermore, Kala is
object-model independent. Kala's simplicity makes its "integration"
with *ANY* tool trivial; using Kala with your favorite tool is as easy
as using your tool with the operating system's file i/o library! No
special integration required; just make the Kala calls!  As simple as
that...


------------------------
If Further Questions ...
---------------------------------------------------------------------

AF| If you have any more questions, you can reach Versant at: 
AF| 1-415-329-7500, or 1-800-VERSANT.

While we don't offer an 800 number (yet!), we do offer a very
convenient and attractive forum for getting all your information about
Kala, asking questions about it, and seeing other people's questions
and the answers to them, to. This is the Kala Forum, available online
via Internet at no cost to you. To subscribe, simply send a request to
kala-request@world.std.com stating your full name, affiliation, and
what motivates your interest in Kala.

   +---------------------------------------------------------------+
   |   Copyright (c) 1992, Penobscot Development Corporation.      |
   |   Kala is a Trademark of Penobscot Development Corporation.   |
   +---------------------------------------------------------------+




  ___    ___    ___   ________________________________________________________ 
 |   `  |   `  |   `  Sergiu S. Simmel       Penobscot Development Corporation
  \ __   \ __   \ __   50 Princeton Road      Internet: sss@world.std.com
       \      \      \  Arlington, Mass        Voice:  +1-617-646-3951
   ` ___) ` ___) ` ___)  02174-8253 USA         Fax:  +1-617-646-5753 


-- 
  ___    ___    ___   ________________________________________________________ 
 |   `  |   `  |   `  Sergiu S. Simmel       Penobscot Development Corporation
  \ __   \ __   \ __   50 Princeton Road      Internet: sss@world.std.com
       \      \      \  Arlington, Mass        Voice:  +1-617-646-3951
Newsgroups: comp.object