Migrating to ApertureDB from a relational database
In a relational database (e.g. SQL-based), the schema is defined by the creation of tables, where each table has named columns. Some columns are “foreign keys” that form links between different rows, often in different tables. Columns have types and can have other constraints. Blobs are stored in columns.
Classes instead of tables
In a multi-modal graph database like ApertureDB, things are a little different. Instead of tables, there are object classes. Many rich media types such as videos, images, and descriptors (embeddings) have specific support and have built-in classes. Other types of object can be defined as separate entity classes. Note here that one SQL table may end up as multiple classes if the table includes multiple blob columns.
Connections instead of foreign keys
Instead of foreign keys to provide a one-way link between tables, ApertureDB has connections. This is similar to an “edge table” in SQL. Like entities, every connection has a named class.
Properties instead of columns
Both objects and connections can have metadata properties which correspond to the columns in a SQL database. The type system is simplified, e.g. “String”, “Number”, “Datetime”. Typically the client does not specify types explicitly, but they are inferred from the values given.
Schema is implicit instead of explicit
One big difference between setting up ApertureDB and a SQL database is that in ApertureDB, the schema is inferred. Simply by creating entities of a specific type, that class now exists. Simply by adding named properties with specific values, that class now has typed properties. There is no equivalent of a CREATE TABLE or UPDATE TABLE command.
Note that, although the schema is inferred, it is also enforced, so a client cannot add the same property to objects of the same class with different types.
Indexing
In a SQL database, a lot of time is spent optimizing the indexes. Many indexes are on a single column, but it is also possible to set up complex indexes across multiple columns.
In ApertureDB, we have found that most of the benefit can be obtained from single-property indexes. These can be created using:
- The CreateIndex command
- The Utils.create_entity_index() and Utils.create_connection_index methods
Connections are implicitly indexed. Descriptors have special indexing that supports ”find similar” search.
Extracting the schema
Once an ApertureDB database has been set up, the schema can be obtained in a number of ways:
- The GetSchema command
- The Utils.get_schema() method
- The
adb utils execute summarycommand line tool that outputs a human-readable description of the schema - The
adb utils visualize-schemathat generates an image visualization of the schema, similar to what is seen in may SQL tools
Unlike a typical SQL schema, our schema will include counts for all classes and properties, and whether each property is indexed. For more information on the schema, see our howto guide.
Query language
The ApertureDB query language is very different from SQL. It is JSON-based and is composed of a sequence of commands executed in order. Commands that find objects or connections can return a list of results, but they can also assign those results to a reference to be used by a subsequent command. In this way, the commands in a query form a pipeline.
The query language is described in detail in our Query Language Reference.