The guarantee that every transaction includes atomicity, consistency, isolation, and durability.
The guarantee that each transaction is treated as a single block of work, which either succeeds or fails in its entirety.
A class is a group of data categorized within a database. Data within a class usually has a common structure, but this is not required. If you’re familiar with traditional databases, you can think of a class as a table without a structured schema.
The promise that any data written to the database must be valid according to all defined rules, such as unique indexes.
Databases are containers for data with access control. In FaunaDB’s multitenant system, databases can be hierarchical, with multiple child databases nested within series of parent databases, each with their own permissions and security settings.
Durability guarantees that once a transaction has been committed, it is permanent. If a system crash, power failure, or other unexpected failure occurs, all transaction with committed data will be saved.
FaunaDB is globally, horizontally scalable because it allows each FaunaDB node to perform the same role as any other FaunaDB node, with nodes that can be distributed around the world. With each node able to serve any role, there is no single point of failure.
Granular identity management, authentication, and access control built on top of an enterprise-class, multitenant foundation provides a secure platform for companies of all sizes. FaunaDB has both administrative and application-level identity and security to provide a layer of separation between applications and administration. This provides the application developers more time to focus on building their applications without having to spend time securing the overall datastore.
An index is a database entity that facilitates data lookups. Indexes are used to quickly locate data without having to search every individual instance (or row) of data in the database.
Instances are single, changeable records within a FaunaDB database. Because they are changeable, they can have more than one version over time as they are updated by an application. If you’re familiar with other database systems, you can think of an instance as a row, record, or document.
The ability to have a single Fauna cluster provide individual databases to multiple tenants (e.g., companies, applications, programmers, and/or users) in isolation. Each tenant has complete administrative control, a private security model, and programmatic creativity over their own database/s, free from interference from users of other databases in the cluster.
Every record in a FaunaDB database is stored as an object. All instances are objects, but you can have objects that are not instances.
Every object in the database has an identifier called a reference or ref for short. An objects’s ref encodes its class along with a unique id, and is therefore unique to that instance within the scope of the database in which it is stored.
FaunaDB’s quality-of-service management means that, in a saturated cluster where resources are reaching critical capacity, each tenant will receive scheduling proportional to their configured priority. For example, in a saturated cluster with two tenants of priority 500 and 250, the first tenant will get 2/3 of the resources and the other will get 1/3 of the resources. This prevents a single greedy user from significantly impacting other users.
A set is a sorted group of immutable data from a class. Object data is mapped onto a set, and as objects are created, modified, and deleted, the set is updated. Sets provide a relational view of the data within your class, such as all the X that are Y.
In FaunaDB, instances of data are temporal, meaning each event is assigned a transaction timestamp and inserted into the instance history. Approaching instances temporally allows event sourcing, reactive programming, and various audit and stream-oriented data architectures that help the system "just work". Unlike older NoSQL systems, no additional configuration is needed to get your datastore playing nicely with your incoming and outgoing data.
To prepare for unexpected failures, all transaction data received by a log node is written to non-volatile storage for recovery of a replica. The transaction data is written in the order received to optimize for fast writes.
Was this article helpful?
We're sorry to hear that.
Tell us how we can improve! firstname.lastname@example.org
Thank you for your feedback!