Schema

Schema defines the structure and configuration of interaction data in Actionbase. Before storing any data, you must define how your edges are structured, what properties they have, and how they can be queried.

For the conceptual foundation, see Core Concepts.

Schema Hierarchy

Actionbase organizes schemas in a hierarchical structure:

Service
├── Label (defines edge schema)
│   ├── Schema (source, target, properties)
│   ├── Indexes (for efficient querying)
│   └── Storage (physical storage)
└── Alias (alternative name for Label)

• A Service groups related Labels and Aliases
• A Label defines the complete schema for edges
• An Alias provides an alternative name for a Label
• A Label references a Storage for physical data storage

Service

A Service is a logical namespace that contains labels and aliases, providing organization and isolation for related graph structures.

Properties:

• name: Service identifier (e.g., myservice)
• desc: Description of the service
• active: Whether the service is active

Services group related labels together. For example, an e-commerce service might contain labels for likes, views, and purchases.

Label

A Label defines the complete schema for edges, specifying the structure of relationships including source and target types, properties, and indexes.

Properties:

• name: Label identifier in the format service.label
• schema: Defines the structure of edges
  • src: Source node type (e.g., user_id)
  • tgt: Target node type (e.g., product_id)
  • fields: List of edge properties
• indices: List of indexes for efficient querying
• storage: Storage name where data is stored
• dirType: Direction type (directed/undirected)
• active: Whether the label is active

Schema Definition

The schema property defines what data edges can contain:

• src: Source node type (STRING, LONG) - typically user_id
• tgt: Target node type (STRING, LONG) - typically product_id, content_id
• fields: List of properties, each with:
  • name: Property name
  • type: Data type (STRING, LONG, BOOLEAN, etc.)
  • nullable: Whether the property can be null
  • description: Property description

Example: Recent Views

source: user_id (LONG)
target: product_id (LONG)
properties:
  - created_at (LONG)

Example: Reactions

source: user_id (LONG)
target: product_id (LONG)
properties:
  - created_at (LONG)
  - reaction_type (STRING) - e.g., "heart", "care"

Index Definition

Indexes enable efficient querying. Each index:

• Has a unique name within the label
• Specifies a list of fields to index
• Each field has a sort order (ASC/DESC)

indexes:
  - name: by_created_at
    fields: [created_at DESC]
  - name: by_type_and_time
    fields: [reaction_type ASC, created_at DESC]

A created_at DESC index enables fast retrieval of “recent views” without scanning all edges. Indexes are pre-computed during writes and accessed directly during queries.

For how indexes are used in queries, see Query.

Alias

An Alias provides an alternative name for a label, enabling different names for the same underlying data.

Properties:

• name: Alias identifier in the format service.alias
• target: The label this alias points to (service.label)
• active: Whether the alias is active

Aliases are useful for:

• Gradual migrations between label names
• Providing domain-specific names for shared labels

Storage

Storage defines where data is physically stored, specifying the storage backend configuration.

Properties:

• type: Storage type (e.g., hbase)
• name: Storage identifier
• conf: Configuration map with storage-specific settings
• active: Whether the storage is active

Labels reference a storage by name. For available datastore backends, see Datastore.

Naming Conventions

Type	Format	Example
Service	Simple identifier	myservice
Label	service.label	myservice.likes
Alias	service.alias	myservice.friends
Storage	Simple identifier	hbase-storage-1

Version Information

Actionbase has two versions of schema APIs: v2 and v3. Currently, schema uses v2 API, while mutation and query operations use v3. The terminology mapping:

v2 Term	v3 Term
Service	Database
Label	Table
Alias	Alias

Schema v3 support is planned for future releases.

Schema and Operations

Schema directly influences how operations work:

• Mutations: Data must conform to the label’s schema
• Queries: You must use indexes defined in the label
• Storage: Configuration determines where data is stored

When you perform a mutation, data follows the label’s schema. When you query, you specify an index that was defined in the label. This explicit relationship ensures queries follow optimized paths prepared during schema definition.

Next Steps

• Mutation: Write data following your schema
• Query: Query data using defined indexes
• API Reference: Complete API documentation