How fast is Objectivity/DB? There are many ways of measuring the speed of a database. Unfortunately, almost all of them are only suitable for relational databases. The industry benchmarks on object databases are over ten years old. Objectivity/DB can create new objects and store them on disk at almost the maximum rate that the processor-network-disk configuration can support. In one recent benchmark Objectivity/DB ingested and stored objects at the rate of 32 Terabytes per day. It randomly or sequentially reads data at similar speeds. If a client thread can reuse data that has already been cached in memory then there is no need to read the data from disk (or across a network) in subsequent transactions. Objectivity/DB can be configured with small client caches for streaming data, or with large client caches for repetitive use of large amounts of data. In the latter case, Objectivity/DB effectively becomes an in-memory database. How much does Objectivity/DB slow down as my database grows? The time to store and directly access objects stays almost linear as the container, database and federated database sizes grow. Operations that need to scan whole containers, databases or the federation scale linearly. B-tree indices behave in a predictable fashion. However, note that applications can often utilize small, local indices or hash tables within containers or databases, rather than global indices across a whole federation. What happens if the number of clients increases? It depends on what they're doing. If they all have to share the same data then the disk holding that data will eventually saturate. It may be possible to replicate the data multiple times to share the load. If they are accessing data on different disks then there is little noticeable effect. Eventually, there may be too many clients for a particular lock server. That problem can be solved by allocating multiple lock servers. |
|||
 |
||||||||
|
||||||||
|
|