Glossary

Sources provide connectivity to systems that Drasi observes for changes. They process change logs from databases and other systems, translate data into a consistent property graph model, and push changes to subscribed Continuous Queries. Sources handle both real-time change streaming and initial data loading for query bootstrapping.

Continuous Queries are queries that run perpetually, maintaining an accurate result set that updates automatically as source data changes. Unlike traditional queries that return a point-in-time snapshot, Continuous Queries detect exactly which results have been added, updated, or deleted and distribute these changes to subscribed Reactions. They are written in Cypher or GQL and can span data from multiple Sources.

Reactions process the stream of query result changes output by Continuous Queries and take action. Actions depend on the Reaction type and can include forwarding changes to Azure Event Grid, SignalR, or AWS EventBridge; executing stored procedures; updating databases; or triggering custom application logic. Multiple Reactions can subscribe to the same Continuous Query.

Query Containers are the runtime environments that host Continuous Queries. They manage query execution, maintain query state, and handle the processing of source changes. A single Query Container can host multiple queries and can be scaled independently. Each container provides storage profiles for configuring how query indexes are stored.

Change Data Capture (CDC) is a set of technologies and patterns for identifying and capturing changes made to data in a database. Drasi leverages CDC to monitor source systems for inserts, updates, and deletes. Drasi’s source input schema is modeled on Debezium, an open-source CDC platform, enabling integration with many existing Debezium sources.

The result set is the collection of records that currently satisfy a Continuous Query’s criteria. Unlike traditional query results that are static snapshots, Drasi result sets are dynamic—they update automatically as source data changes. Changes to the result set are expressed as added, updated, and deleted records, which are distributed to Reactions.

Bootstrap is the initialization process when a Continuous Query starts. During bootstrap, the query loads its initial state by querying the source systems for current data. This ensures the query result is accurate from the start, before processing the ongoing stream of changes. Storage profiles can affect bootstrap performance for queries with large initial result sets.

An instantaneous query is a traditional database query that executes once and returns results representing the data at that specific point in time. After execution, the results are static and do not reflect subsequent changes. To detect changes, you must re-run the query and compare results. Drasi’s Continuous Queries solve this limitation by maintaining a perpetually current result set.

openCypher is a declarative graph query language originally developed for Neo4j. In Drasi, openCypher is one option for writing Continuous Queries. Its pattern-matching syntax makes it easy to describe complex relationships between data elements and specify which changes to detect. openCypher queries use MATCH, WHERE, and RETURN clauses to define patterns, filters, and output schemas.

GQL (Graph Query Language) is an ISO-standard query language for property graphs. Drasi supports GQL as an alternative to openCypher for writing Continuous Queries. GQL provides similar pattern-matching capabilities with standardized syntax. You can specify the query language in the Continuous Query configuration using the queryLanguage property.

In Drasi’s property graph model, a node represents a discrete entity such as a person, product, location, or event. Nodes have labels (types) and properties (key-value pairs). Sources transform data from various formats into nodes that Continuous Queries can process. In Cypher queries, nodes are represented in parentheses: (n:Label).

Relationships (also called relations or edges) connect nodes in Drasi’s property graph model. They have a type, direction, and can contain properties. Relationships enable Continuous Queries to traverse connections between data elements. In Cypher, relationships are written with square brackets: -[:RELATES_TO]->. Sources can define relationships explicitly or they can be created synthetically via joins.

The property graph model is the data representation used internally by Drasi. In this model, data consists of nodes (entities) connected by relationships, where both can have properties (key-value pairs). Sources translate data from various formats (relational, document, etc.) into this unified model, enabling consistent querying across different source types.

The Drasi CLI is the primary tool for interacting with Drasi. It provides commands for installing Drasi (drasi init), managing resources (drasi apply, drasi delete, drasi list), viewing logs (drasi logs), and debugging queries (drasi describe). The CLI works with YAML resource definitions stored in your solution repository.

Resource definitions are YAML files that declare Drasi resources. Each definition includes an apiVersion, kind (Source, ContinuousQuery, or Reaction), name, and spec containing configuration details. Definitions can be version-controlled alongside application code and applied using the drasi apply command.

Storage profiles define how Drasi stores Continuous Query element and solution indexes. The default Query Container provides ‘memory’ and ‘redis’ profiles. Memory-based storage is suitable for testing and queries without significant bootstrap requirements. Redis provides persistent storage for production workloads. The profile is specified in the Continuous Query’s storageProfile property.

Middleware enables custom logic to be executed on incoming source changes before they are processed by a Continuous Query. Middleware configurations are defined in the query spec and can be chained in a pipeline for each source subscription. This allows transformation, filtering, or enrichment of change data.

Joins in Drasi create mappings between nodes from different Sources based on property values. This enables Continuous Queries to traverse relationships across source boundaries as if querying a unified graph. Joins are defined in the query’s spec.sources.joins section by specifying label and property pairs that should match.

Debezium is an open-source distributed platform for Change Data Capture. Drasi’s source input schema is modeled on Debezium’s format, enabling compatibility with Debezium’s ecosystem of database connectors. This design choice allows Drasi to integrate with many existing data sources through the well-established Debezium standard.

drasi.changeDateTime() is a built-in Drasi function used in Continuous Queries to access the timestamp of when a data change occurred in the source system. This enables time-based logic and auditing within queries.

drasi.trueDuring() is a temporal function in Drasi that evaluates whether a condition holds true during a specified time period. It enables Continuous Queries to implement time-window logic and detect patterns that occur over durations rather than at single points in time.

drasi.linearInterpolate() is a function that calculates intermediate values between known data points using linear interpolation. This is useful in Continuous Queries that need to estimate values at specific times when only periodic samples are available, common in IoT and sensor data scenarios.

Drasi Server is one of three deployment options for Drasi. It runs as a standalone server process or Docker container, suitable for development, testing, or simpler production deployments.

Drasi for Kubernetes is the deployment option for Drasi, running on Kubernetes clusters. It provides horizontal scaling, high availability, and integration with Kubernetes-native tooling. Drasi for Kubernetes is ideal for enterprise deployments requiring robust operational capabilities.

drasi-lib is a Rust crate that enables developers to embed Drasi’s Data Change Processing capabilities directly into Rust applications. It provides the same Continuous Query functionality without requiring a separate Drasi server, making it ideal for embedded systems or applications where minimal dependencies are preferred.

Data Change Processing is the core capability that Drasi provides. It involves continuously monitoring data sources for changes, evaluating those changes against Continuous Queries to identify meaningful patterns, and distributing detected changes to downstream systems through Reactions. Unlike traditional batch processing, Data Change Processing operates in real-time as changes occur.

A Source Change Event is the internal representation of a data change detected by a Source. It contains the type of change (insert, update, or delete), the affected data in property graph format, and metadata such as timestamps. Sources emit these events when underlying data changes, which are then processed by subscribed Continuous Queries.

A Result Change Event is emitted by a Continuous Query when its result set changes. It describes which results have been added, updated, or deleted as a consequence of Source data changes. Reactions subscribe to these events to take action when query results change. The event includes the query ID, sequence number, and the specific result changes.

A Source Subscription defines which Sources a Continuous Query receives Source Change Events from. Subscriptions are configured in the query’s spec.sources section and can include middleware pipelines for transforming or filtering incoming changes. A single query can subscribe to multiple Sources, enabling cross-source queries.

A Source Join is a connection between nodes that is defined by join conditions in a Continuous Query rather than existing explicitly in source data. This enables queries to traverse relationships across different Sources or create logical connections based on matching property values. Synthetic relationships are configured in the query’s spec.sources.joins section.