Skip to content

Latest commit

 

History

History
50 lines (30 loc) · 2.73 KB

README.md

File metadata and controls

50 lines (30 loc) · 2.73 KB
Raw

cooperdb

Introduction

This repository contains the CooperDB database specification and reference implementation.

This database is named for D. B. Cooper, who was able to ransom a large quantity of money, and escape to an unknown fate.

CooperDB is a database which solves all three of the problems of CAP theorem. It is able to solve these in real time, across latent network gaps, with eleven-nines of availability, and be completely partition tolerant. It is the world's most buzzword-compliant database.

High level features of CooperDB:

  • Easily and infinitely horizontally scalable
  • Fully partition-tolerant
  • Highly available
  • Immediately consistent
  • ACID and BASE compliant
  • Transactional integrity - without transactions
  • Immune to deadlocks
  • Share-nothing architecture
  • Each node is completely stateless

Any implementation of the CooperDB API MUST meet all of the above features.

Conventions and Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.

The key words MUST (BUT WE KNOW YOU WON'T), SHOULD CONSIDER, REALLY SHOULD NOT, OUGHT TO, WOULD PROBABLY, MAY WISH TO, COULD, POSSIBLE, and MIGHT in this document are to be interpreted as described in RFC 6919.

How does it work?

CooperDB is able to provide a rich feature set in very few lines of code. It uses technology capabilities of today, without needing to consider quantum entaglement.

When leveraging CooperDB, you SHOULD CONSIDER the power of the /dev/null model that it follows, enabling you to literally store any content in it, and never be able to retrieve it again.

When leveraging an implementation of CooperDB, you MAY WISH TO store arbitrary payloads inside Cooper DB. This is a perfect usage of CooperDB. You REALLY SHOULD NOT consider retrieving content from CooperDB, as CooperDB implementations MUST return null for any request to meet all three guarantees of CAP.

You MAY WISH TO consider that Cooper DB is ideally named for D. B. Cooper for this very reason. It can accept any payload you send it, and send them to an unknown fate.

Informative References

Normative References

  • RFC2119 Key words for use in RFCs to Indicate Requirement Levels
  • RFC6919 Key words for use in RFCs to Indicate Requirement Levels