Content deleted Content added
m Basic copyedit changes for removal of extra spaces. |
|||
Line 8:
== History ==
Objectivity/DB was first sold in 1990. The C++ and Java interfaces for Objectivity/DB incorporate the features defined in the ODMG'93 standard.<ref name="odmgBook">
{{cite book |url=https://archive.org/details/isbn_9781558606470_0 |title=Object Data Standard: ODMG 3.0 |author1=R. G. Cattell |author2=Douglas K. Barry |author3=Mark Berler |author4=Mark Berler |author5=Jeff Eastman |author6=David Jordan |author7=Craig Russell |author8=Olaf Schadow |author9=Torsten Stanienda |author10=Fernando Velez |date=January 2000 |publisher=Academic Press |isbn=1558606475 |accessdate=December 1, 2014 |url-access=registration }}
</ref> The C# and Python interfaces were added subsequently.
Line 15 ⟶ 14:
== Architectural features ==
Objectivity/DB is a [[distributed database]] that provides a single logical view across a federation of databases distributed across the network. It uses a [[distributed computing]] model that links a small software library with the client application. The client transparently communicates with remote servers that are functionally simpler than their equivalents in [[centralized database]] server architectures. There are lock, remote data transfer and query agent server processes. The distributed architecture helps make Objectivity/DB inherently [[scalability|scalable]]<ref name="georgeTown">
{{
cite web
Line 25 ⟶ 23:
|accessdate= December 1, 2014
}}
</ref> and [[reliability (engineering)|reliable]]. It has sustained ingest rates in excess of one terabyte per hour while simultaneously supporting data fusion and query operations.<ref name="panasasPaper">
{{
cite web
Line 38 ⟶ 35:
Objectivity/DB uses a distributed storage hierarchy. Objects are stored in logical clusters called containers. The containers are stored in databases that are cataloged in a [[federated database]]. Every object has a unique 64-bit Object Identifier (OID) that is a composite logical structure. The physical address space limitation for a single federation is in the millions of Terabytes range. The largest publicized Objectivity/DB installation, at SLAC's [[BaBar experiment]], stored over a Petabyte of objects.<ref>[http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/proceedings/CIDR05.pdf Lessons Learned from Managing a Petabyte] Jacek Becla and Daniel L. Wang, 2005</ref><ref>[http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/ BaBar Database]</ref>
Objectivity/DB provides a flexible approach for defining how objects are placed within a given storage hierarchy.<ref name="placement">
{{
cite web
Line 51 ⟶ 47:
</ref> Database designers can define a custom placement strategy that is encapsulated in an XML configuration file and made available to the application. This strategy can define which persistent objects are stored together, which are distributed, and which are stored near designated objects.
Objects can be linked to other objects using named uni-directional or bi-directional links. The links can have a [[cardinality]] of 1:1, 1:many, many:1 or many:many and use the OIDs to speed up the navigation of networks of objects.<ref name="bloor">
{{
cite web
Line 62 ⟶ 57:
|accessdate= December 1, 2014
}}
</ref> The OIDs are also used in support of scalable collections (tree, list, set etc.), indices and [[hash table]]s. Eliminating the relational [[Join (SQL)|Join]] operations inherent in a relational database gives Objectivity/DB a performance advantage.<ref>
{{Citation
|author1=Suzanne W. Dietrich |author2=Susan D. Urban | year = 2011
Line 73 ⟶ 67:
| accessdate = December 3, 2014
}}
</ref><ref>
{{Citation
|editor1=Alan Dearle |editor2=Roberto V. Zicari | year = 2010
Line 84 ⟶ 77:
| accessdate = December 3, 2014
}}
</ref><ref>
{{Citation
| author = C.S.R Prabhu
Line 102 ⟶ 94:
Databases and system data (catalogs and [[Database schema|schema]]) can be replicated to multiple locations using a quorum based synchronous replication mechanism. Replicas that are temporarily separated from the quorum are transparently resynchronized when they are reconnected to the network that services them and their peers. Individual databases and lock servers can be allocated votes that are used to determine whether or not a client can update a replica.
The distributed database and processing architecture of Objectivity/DB has allowed it to be used in many [[grid computing]] environments. It has attained certification as an IBM Ready For Grid product. It is also used in [[Service Oriented Architecture]] applications. Objectivity For Java has support for the [[J2EE Connector Architecture]] (JCA) standard. The distributed architecture of Objectivity/DB is equally applicable to cloud environments.<ref name="cloudReady">
{{
cite web
| |||