InfinityDB Database Engine Features
InfinityDB is, among many possible applications, appropriate for:
- Memory- or disk-constrained embedded hardware platforms such
- J2EE application servers running Servlets/JSP in conjunction with RDBMS
as additional special-purpose storage
- Text indexing engines or file indexes and other space-critical applications
- Application Configuration
- Heterogenous data environments
- Dynamic schemas, requiring flexible runtime adaptation,
and easy backwards compatibility with existing databases
- Standalone applications that cannot afford the overhead and
management of RDBMS
- Portable databases in a single file rather than a directory of files
- Flexible semantic structures (an 'Entity-Attribute-Value' model)
- Maximum speed low-level direct engine access
- Heavily multi-threaded data sharing
- Object persistence
- Data loss avoidance
- Transactional 'ACID' data storage in multi-threaded environments
InfinityDB has these main features described below. For an
explanation of the technology (not including the InfinityDB 2.0
ACID transactionality), see
- High Performance
- Basic operations orders of magnitude faster than SQL when
data is in the cache, as in small db's or localized access.
Most in-cache retrievals achieve 60 to 100 KOperations/second/GHz
and modifications are about half as fast. Out-of-cache I/O is typical.
- Direct access in Java without SQL creation, variable binding,
connection turnaround, parsing, and query optimization.
- On-disk stuctural integrity preservation system
survives process failure
- No internally-generated Exceptions are thrown except
on media failure,
- No internal deadlocks can occur, no deadlock Exceptions are
ever thrown. Optimistic Locks can throw conflict exceptions, however.
- No internal resource limitations require tuning or cause
- Free space in the file does not leak, even for long-running
applications, and space efficiency remains high
- Basic API is very simple.
- A simple 'Map-based' interface can be used to hide the lower 'engine' API.
- No fixed one-table result set concept
- Navigation can be hierarchical, bidirectional sequential, random
- View is dynamic, i.e. shows current db state
- No tuning
- No dependence on outside libraries
- True WORA portability, no dependence on SQL dialect or native libraries
- Completely Thread-safe, with good concurrency
- Threads needing data from disk do not block Threads
needing data from the cache
- No internal inter-Thread blocking can occur,
all operations complete
- Used in Servlet and custom high-performance Server
environments, as well as Threaded client applications. Appropriate
for soft realtime systems
- Data Loading or other bulk operations (the InfinityDB 1.0 'ACD' transactions)
- There is one global transaction in progress at all times.
- Global atomic durable commit with optional application rollback
- No limit on data loading transaction data size, no performance
penalty for large transactions
- No log is used, so no log rotation, size monitoring,
or space limitations arise
- No limit to Thread count - a thousand is practical and typical
- ACID Transactions in InfinityDB 2.0
- Concurrent transactions isolated by optimistic locks
- Transaction count and size and lock count and size limited only by memory.
- Workset and lock sets efficiently stored packed in memory,
no inefficient block-level locking.
- Table, row, value, and index range lock granularity (these
terms are not strictly applicable to the InfinityDB data model,
- SERIALIZABLE and READ_COMMITTED transaction isolation modes,
- Non-wait-for-durable high-speed commit mode,
- No log.
- Concurrent with 'ACD' bulk operations,
- No limit to Thread count - hundreds are practical and typical,
- Space Efficiency
- On-disk data compression takes advantage of compressible data.
- Common-prefixes in Keys are removed
- Common 'substrings' in any kind of data are compressed by ZLib
- UTF-16, ASCII or other small values compressed by ZLib's Huffman coding
- Common suffixes in upper tree levels removed
- Variable-length keys and data, no padding
- Java primitives are encoded variable-length, with common values shortened
- Tree blocks are stored variable-length on disk, reducing
block-internal free space
- Compression ratios 1 to 10 times are common over input data
(see tests in trial download).
- Efficiency can be commonly orders of magnitude better than competition
- Used in text search engines to compress large databases as well as in
memory-constrained small embedded systems
InfinityDB is not for all data storage applications. However, the necessary
capabilities missing from InfinityDB at the basic
level can almost always be provided by upper layers in any
given situation. This approach
is appropriate for an embedded database where the required total
feature set is fixed and customized. InfinityDB
provides an increasing library of application
modules to assist in customization, but its focus
is on the engine layer. Specifically, the InfinityDB
engine itself does not currently provide:
Some of the above features may be targets for future
- A log (hence there is no slow power-up recovery phase).
- SQL or JDBC
- User accounts or security
- Connection-based remote access
- Metadata. Schema is implicit or maintained by upper layers
- Disk or file spanning
- Space quotas and space management.
Copyright © 1997-2006