Maximum Control Low TCO |
Use a database that gives you total control. Learn more…
The FairCom benchmarking team achieved these results on one Dell R840 server with 72 cores, 768 GB RAM and 25.6 TB of NVMe SSD.
The test inserts billions of records in parallel across 70 sharded tables. Each table uses fixed-length records, has no indexes and no transaction processing.
This reference application demonstrates how you can use FairCom DB to control every aspect of the insert process. It uses the following features to configure the database for maximum insert performance:
FairCom DB is an advanced database engine that gives you ultimate control to achieve unprecedented performance with the lowest total cost of ownership (TCO).
FairCom DB delivers predictable high-velocity transactions and massively parallel big data analytics. It empowers developers with NoSQL APIs for processing binary data at machine speed and ANSI SQL for easy queries and analytics over the same binary data.
You do not conform to FairCom DB…FairCom DB conforms to you.
With FairCom DB, you are not forced to conform your needs to meet the limitations of the database. You can conform FairCom DB to meet your business needs, giving you the database you need to meet your core-business needs — fast, reliably and efficiently.
c-treeACE is now FairCom DB |
a few of our key customers |
Try it Now!FairCom DB V12 |
Run FairCom DB anywhere & everywhere |
NAV API OverviewFairCom’s NAV API gives your application an unprecedented level of control over every database action. NAV allows your favorite programming language to “remote control” the database. It can find any record (or a subset of records), move to next and previous records in index or data order, join to specific records in other tables, choose which records to lock, which records to include in a transaction, and which records to retrieve, insert, update, and delete. NAV allows you to save the position of records and immediately jump back to those positions to retrieve records without index lookup. You can run SQL simultaneously with any NAV operation. This gives your application the best of both worlds. SQL solves easy problems with little code. NAV solves hard problems with little code by leveraging the full capabilities of mainstream programming languages, such as Java, C#, C++, Python, and Javascript. NAV extends these languages to control the database with a small amount of simple code. NAV provides unprecedented speed because your application uses the ideal algorithm to make the database do exactly what needs to be done and no more. |
Use NAV to create an algorithm to process your data exactly the way you want with total control for extreme performance and efficiency. You can use any algorithm – including hundreds of existing graph algorithms. NAV also gives you automatic behaviors that make writing code easy and intuitive.
Use NAV to navigate from record to record and table to table using a wide variety of techniques, such as:
Use NAV to save and restore multiple record positions to instantly retrieve records or move a cursor to any record – without index lookups. With NAV, record positions can be immutable, making them safe to store inside records as “pointers” to other records. This makes graph traversal easy and fast.
Use NAV to control if and how a record gets locked automatically or manually. You can combine automatic and manual locks for ease of use and total control. For locking records manually, you can use read, write, blocking, non-blocking, and exclusive locks. For automatically locking records while your application navigates records, use session lock modes, such as no locks, read-only locks, read-write locks, blocking locks, non-blocking locks, etc. You can suspend and resume automatic locking at any time and easily release all or some locks created by your session. You have the ability to freely intermingle SQL and NAV because locks are compatible across both.
With NAV you have the ability to create all-or-nothing, isolated transactions that span multiple operations across many records, such as removing an amount from a debit record and adding it to a credit record. You can control when transactions begin, end, are nested, and whether specific records participate in a transaction. NAV allows you to create save points along the way and roll back to them as desired. NAV’s automatic transactions make ACID-compliant navigation easy, and NAV’s manual transactions provide total control to achieve extreme performance and any degree of consistency from eventually consistent to ACID compliance. You can also freely intermingle SQL and NAV because transactions are compatible across both.
No need to go alone.
The highly rated FairCom Support and Professional Services teams are here 24/7/365.
FairCom DB does not limit you to one cluster topology. FairCom DB’s built-in Replication Manager makes it easy to mix and match data replication and failover to create any cluster topology you need for horizontal scalability and high availability.
Implement any cluster scenario including:
Control replication at all levels from individual data files to entire databases. Publish data once and subscribe to a publication many times across many servers. Don’t worry about performance because FairCom Replication uses multiple threads to continuously stream all changes at high speed, and it runs outside the database process to ensure database performance is not impacted.
Replication options:
Automatic failover options:
A browser-based graphical user interface, called Replication Manager, runs in a central location to configure, manage and monitor data replication across hundreds of servers and thousands of tables and files. FairCom Replication can also be automated through a JSON/HTTP web service API and a C/C++ API.
|
The left side of each continuum is "Total Control" - which describes uniquely useful capabilities of the FairCom Database. The right side is "Traditional Control" where the FairCom Database operates like a SQL database. In between are multiple levels of control.
You choose your ideal level of control within and between continuums.
TRY IT FOR YOURSELFExplore How FairCom DB Can Achieve Your Goals |
Simultaneously use the full range of FairCom DB consistency options from 100% ACID compliant to eventually consistent.
There are four aspects of consistency: Atomicity, Transaction Consistency, Isolation and Durability.
The next four continuums of control illustrate how you can customize consistency of each database and each table to meet the precise needs of your application.
ConsistencyFairCom DB provides a Continuum of Control over consistency to allow each type of record to meet required trade-offs between performance, capability and consistency. ACID Consistency ensures, that at a single point in time, the same piece of data always has the same value when it occurs in multiple shards, tables, indexes and queries. Eventual Consistency allows the same piece of data to be different wherever it occurs while eventually making it the same. Partial consistency lies in between. FairCom DB allows each type of record to have the precise type of consistency it needs. ![]() ![]() ![]() Eventual ConsistencyMaximum speed… ![]() Eventual ConsistencyEventual Consistency allows the same piece of data to be different across multiple shards, tables, indexes and queries. The data eventually becomes consistent. All aspects of the database perform faster because they do not have the overhead of point-in-time consistency. Eventual Consistency requires a developer to deal with additional challenges:
FairCom DB gives you full control over Eventual Consistency to reap its benefits and deal with its challenges.
![]() ![]() Custom ConsistencyPer table consistency… ![]() Custom ConsistencyFairCom DB allows you to control the consistency of each table: whether it is Eventually Consistent, ACID Consistent, Preimage ACID Consistent, Not Consistent, or Temporarily Consistent. A Continuum of Control over consistency is vital for all applications. Each type of record (i.e. table or data file) has different requirements for performance, capabilities and consistency. Per table, you can implement Eventual Consistency by turning on transaction logging, asynchronous bidirectional replication and manual locking. Eventual Consistency works best when global availability and scalability are most important. Per table, you can implement ACID Consistency by turning on transaction processing and automatic locking. ACID Consistency works best when data consistency, query isolation and all-or-nothing transactions are most important, such as banking transactions, precise control of mission-critical data, concurrent updates without conflicts, etc. Per table, you can implement Preimage ACID Consistency by turning on Preimage transactions and Direct IO. The table has all ACID capabilities without transaction logs, which greatly increases write performance. It works best for collecting high-velocity data for real-time analytics, gaming leaderboards, stock market transactions, etc. Per table, you can implement No Consistency by not using transaction logging and locking. This greatly increases write performance, but it decreases durability and disables atomicity and isolation. No Consistency works best for locally cached data, temporary tables, bulk-loading data into a data warehouse, collecting data from many devices, etc. Per table, you can implement Temporary Consistency by temporarily disabling transactions on a table created with transaction logging. This allows the table to perform data operations at exceptional velocity. Manual locking is a Continuum of Control by itself. It is available in all consistency models. Through the NoSQL APIs, you can use read and write locks as desired to create any level of consistency and isolation. Tables without transaction logging, such as the last three consistency examples, have much faster write performance because data is written only once, but they have limited durability and capabilities. They cannot participate in point-in-time backups, restores, audits, data replication and high-availability clustering. ![]() ![]() Index ConsistencyPer index consistency… ![]() Index ConsistencyDuring ACID-compliant transactions, each index added to a table further slows inserts, updates and deletes because all indexes must be updated before a transaction can commit. FairCom DB provides two types of index consistency: normal and deferred.
Deferred indexing introduces inconsistency between data in a table and its indexes. Index data quickly catches up to the table data, but until it catches up, queries return inconsistent results. Deferred indexes work well for several use cases:
![]() ![]() Multi-server ConsistencyConsistency across servers… ![]() Multi-server ConsistencyYou can use FairCom's two-phase transaction API to cause a transaction to span multiple database servers. This ensures all data in a transaction succeeds or fails on both servers with ACID compliance. ![]() ![]() ACID ConsistencyPoint-in-time consistency… ![]() ACID ConsistencyFairCom DB supports ACID Consistency on a per table basis. FairCom's SQL engine automatically creates and uses tables with ACID Consistency. FairCom's NoSQL APIs create and use tables using a continuum of options ranging from Eventually Consistent through ACID Consistent. This gives your application total control over the transactional design of each table. Regardless of a table's consistency model, FairCom's SQL and NoSQL APIs can process it simultaneously. This is a unique and powerful capability of FairCom DB. ACID Consistency requires:
In other words, all transacted data in the database transition from one state to the next according to the database's rules and according the ACID-compliant rules of atomicity, consistency, isolation and durability. FairCom's transaction engine implements transaction processing in a unique way that supports each table having a different Continuum of Control from ACID to Eventually Consistent.
In addition, transaction logging enables hot backups, point-in-time restores, transaction auditing, data replication, high availability and global scalability without impacting database performance. |
IsolationIsolation ensures your queries and transactions are not visible to other users and vice versa. You can control the isolation level of each database, table and row. ![]() ![]() ![]() No IsolationExceptional read speed… ![]() No IsolationNo Isolation is the default for FairCom's NoSQL APIs. This is one reason they are so fast. FairCom tables have slightly different isolation behaviors when they are created with transaction logging or not. Non-transaction tables provide no isolation by default.
Transaction tables provide isolation from uncommitted changes.
FairCom SQL provides a minimum of Read Committed isolation.
![]() ![]() Custom IsolationIsolate exactly as much as you want… ![]() Custom IsolationPerformance speeds up as isolation decreases. Thus, FairCom DB's NoSQL APIs default to no isolation for maximum performance, and they allow you to add locks as needed to create your desired level of isolation.
FairCom SQL supports two of the four SQL isolation levels:
SQL clients can specify either option per connection. Through configuration, FairCom DB can globally limit SQL isolation to Read Uncommitted only or both. SQL uses locks to enforce isolation to ensure the SQL and NoSQL APIs work seamlessly over the same data. ![]() ![]() SQL Read CommittedAutomatically isolate from uncommitted writes… ![]() SQL Read CommittedRead Committed is the default Isolation Level for SQL queries in FairCom DB. It ensures a SQL query sees no data changes made by concurrent users. It allows a query to see previous uncommitted data changes made by its own transaction. If the query is repeated in the same transaction, it will include committed transactions from other users who subsequently inserted, deleted or updated rows. It will never include uncommitted changes from other users. SQL uses locks to enforce isolation to ensure the SQL and NoSQL APIs work well together over the same data. Thus, when Read Committed Isolation is not fast enough for an operation, you can use the NoSQL APIs to control locks more precisely for maximal speed. Also, when you need more isolation, you can achieve the precise amount you want with the NoSQL APIs. SQL clients can specify Read Committed Isolation when they connect. Through configuration, FairCom DB can globally limit SQL Isolation to be Read Committed. Read Committed is the default Isolation Level for many SQL databases including SQL Server, Oracle, DB2, PostgreSQL, etc. ![]() ![]() SQL Repeatable ReadAutomatically isolate from new rows… ![]() SQL Repeatable ReadSQL Repeatable Read is an optional Isolation level for SQL queries in FairCom DB. It ensures a query sees no data changes made by concurrent users. It allows a query to see previous uncommitted data changes made by its own transaction. And unlike Read Committed Isolation, if the query is repeated in the same transaction, it will not include rows that were subsequently updated or deleted by concurrent users, but it will still include committed inserts from concurrent users. It will never include uncommitted changes from other users. SQL uses locks to enforce isolation to ensure the SQL and NoSQL APIs work well together over the same data. Thus, when Repeatable Read Isolation is not fast enough for an operation, you can use the NoSQL APIs to control locks more precisely for maximal speed. Also, when you need more isolation, you can achieve the precise amount you want with the NoSQL APIs. SQL clients can specify Repeatable Read Isolation when they connect. Through configuration, FairCom DB can globally limit SQL Isolation to be Repeatable Read. |
DurabilityDurability ensures your data is stored safely on persistent storage. FairCom DB gives you a Continuum of Control to achieve unprecedented performance and durability. ![]() ![]() ![]() In-memory DurabilityFastest storage, period… ![]() In-memory DurabilityIn-memory tables provide the fastest possible performance, and when you put them in non-volatile RAM, they provide full durability. You can optionally create them with preimage atomicity, consistency and isolation, which means they can fully participate in transactions with other tables without using transaction logs. They support all transaction features including all-or-nothing commits, rollbacks and savepoints. When they are persisted in non-volatile RAM, they become durable and are, thus, fully ACID compliant. They are useful for any table that can fit entirely in RAM. In-memory tables are not automatically backed up, but you can easily write their records into a table that can. In-memory transactions are not included in transaction logs, which means in-memory tables cannot participate in data replication, but they can be replicated using in-memory replication. More Information ![]() ![]() Delayed DurabilityFastest transaction IO… ![]() Delayed DurabilityYou can configure transaction logs to be cached by the operating system for up to 3x faster performance. This is called Delayed Durability. Without Delayed Durability, FairCom DB immediately flushes each committed transaction to the transaction logs. This ensures each committed transaction is physically on disk. With Delayed Durability, FairCom DB allows the operating system (OS) to cache transaction logs and eventually write them to disk. This greatly increases the speed of transactions, but if the OS or hardware fails before a transaction is flushed to disk, that transaction is lost and the transaction file may contain incomplete data. To mitigate the risk of losing transactions, you can do the following:
Delayed Durability is beneficial for applications that need maximum speed and the benefits of transactions while accepting the low risk of losing around one second's worth of records. ![]() ![]() Direct IOFastest non-transaction IO… ![]() Direct IO DurabilityWhen you turn off transaction logs, all databases have the potential to lose or corrupt data during an abnormal server termination because there is no transaction log to restore the data. With FairCom DB, this risk can be mitigated because most tables remain under transaction control while a few preimage and non-transaction tables use Direct IO for durable writes. FairCom DB is unique in that it provides different types of tables optimized for various levels of performance: transaction tables, in-memory tables, preimage tables and non-transaction tables. You can configure preimage and non-transaction tables to use Direct IO. This ensures data is written directly to storage, where it is protected from outages. Direct IO bypasses the operating system's asynchronous model of flushing cached data to storage and gives you direct control of when data is flushed to storage. You can configure data to flush immediately, flush every N seconds, flush every N bytes or flush on demand. Using FairCom's NoSQL API to flush data on demand is particularly useful. It allows you to persist critical data immediately after it is written, while allowing less-critical data to be cached and written periodically. This makes Direct IO fast and durable without transaction logs. Direct IO is the fastest form of IO when one process exclusively writes to a table – even while many concurrent processes read from it. In-memory, preimage and non-transaction tables are well suited for temporary tables, locally cached data, etc. For example, local in-memory tables can collect high-velocity data for real-time analytics and gaming leaderboards. Dedicated writer threads can rapidly persist the in-memory data into non-transaction tables that use Direct IO. Multiple reader threads can process these tables in parallel for high-speed machine learning. No other database can compete with this level of performance, which has been benchmarked at millions of inserts per second on a single server. ![]() ![]() Table MirroringDurable NVMe storage… ![]() Table MirroringFairCom DB can mirror the data of any table (except for in-memory tables) across two storage devices. If one device becomes unavailable, the database automatically uses the other. This increases the availability of the database and increases durability. You can also mirror FairCom DB's local control files, which include security, transaction logs and transaction start files. Using Table Mirroring for these files is essential to achieve high availability and high performance when local storage devices are not configured as RAID 10 arrays. You can use Table Mirroring to make local NVMe storage highly available. This is important because NVMe is the fastest form of storage outside of non-volatile RAM, and it is cost effective. But it is not highly available because it cannot participate in RAID arrays. You can also use mirroring to place copies of files on both local and remote storage for higher availability, but likely slower performance. Mirroring is as slow as the slowest storage device; so, it is important to mirror across similar storage devices. When you are not using NVMe devices or mirroring across local and remote storage, hardware accelerated RAID storage is preferable. ![]() ![]() ACID DurabilityUltimate durability… ![]() ACID DurabilityBy default, FairCom DB provides ACID Durability. Each transaction is committed to a transaction log that is immediately flushed to disk. Data is shortly thereafter written to table files. Periodically, the files are backed up. The data is durable because it is in multiple places: data files, transaction logs and backups. Backups and transaction logs can restore transactions to any point in time. FairCom DB provides many options to achieve exceptional speed and retain durability:
|
PLATFORM SUPPORT![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hardware and OSFairCom Database Engine runs on most hardware and operating systems.
|
Additional InformationWant to learn more about FairCom DB? Select a topic below for additional information. |
See what is new!FairCom DB |
c-treeACE lives on under a new name, FairCom DB. The same great technology you have come to expect from the FairCom c-tree product family with new improvements and a new name, FairCom DB. The upgrade to the new FairCom DB V12 from c-treeACE V11 or earlier versions of c-tree is as easy as ever.
To upgrade from c-treeACE, contact your FairCom account executive or contact us here.