Documentation

Get Started Within Minutes

Important References

IMPORTANT: You will need the service_account.json, the API key, and the URL for the database sent in your purchase confirmation email.

The complete API is defined in the proto file found under the gRPC code examples. These are labeled by rpc in the RogueDB service. All responses are the Response message. All inputs are captured in the parentheses (Insert, Update, Remove, Search).

Complete Guide

The code examples covers authentication, all 4 CRUD APIs, and schema change with detailed notes on usage. Included are functions for JWT token generation used for authentication and file detection.

Learn how to use REST and JSON with RogueDB.
Learn how to use gRPC and Protocol Buffers with RogueDB.
Proto service and API definitions for RogueDB.

Schema Management

RogueDB uses Protocol Buffers for schema definitions.

See Index Performance below for general guidelines on the best way to create an index.

Special Note: Using Protocol Buffer's compiler protoc to generate messages in your target language allows validation locally before applying changes to the database.

Authentication and Identification

The complete example includes everything needed for secure connection with HTTPS using a JWT token for authentication and an API key for identification.

No additional setup is required.

Secure connections are the only allowed connections. Any connection not containing all three components are rejected by default.


User Roles and Permissions

The API key from the purchase confirmation email has all permissions by default and cannot be revoked.

RogueDB supports the creation of users and assigning of permissions per schema. Users have no permissions by default. The following permissions can be assigned:

  • Read: Permission for the Search API.
  • Write: Permission for the Create, Update, and Remove APIs.
  • Execute: Permission for the Subscribe API.
  • Admin: Grants all permissions and overrides any existing permission.

Manage users through the CRUD APIs:

Index Performance

  • Partitioning: Example - Use stock symbol over timestamp as the first index.
    • RogueDB optimizes insertion for "bucketed" data versus incremental based index strategies.
  • Granularity: Example - Use stock symbol over aggregate period as the first index.
    • RogueDB optimizes for multi-field indexing with negligible effects on performance.
  • Minimal: Example - Use the smallest reasonable number of fields to form a unique index.
    • RogueDB optimizes memory footprint with internal metadata utilizing the subset of fields identified for indexing.
  • Order: Arrange categorical fields first and incremental fields last. Only include fields used in all indexed search queries.

Practical use cases means swapping the order typically used in other databases for the fields being indexed. Categorization fields go first. Incrementing fields go last. By doing this, RogueDB can leverage the natural bucketing of data to parallelize operations.

Permission Propogation

Permissions flow downwards from the parent schema. For instance, consider the following example:

Now presume we have a user, Foo, with the following permissions:

  • MedicalRecords: No permissions by default.
  • FinancialRecords: Read permissions.
  • Customer: Write and Read permissions.

Due to the composition of Customer including MedicalRecords and FinancialRecords, Foo can do the following when using Customer as the record:

  • MedicalRecords: No permissions by default => Write and Read permissions.
  • FinancialRecords: Read permissions => Write and Read permissions.

Careful consideration needs to be made when designing schemas to ensure permissions do not propagate in unexpected ways. As such, the Execute permission and Admin role should be given sparingly, if at all, and under additional security mechanisms.

Design Suggestion

Creation of a unique ID per customer with storage of MedicalRecords, FinancialRecords, and PII as separate schemas in the database prevents propagation of permissions. This further streamlines efficient storage and retrieval of data to only the required components versus the entirety of a record. UUIDs are an excellent mechanism for unique identifiers.

Consider the following as a more secure alternative:

Special Considerations

  • Duplicate Data: RogueDB automatically removes all duplicate data based on the index.
  • Highly Nested Messages: Consider separating into smaller individual components.
    • RogueDB does not intend to support queries that allow specification into nested message fields. If the field's indexing strategy does not cover intended use case, the message will need to be separated.
    • Protobuf serialization becomes slower for deeply nested messages due to the recursive nature. Simpler messages means faster performance.
  • CRUD Operations: Round robin scheduling of CRUD operations.
    • RogueDB utilitizes batching of operations to increase throughput.
    • Order of execution: Create, Update, Remove, Basic Queries, Complex Queries, Compositional Queries
  • Order Guarantees:
    • Ordering is not guaranteed between CRUD operations or requests.
    • Duplicate messages based on index in a request only uses the first message.

Still have questions?

Contact Us

First Mover Advantage
Limited Availability Discounts

0-100 Users: 50% Discount. Promo: FIRST100
101-250 Users: 25% Discount. Promo: FIRST250
251-500 Users: 10% Discount. Promo: FIRST500

Get Started