Code Monkey home page Code Monkey logo

fdb-java-eventstore's Introduction

fdb-java-eventstore

Build Status codecov Maintainability Sonarcloud Status

An event store layer build on top of FoundationDB

Layout

Data is stored in two separate subspaces

Global Subspace

Globally ordered based time
Global / [versionstamp] /

Global subspace tuple value is a pointer to an event in the stream subspace stored in the format of <event number>@<stream id>. When reading from the global subspace via the readAll* methods we resolve the pointer and return the message from the stream subspace

QUESION: Could we pack in the <event number>@<stream id> or equivalent into the key so we didnt need to retrieve the value? What type of performance boost would that give?

Stream Subspace

Stream / id (stream hash) / version /

  • message Id
  • stream id
  • message type,
  • message data
  • message metadata
  • event number
  • created Date (UTC from epoch)
  • Versionstamp (Global position)

Using

EventStoreLayer requires you pass in a FoundationDB Database as well as a DirectorySubspace. The DirectorySubspace is where we'll store all our events.

Create a DirectoryLayer

new DirectoryLayer(true).createOrOpen(tr, Collections.singletonList("es")).get();

Create EventStoreLayer

EventStoreLayer es = new EventStoreLayer(db, eventStoreSubspace);

Create EventStoreLayer with default "es" DirectorySubspace

EventStoreLayer es = EventStoreLayer.getDefault(db);

Append

EventStoreLayer es = new EventStoreLayer(db, eventStoreSubspace);
String stream = "test-stream";
es.appendToStream(stream, ExpectedVersion.ANY, createNewStreamMessage());

Read

Read from a stream

ReadStreamSlice read = es.readStreamForwards("test-stream", 0, EventStoreLayer.MAX_READ_SIZE);

Read backwards from a stream

ReadStreamSlice read = es.readStreamBackwards(stream, StreamPosition.END, 10);

Read from the all subspace

ReadAllSlice read = es.readAllForwards(Position.START, 10);

Read backwards from the all subspace

ReadAllSlice read = es.readAllBackwards(Position.END, 10);

Build / CI / Plugins

running locally

Downloads

https://www.foundationdb.org/download/

https://www.foundationdb.org/downloads/6.2.22/macOS/installers/FoundationDB-6.2.22.pkg

https://www.foundationdb.org/downloads/1.6.3/macOS/installers/FoundationDB-Document-Layer-1.6.3.pkg

configuration /usr/local/etc/foundationdb

cd /usr/local/foundationdb has an install script data and logs

On macOS, FoundationDB is started and stopped using launchctl as follows:

host:~ user$ sudo launchctl load /Library/LaunchDaemons/com.foundationdb.fdbmonitor.plist host:~ user$ sudo launchctl unload /Library/LaunchDaemons/com.foundationdb.fdbmonitor.plist It can be stopped and prevented from starting at boot as follows:

host:~ user$ sudo launchctl unload -w /Library/LaunchDaemons/com.foundationdb.fdbmonitor.plist

fdbcli

fdb-java-eventstore's People

Contributors

seancarroll avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

fdb-java-eventstore's Issues

Deleting a Stream

Add the ability to soft and hard delete a stream. As part of this we need to be able to scavenge and delete data from the global subspace

Store Link / Pointer In Global Subspace Instead of Full Tuple

Currently we store all the information twice once in the Stream subspace and again in the global subspace. This is not space efficient and likely unnecessary. Instead we could just store a pointer in the global subspace that point to the record in the corresponding stream subspace. The tradeoff here is space efficiency for an additional read operation, 1 to read the global record which will be a pointer and then another read from the stream subspace to get the actual information, when reading from the global subspace. I think the tradeoff is worth it given the global subspace is mostly for projections which shouldnt be read as often and should be affected too much my the decrease read performance. I should also run a read benchmark to see what exactly the read performance looks like between the two

Split Large Keys/Values

From Foundationdb known limitations

Keys cannot exceed 10,000 bytes in size. Values cannot exceed 100,000 bytes in size. Errors will be raised by the client if these limits are exceeded.

I don't think we'll have issues with the key size, famous last words, given we can constrain size of stream name and keys however we'll need to add logic to split values so we can support larger values.

Other links

Set up CI

Need to set up CI for this project. Leaning Travis CI at the moment

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.