InfinityDB Database Engine Features

• Applications
• Features
• Non-features

Applications

• Memory- or disk-constrained embedded hardware platforms such as system-on-a-chip
• 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

Features

• 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.
• Reliability
  • 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 failures
  • Free space in the file does not leak, even for long-running applications, and space efficiency remains high
• Simplicity
  • 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
  • Single-File
  • No tuning
  • No dependence on outside libraries
  • True WORA portability, no dependence on SQL dialect or native libraries
• Multi-Threading
  • 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
• Transactionality
  • 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, however).
    • 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

Non-Features

• 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.

Previous Next