Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/mindbeam/unbase

Last synced: 13 days ago
JSON representation

Host: GitHub
URL: https://github.com/mindbeam/unbase
Owner: mindbeam
License: other
Created: 2015-02-14T20:13:45.000Z (almost 10 years ago)
Default Branch: master
Last Pushed: 2020-02-10T21:03:54.000Z (almost 5 years ago)
Last Synced: 2024-10-08T02:15:38.790Z (about 1 month ago)
Language: Rust
Size: 24.5 MB
Stars: 39
Watchers: 8
Forks: 9
Open Issues: 13
Metadata Files:
- Readme: README.md
- License: LICENSE

Awesome Lists containing this project

README

        [![Build Status](https://travis-ci.org/unbase/unbase.svg?branch=master)](https://travis-ci.org/unbase/unbase)

[![Gitter](https://badges.gitter.im/unbase/Lobby.svg)](https://gitter.im/unbase/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)

# 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](#footnote1)} anywhere, thus the name Unbase.

*Unbase is presently under active development.*

## Summary of Design Goals:

See [Design Goals](http://unba.se/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 partitions^{[2](#footnote2)}

* A robust type system

* Tunable [durability](http://unba.se/design/durability) guarantees

* Reduced costs associated with hosting infrastructure, and the planning thereof.

* Common, minimalist library for client and server^{[3](#footnote3)} 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](http://unba.se/design/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](https://en.wikipedia.org/wiki/Light_cone){:target="define"} as a good approximation of our upper-bound.


2: Using the term "partition" for conversational understanding. [Partitions are not actually a thing](https://arxiv.org/abs/1509.05393).


3:  We believe there should be no difference between "client" and "server" except for computational/storage/network capacity and policy.