penneyj@servio.UUCP (D. Jason Penney) (08/21/89)
I have been reluctant to jump into this fray, but with the submission by David Harrington, an ex-Servio employee, I am compelled to make a response and some corrections. In article <1037@unify.UUCP> dgh@unify.UUCP (David Harrington) writes: > >Look at Servio Logic. It has been building GemStone for at least 5 years, and >as of April of this year had maybe 30 systems installed -- mostly 4 user GemStone currently has much more than 30 systems installed. The exact size of our install base may be proprietary information, so I can't say more than that. (Our salesmen might actually volunteer that information; I'm just saying it's not my place to give it out on the net.) As for how long we've been developing GemStone, just how long did development go on INGRES before 1) it became fast enough to woo people away from older more mature technologies and 2) RTI managed to "sell" people away from those older technologies? That's a rhetorical question, actually. My points are, there is a long development cycle in databases to reach competitive performance (we're 10 years younger than INGRES!), and the inertia of the customer base can not be underestimated (they've just disovered RDBMSs in the last couple of years). > >systems in R&D labs. The only reason Servio is still around is that they are >funded by the House of Sampoerna, an Indonesian tobacco company run by a >41-year old Chinese "Tai-Pan" named T. Pao Liem who has MUCH more money than >he needs. Mr. Harrington should appreciate that Mr. Liem does not subscribe to the short term "management by objective" that has killed the long-term viability of many other American companies. >GemStone has no front-end, no distributed database, no 3rd party >developers (other than a small group of Servio employees in Alameda trying to >build an MRP system in Smalltalk (!) that uses GS as a structure server). > Incorrect! Our front ends may currently be limited (we have several front-ends, and better things are on the way), but we currently have the best distribution and heterogeneity of any of the OODMS's (Object-Oriented Data Management System) I have seen. (Apologies to Object Design -- I haven't seen their work yet.) We currently allow applications to run on different (and heterogeneous) hosts, and RPC (remote procedure call) operation is optional -- you can link your program directly to our runtimes, reducing fixed overhead for a database operation to a function call. We currently have a number of third-party developers, an OEM, and even some industrial applications by our customers. >They have based their marketing strategy, such as it is, on an assumption that >the market for OODBMS, which they say is "applications requiring a LOT of >COMPLEX data", will mature at least 5X as fast as the relational market did. > This information is out of date. Recent responses by the RDBMS companies have caused us to re-think our marketing position. Surely the discussion here in comp.databases indicates that the OODMS and x-RDBMS systems will be addressing the same problem domains. Again, I don't feel qualified to give a "party line" on this subject, but be sure to ask us at OOPSLA in New Orleans. >I think the path to OODBMS is evolutionary, especially given the huge install >base of RDBMS and applications that use them. No argument here, at least. Since I've been dragged into a follow-up, I would like to point out my own personal opinion as to why an OODMS may eventually out-perform an x-RDBMS: Relational systems rely on "normalizing" data into separate relations, and then joining the relations at query time to formulate results. OODMSs essentially pre-calculate the joins. Applications that are heavier on writing than reading will probably always perform better on an x-RDBMS, because the join calculation is deferred. Applications that read the database more than they write it will win with an OODMS, because the need for joins during the query is eliminated. Arguments about in-memory caching are spurious (as others have pointed out), because all successful databases must reduce disk accesses to a minimum and rely on primary memory caching to achieve adequate performance. A final note, grounding in reality: database systems in the 90's will have to cooperate with other dissimilar systems. RDBMSs aren't going to vanish (as much as I might personally hope for that) -- the investment in existing data sets and applications is too high. Successful OODMSs will have to cooperate with RDBMSs (see our demo at OOPSLA) in order to achieve market acceptance. But please don't ask GemStone to do a join -- that's asking an OODMS to emulate the performance bottlenecks of an RDBMS. -- D. Jason Penney Ph: (503) 629-8383 Beaverton, OR 97006 uucp: ...uunet!servio!penneyj STANDARD DISCLAIMER: Should I or my opinions be caught or killed, the company will disavow any knowledge of my actions...
mendel@db.toronto.edu (Alberto Mendelzon) (08/24/89)
In article <161@servio.UUCP> penneyj@servio.UUCP (D. Jason Penney) writes: >I would like to point out my >own personal opinion as to why an OODMS may eventually out-perform an >x-RDBMS: Relational systems rely on "normalizing" data into separate >relations, and then joining the relations at query time to formulate >results. OODMSs essentially pre-calculate the joins. Applications that >are heavier on writing than reading will probably always perform better >on an x-RDBMS, because the join calculation is deferred. Applications >that read the database more than they write it will win with an OODMS, >because the need for joins during the query is eliminated. An interesting argument, but I'm not sure it holds water. The better a relational system is at computing joins, the more likely that there will be a substantial overhead at write time in updating indices, etc. In the other direction, applications that mostly read can have their joins pre-calculated even in a relational environment by using constructs such as snapshots or materialized views. In fact, the applications that are usually mentioned as best suited to OO systems (CAx and such) do not seem to require much more reading than writing - or do they? Alberto Mendelzon University of Toronto mendel@db.toronto.edu
dlw@odi.com (Dan Weinreb) (08/29/89)
In article <161@servio.UUCP> penneyj@servio.UUCP (D. Jason Penney) writes:
I agree with almost everything you say, but I'd like to comment on one
paragraph.
Arguments about in-memory caching are spurious (as others have pointed
out), because all successful databases must reduce disk accesses to
a minimum and rely on primary memory caching to achieve adequate performance.
Not everything that has been said in comp.databases about memory
caching is spurious. It is true that a relational database could
follow the same caching protocols as any object-oriented database, in
principle. However, in commercial practice, the distributed
relational database systems use certain kinds of caching and
distribution that are very different from the kind of thing that we
are using. Neither kind of caching is "right" or "wrong"; each is
appropriate for certain kinds of usage patterns, and for certain
applications. Neither is tied in a theoretical sense to any
particular data model, but they might be *correlated* to some degree
with data model, and other attributes of a DBMS, based on the target
market for the DBMS product. Certainly all DBMS's will strive to
minimize disk access, and certainly all will use some form of primary
memory caching to do it, but the next level of detail differs from one
DBMS to another and can have large effects on performance. The paper
by Rubenstein, Kubliar, and Cattell that was recently cited in
comp.databases goes into this question in greater detail.
Dan Weinreb Object Design, Inc. dlw@odi.com