Skip to content
A record-oriented store built on FoundationDB
Branch: master
Clone or download
Latest commit 31c85b0 Mar 18, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.idea Resolves #249: Collating index (#307) Feb 11, 2019
build
docs
examples
fdb-extensions
fdb-record-layer-core-shaded
fdb-record-layer-core Merge pull request #424 from nschiefer/planner-multi-field-indexes Mar 15, 2019
fdb-record-layer-icu
gradle
.gitignore
ACKNOWLEDGEMENTS Resolves #249: Collating index (#307) Feb 11, 2019
CODE_OF_CONDUCT.md initial repository commit Oct 10, 2018
CONTRIBUTING.md added a script that is run at release time to regenerate the release … Jan 19, 2019
LICENSE
README.md
build.gradle Resolves #85: Create a validator to check if a new meta-data is a val… Feb 15, 2019
build.py
gradle.properties
gradlew initial repository commit Oct 10, 2018
gradlew.bat
settings.gradle

README.md

FoundationDB Record Layer

The Record Layer is a Java API providing a record-oriented store on top of FoundationDB, (very) roughly equivalent to a simple relational database, featuring:

  • Structured types - Records are defined and stored in terms of protobuf messages.
  • Indexes - The Record Layer supports a variety of different index types including value indexes (the kind provided by most databases), rank indexes, and aggregate indexes. Indexes and primary keys can be defined either via protobuf options or programmatically.
  • Complex types - Support for complex types, such as lists and nested records, including the ability to define indexes against such nested structures.
  • Queries - The Record Layer does not provide a query language, however it provides query APIs with the ability to scan, filter, and sort across one or more record types, and a query planner capable of automatic selection of indexes.
  • Many record stores, shared schema - The Record Layer provides the the ability to support many discrete record store instances, all with a shared (and evolving) schema. For example, rather than modeling a single database in which to store all users' data, each user can be given their own record store, perhaps sharded across different FDB cluster instances.
  • Very light weight - The Record layer is designed to be used in a large, distributed, stateless environment. The time between opening a store and the first query is intended to be measured in milliseconds.
  • Extensible - New index types and custom index key expressions may be dynamically incorporated into a record store.

The Record Layer may be used directly or provides an excellent foundational layer on which more complex systems can be constructed.

Documentation

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.