Skip to content

Latest commit

 

History

History
33 lines (23 loc) · 2.76 KB

README.md

File metadata and controls

33 lines (23 loc) · 2.76 KB
Raw

Build Status Gitter

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{:target="define"} 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.