Orly™ Graph Database
C++ Other
Latest commit 8971c4d Nov 3, 2014 1 @cmaloney cmaloney Merge pull request #1 from cmaloney/subproc_precise
Subproc precise
Permalink
Failed to load latest commit information.
base base/pump: Rewrite it to use more modern C++ Aug 25, 2014
docs Add basic origins of project file May 2, 2014
gz base/*_util* -> util/ Jun 16, 2014
inv_con An all-in-one allocation mini-cache. This uses invasive containment t… Jul 10, 2014
io Generic lambdas aren't quite ready in g++-4.9.0. Jun 28, 2014
jhm base/subprocess: Allow precision specification of subprocess arguments Aug 25, 2014
mpl Fix <mpl/typical.test> after I broke it only partly removing <mpl/sor… May 5, 2014
multi_event Move NO_CONSTRUCTION, NO_COPY_SEMANTICS to base/class_traits.h Apr 16, 2014
orly base/subprocess: Allow precision specification of subprocess arguments Aug 25, 2014
rpc base/*_util* -> util/ Jun 16, 2014
server test: Make unittests print backtraces when they segfault Aug 20, 2014
signal base/*_util* -> util/ Jun 16, 2014
socket Remove <base/error> per #21 Jul 7, 2014
static/branding add logo for readme Jul 18, 2014
strm Added strm/utf8/in. Jul 5, 2014
test test: Catch and print a nice error message for SIGPIPE Aug 25, 2014
third_party Replace readline with the BSD licensed linenoise library Jul 22, 2014
tools Remove the last member AsStr function! Aug 1, 2014
utf8 Move NO_CONSTRUCTION, NO_COPY_SEMANTICS to base/class_traits.h Apr 16, 2014
util Address reviewer comments Aug 14, 2014
visitor Use a helper function to convert chrono durations to seconds represen… Aug 8, 2014
.gitignore starsha: DELETED Jun 17, 2014
AUTHORS fix name for ASF push Apr 11, 2014
LICENSE fix names for ASF migration Apr 11, 2014
Makefile Add twitter_live to default buildset, Makefile Jul 18, 2014
README.md Update README.md Jul 18, 2014
bootstrap.jhm jhm: Add missing targets line to bootstrap.jhm from config merging. Jun 17, 2014
bootstrap.sh base/backtrace: Add a generic backtrace generation library Aug 20, 2014
debug.jhm jhm: Convert config to use delta configuration Jun 17, 2014
demo.py Update defaults to reflect our minimum requirements, default to loadi… Jul 20, 2014
release.jhm jhm: Convert config to use delta configuration Jun 17, 2014
root.jhm base/subprocess: Allow precision specification of subprocess arguments Aug 25, 2014
setup_llvm.sh fix names for ASF migration Apr 11, 2014

README.md

Orly

tip for next commit

This is the repository for the Orly (pronounced "Oh Really") non-relational database. It's meant to be fast and to scale for billions of users. Orly provides a single path to data and will eliminate our need for memcache due to its speed and high concurrency.

Orly features:

  • Points of View: This is our version of optimistic locking or isolation. In traditional databases, clients have to lock the entire database (or at least large swaths of it) before updating it to ensure data remains consistent. In Orly, clients make changes in their own private points of view, which are like small sandboxes. Changes in private points of view eventually propagate into shared points of view and eventually reach the global point of view, which is the whole database. Updates to private points of view don't lock anything: Orly determines later whether, when, and how to reconcile changes from different points of view. We also encourage field calls rather than field changes (e.g., x += 1 is better than x = x + 1).
  • Time Travel: We use something called the Flux Capacitor to keep a history of changes made to the database and to resolve conflicts as they come into shared points of view and the global point of view. This permits us to perform consistent read for any point in time. Orly defines its "time line" by causality rather than clock time. Instead of manipulating timestamps, Orly records an ordering of events (e.g., update A affects update B, so A "happens before" B).)
  • Query Language: Orly has its own high-level, compiled, type-safe, functional language called Orlyscript. Orlyscript is not just a query language: You can write general-purpose programs in it complete with compile-time unit tests. Orly comes with a compiler that transforms Orlyscript into shared libraries (.so files on Linux), which Orly servers load as packages.
  • Scalability and Availability: While we eventually plan to develop a sharded Orly machine (and actively design so that we can build such a machine), our current single-node server with fail-over/replication can handle hundreds of thousands of transactions per second. We like to say that Orly will function on a "planetary scale": Your data and computations will not only distribute across a data center, but also across many data centers across the globe. This means that no disaster short of nuking the planet fifty times over or colliding with a gigantic asteroid will destroy your data. (Even those might not be catastrophic: Maybe we'll have data centers running Orly with your replicated data on the moon or Mars.)

Supported Platforms

Currently Orly only runs on Linux.

System Requirements

  • Ubuntu 14.04 LTS (Trusty Tahr) (64-bit)
  • 4GB of RAM

Building Orly

Requires the latest versions of the gcc and clang/LLVM compilers. We're currently using: gcc (Ubuntu 4.9-20140406-1ubuntu1) 4.9.0 20140405 (experimental) [trunk revision 209157]

Contributing to Orly

Documentation for this is currently minimal. See docs/coding.md and docs/best_practices.md for basic starting hints.


README.md Copyright 2010-2014 OrlyAtomics, Inc.

README.md is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

You should have received a copy of the license along with this work. If not, see http://creativecommons.org/licenses/by-sa/4.0/.