Object Storage Past, Present, and Future - PowerPoint PPT Presentation

About This Presentation
Title:

Object Storage Past, Present, and Future

Description:

Title: Lessons Learned Implementing Object Databases Author: Douglas K. Barry Last modified by: DJMiller Created Date: 4/15/1997 11:36:32 PM Document presentation format – PowerPoint PPT presentation

Number of Views:183
Avg rating:3.0/5.0
Slides: 49
Provided by: Dougl319
Category:

less

Transcript and Presenter's Notes

Title: Object Storage Past, Present, and Future


1
Object Storage Past, Present, and Future

Douglas K. Barry Principal Barry Associates,
Inc. 13504 4th Avenue South Burnsville, Minnesota
55337 USA voice 1-952-892-6113
fax 1-952-892-5966 email doug_at_barryandassociate
s.com web http//www.barryandassociates.com
2
Full disclosure
  • Background
  • Training and industry practice in relational
    DBMSs
  • Got involved in object DBMS technology in 1987
  • Current Practice
  • Consultant in the area of selecting object DBMS
    and object-relational mapping products
  • Serve as the Executive Director of the Object
    Data Management Group (ODMG)

3
We will cover ...
  • Why object storage started the way it did
  • What is the current state of the industry
  • What impacts good object storage decisions
  • What distinguishes current object storage
    products
  • What will happen with object storage in the
    future
  • What standards will be important
  • What will characterize the major players in
    object storage

4
Why object storage started the way it did
  • Need for high performance on complex data
  • Need for multi-user database access to replace
    flat file single-user systems
  • Computer-Aided Design (CAD) drove many of the
    requirements

5
Complex data
  • often lacks unique, natural identification
  • often has a significant number of many-to-many
    relationships
  • often requires traversing a graph structure in
    the application(s)

6
Why not relational DBMSs?
  • Provided the desired multi-user database access
  • But performance was terrible on complex data

7
Why performance was terrible
Objects in the
application
Server
Client
Tuples stored on disk
8
Model mapping
ObjectApplication
ModelMapping
DBMSServer
9
C entered the scene
  • Object-oriented languages existed for some time
  • The most notable language was Smalltalk
  • Others included Lisp (CLOS), Objective-C, and
    Eiffel
  • C, however, captured the market

10
C binding for object DBMSs
Objects in the
application
Server
Client
Objects stored on disk
11
C binding for object DBMSs
  • Possible to store any C data structure directly
    with no mapping code
  • One model for both the application and database
  • No impedance mismatch
  • Cache management
  • Performance was 100 to 1000 times faster the
    relational DBMSs on complex data
  • Less code to write -- lower development costs

12
Object DBMS cache management
ObjectApplication
Cache
DBMSServer
13
Object DBMSs use
  • Aerospace
  • Design
  • Financial
  • Manufacturing
  • Publication
  • Telecommunications
  • Transportation

14
Object DBMS market size
Compound Annual Growth Rate (1998-2005) 46.9
Source Frost Sullivan, www.frost.com
15
Effect of Y2K on object DBMS market
  • 1998 and 1999 were low-growth years for object
    DBMS products
  • A significant portion of new development money
    went into Y2K fixes during these years
  • This had a major impact on the object DBMS market
    since object DBMSs are primarily used for new
    development

16
What is the current state of the industry
  • Relational DBMSs have maintained their market
  • The relational DBMS market has effectively become
    the object-relational market
  • Object DBMSs have exhibited a healthy growth rate
  • Large disparity between market size for Object
    DBMSs and Relational market
  • XML is entering the scene

17
And Java has entered the scene
  • Significant use in new development
  • Created new demands for object storage options

18
And XML has entered the scene
  • XML model is basically an object model
  • And like Java, XML has
  • Significant use in new development
  • Created new demands for object storage options

19
XML
lt?xml version"1.0"?gt lt?xml-stylesheet
href"catalog.xsl" type"text/xsl"?gt lt!DOCTYPE
catalog SYSTEM "catalog.dtd"gt ltcataloggt
ltproduct description"Cardigan Sweater"
product_image"cardigan.jpg"gt ltcatalog_item
gender"Men's"gt ltitem_numbergtQWZ5671lt/ite
m_numbergt ltpricegt39.95lt/pricegt
ltsize description"Medium"gt
ltcolor_swatch image"red_cardigan.jpg"gtRedlt/color_
swatchgt ltcolor_swatch
image"burgundy_cardigan.jpg"gtBurgundy
lt/color_swatchgt lt/sizegt ltsize
description"Large"gt ltcolor_swatch
image"red_cardigan.jpg"gtRedlt/color_swatchgt
ltcolor_swatch image"burgundy_cardigan.jpg"gt
Burgundy . . .
20
XML is complex data
  • some nodes lack unique, natural identification
  • has a significant number of many-to-many
    relationships
  • requires traversing a graph structure in the
    application(s)

21
Java and XML are going to drive object storage
  • Java appears to be the language of choice for new
    development
  • XML will be used more extensively as time goes on
  • The Java and XML object models will drive the
    need for efficient object storage particularly
    in the middle tier

