Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Download a PDF version of this Article

Learning Center Home

Table of contents:

Objectivity/DB - Flexible Deployment

• Introduction
• Single Logical View
• Simple Distributed Servers
• Replaceable Components
• Configuration Parameters
• Processor Power
• Data Locality
• Input/Output Capabilities
• Network Bandwidth
• Concurrency
• Caching
• Data Usage Dynamics
• System Latency
• Fault Tolerance
• Geography/Mobility
• Security
• Configuration Examples

Caching

Accessing data that is in RAM takes as little as 60 nanoseconds. Reading the same data from disk takes at least 3.5 milliseconds, which is roughly 60,000 times slower. Likewise, transmitting 8 KB of data across a 100 Mb network connection takes about a millisecond, so caching the data in RAM is useful for avoiding both disk and network delays.

Modern operating systems and I/O infrastructure generally cache data on its way to and from disk. Objectivity/DB also has its own smart client-side cache for reducing network traffic and local disk reads and writes. It will cache unchanged data across transactions, removing the need to do anything other than obtain the correct locks.

Each client thread or process can initialize and use its own cache. Each thread can set the initial size, growth rate and upper bound (which should always be less than the amount of available RAM). Clients that are streaming data will generally use small caches so that data is transferred to or from disk as rapidly as possible. Data ingest processes want the data to flow straight to disk, so they want to avoid queuing a lot of data in RAM until the commit operation occurs and flushes it to disk. Clients that need to lookup a large body of reference data will probably require very large caches.

Careful direction of incoming requests to service threads with their own cache of reference material, e.g. one per telephone area code, can minimize the number of I/Os required to lookup reference data. Figure 9 (below) shows an application using multiple cache sizes and dynamics

In some I/O subsystems, particularly when data is being ingested to disk rapidly, it may be better to turn off the operating system or hardware caches for the same reason that small caches work better in Objectivity/DB itself when data is being streamed.

The data servers (called Advanced Multithreaded Servers, abbr. AMS) use the underlying operating system or hardware caches by default. However, there is a replaceable component, the Objectivity Open File System [OOFS] that can be modified to provide alternative read/write cache dynamics. Figure 10 (below) shows the AMS subsystems. OOFS can be modified to provide different caching behaviors, such as:

• Discarding pages on a Least Frequently Used basis, rather than Least Recently Used.
• Read ahead caching, which allows the data server to fetch pages ahead of the client request for the next page in a sequence.
• “Retain until read” behavior, which keeps newly written pages in the cache until one or a preset number of read requests are received. This is useful in conjunction with the Parallel Query Engine