Object Oriented Databases Single, Consistent View of Data
Single, Consistent View of Data: Another fundamental benefit of a database management system is providing a single, consistent view of data. A natural inference from this is that the data is centralized, but this isn’t necessarily a requirement and often it’s undesirable. Centralization leads to bottlenecks and single points of failure.
SQL databases are by nature centralized because the query engine tends to be centralized. This is depicted in Figure 7. Joins between tables are already inefficient. Separating data across a network or other slower connection aggravates the cost of joins. Without flexible clustering, it’s difficult for a SQL database to split tables across multiple servers in an efficient way.
Objectivity/DB OIDs provide a natural ability to easily distribute a federation’s data across servers, clients or any data storage accessible to clients. As described in the section titled Persistence, the first 16 bits of the OID map to the database of the object. Each database is represented by a single file.
When Objectivity/DB fetches an object based on its OID, it first looks up the database file in a database catalog using that 16-bit number. This is a very fast operation, since the database list is generally not very volatile and will easily fit in a client’s cache. To move data from one server to another or even to a client, all one has to do is run an Objectivity/DB utility called oochangedb. No application code must be changed.
The oochangedb utility simply moves the database file to the new location and updates the database catalog. Each client discovers that the catalog has changed and refreshes the list.
Once the database of the desired object(s) has been located, the file is opened and the specific pages are found by finding the container offset, looking up the physical page in the page map and fetching the page(s) by reading from the file.
If the page has been read from a different architecture than the client, the appropriate conversion (endian, byte-swapping, etc) is done in the client’s memory.
Objectivity/DB therefore supports the centralized client-server architecture, and many Objectivity/DB customers choose centralization because it fits the application.
Objectivity/DB also supports many distribution models that can greatly improve the performance and availability of data in the federation.
Common examples are:
Easily adding servers without federation downtime to increase performance using parallel processing.
Since Objectivity/DB supports server heterogeneity, new servers can be purchased by choosing the best value at the time. Original hardware investments are not lost, nor do the original investments bind the system to any specific vendors.
Moving local data to local machines to reduce network traffic and increase performance of providing that data to the local clients.
Often objects are placed into databases according to locality (geography, for example). This means that Denver’s data can be stored in a database hosted in Denver and San Francisco’s data can be stored in a database hosted in San Francisco.
San Francisco can still read Denver’s data and vice versa, but San Francisco does not have to communicate over a wide area network to access its own data.
The lock server maintains the consistent view across the federation, including concurrency control and integrity of transactions. In order to decentralize the lock server, Objectivity/DB also provides a “Fault Tolerance Option” that allows separate lock servers to manage groups of databases.
Figure 8 shows an example of a somewhat distributed architecture. Most of the data is stored on a dual-server system, so it’s still basically a clientserver architecture. Two workstations, however, have local databases. If these clients request objects located in these databases, the access can be provided directly.
Objectivity/DB also provides a “Data Replication Option” that allows database images to be replicated as many times as necessary. Consequently, one or more clients can have a copy of a database that’s on the server. This obviously has large performance advantages for fairly static databases that have data that’s shared across multiple clients.
Objectivity/DB ’s distribution model can even be taken to the point where there is essentially no single server at all, as shown in Figure 9. This is a pure “pier-to-pier” distribution model - any client can access any other client’s data. Again, either a single or multiple lock servers will enforce consistency, concurrency control and transaction integrity of the federation.