unba.se Open in urlscan Pro
185.199.109.153  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Reactive, Fault-Tolerant, Decentralized. No Waiting

 * Home
   
 * Design
 * The Problem
 * Consistency Model
 * Design Goals
 * Core Concepts
 * Glossary
 * Cheat Sheet
 * Data Types
 * Durability
 * Frequently asked questions
 * Bibliography
 * Simulation
 * Beacon Clock Sim v1


WHAT IS UNBASE?

Unbase is a concept for a distributed database/application framework that is
fundamentally reactive, fault tolerant, and decentralized. It seeks to address
some very specific shortcomings in traditional paradigms; to create a
distributed architecture that transcends device, geography, programming
language, and present orthodoxy about what constitutes a “database”. It seeks to
blur the lines between application/database, and client/server.

We believe that for many use cases, data (or computation thereof) should not be
assigned to any specific storage location (as is the case in “sharded” systems)
but rather it should be stored close its origin, and its consumers. Data should
not be “based”1 anywhere, thus the name Unbase.

Unbase is presently under active development.


SUMMARY OF DESIGN GOALS:

See Design Goals for more details

 * Provide the strongest consistency guarantees possible with zero
   coordination/waiting
 * Drastically reduce operational latency by focusing on data locality
   (planet/city/memory-bus/processor-core)
 * Peer-to-peer networking to ensure continued operation during network
   partitions2
 * A robust type system
 * Tunable durability guarantees
 * Reduced costs associated with hosting infrastructure, and the planning
   thereof.
 * Common, minimalist library for client and server3 applications
 * Distributed content-filtered pub/sub for efficient push notifications
 * Provide a facility for the registration and execution of triggers to allow
   for reactive, but loose couplings


CONSISTENCY MODEL

Unbase seeks to implement a specific causal consistency model which we are
calling “Infectious Knowledge”. See Consistency Model for more details

1: When data storage locality is determined by an algorithm which fails to
consider the points in space where the data is originated or observed, the
requester must wait longer for its retrieval. We can think of light cones as a
good approximation of our upper-bound.
2: Using the term “partition” for conversational understanding. Partitions are
not actually a thing.
3: We believe there should be no difference between “client” and “server” except
for computational/storage/network capacity and policy.

Documentation for Unbase