22
Three-tier or n-tier architecture
XML
Internet
XML and Java
Middle tier
Existing data
Bottom tier
23
Object storage growth will be primarily in the
middle tier
XML
Internet
Middle tier
XML and Java
Existing data
Bottom tier
24
Middle-tier object storage options
  • Object DBMSs (ODBMSs)
  • Object-relational mapping (OR Mapping)
  • Relational DBMSs (RDBMSs)
  • Native XML DBMSs

25
What impacts good object storage decisions
  • Need to know your application needs especially
    the nature of your data and how you will use the
    data
  • Need to study the features of the various
    products
  • Need to analyze how the features of products fit
    or modify your application needs

26
What distinguishes current object storage products
  • Object DBMSs (ODBMSs)
  • Object-relational mapping (OR Mapping)
  • Relational DBMSs (RDBMSs)

27
Object DBMSs
  • Tight binding with object programming language
  • Application cache (some also have a server cache)
  • No model mapping
  • DBMS and application use same model
  • Highest performance on complex data
  • Lowest development cost

ObjectApplication
Cache
DBMSServer
28
Object-relational mapping
  • Tight binding with object programming language
  • Application server cache
  • Model mapping
  • DBMS and application use different models
  • Moderate performance on complex data
  • Moderate development cost

29
Relational DBMSs
  • Loose binding with object programming language
  • No application cache
  • Model mapping
  • DBMS and application use different models
  • Lowest performance on complex data
  • Highest development cost

30
More on model mapping
31
Product classification summary
32
Consider ODBMSs when...
  • You have a new application that needs high
    performance on complex data
  • 10 to 1,000 times faster than relational DBMSs
    depending on data complexity
  • Allows for lower hardware costs to achieve
    performance
  • You have a new application, but the data is not
    necessary complex
  • Allows for reduced development costs

33
Consider OR Mapping when
  • You have a new application that uses existing
    data from one or more existing databases
  • You have a new application that uses complex
    data, that has a high read to write ratio
  • Need to 10 to 100 reads of an object for every
    write to meet performance of ODBMSs, or
  • Plan on running with more powerful hardware to
    meet the performance of ODBMSs
  • Higher development costs than with ODBMSs

34
Consider RDBMSs when...
  • You want to add some object characteristics to an
    existing application/database to improve
    performance
  • You want to develop a new application, but your
    data is not complex
  • Development cost, however, is higher than with
    ODBMSs or OR Mapping products since you will have
    more code to write
  • Nevertheless, you probably have people who are
    familiar with the RDBMS on staff

35
Some architectural options
Internet
XML and Java
Middle tier
Bottom tier
36
Options for new data
Object DBMS
RDBMS
OR Mapping
Middle tier
Bottom tier
37
Options for using existing data directly
RDBMS
OR Mapping
ObjectApplication
Middle tier
Bottom tier
38
Object DBMS with relational DBMS
Object DBMS
Object DBMS and RDBMS
ObjectApplication
ObjectApplication
ModelMapping
Cache
Cache
Middle tier
DBMSServer
Bottom tier
39
Object DBMS with object-relational mapping
Object DBMS
Object DBMS and OR Mapping
ObjectApplication
ObjectApplication
Cache
Cache
Middle tier
DBMSServer
Bottom tier
40
Middle-tier ODBMS/RDBMS example
The Chicago Stock Exchange uses the Versant ODBMS
for its trading system in the middle tier. The
trading system stores data at the end of the
trading day in Oracle for running existing
back-office programs. There is a description of
the trading system along with architectural
diagrams at www.howstevedidit.com. This URL will
re-direct you to a Microsoft site that provides
several choices. Follow the Technical Roadmap
choice.
41
What will happen with object storage in the future
  • RDBMS vendors will universally adopt parts of
    SQL 1999 (SQL3)
  • Will still have impedance mismatch with object
    programming languages since the SQL 1999 object
    model does not match with Java or C
  • Tight object language bindings with caching will
    become universal
  • The JDO specification is the most likely
    candidate for a standard

42
What standards will be important
  • SQL-1999 (www.incits.org)
  • ODMG 3.0 (www.odmg.org)
  • Java Data Objects or JDO (access1.sun.com/jdo)

43
More on SQL 1999
  • Overriding principle is backward compatibility
    with SQL-92
  • As a result of this principle, the SQL 1999
    object model does not match either Java or C
    object models

44
More on ODMG 3.0
  • Overriding principle is transparent persistence
    for object languages
  • As a result of this principle, the ODMG 3.0
    object model matches both the Java and C object
    models

45
More on Java Data Objects
  • Overriding principle is to provide transparent
    persistence to both object and relational DBMSs
  • As a result of this principle, the JDO object
    model matches both the C and Java object models
    and provides an automatic mapping to relational
    DBMSs where needed

46
What will characterize the major players in
object storage
  • Ease of Java use
  • Performance with Java
  • Ease of XML use
  • Performance with XML
  • Ease of use with J2EE-compliant application
    servers, including both container-managed and
    bean managed-persistence

47
Free online overview articles
  • Object databases www.odbmsfacts.com/articles
  • Object-relational mapping www.object-relational.
    com/articles

48
Thoughts? Questions?
Write a Comment
User Comments (0)
About PowerShow.com