InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

StrokeDB, Just Another Distributed Database? Not Really.

Posted by Sebastien Auvray on Apr 22, 2008

Sections
Architecture & Design,
Development,
Operations & Infrastructure
Topics
Data Access ,
Database Design ,
Ruby
Tags
Database
As Distributed Databases get more and more interest, implementations are flourishing. CouchDB showed the way to go and is now incubated as an Apache project. RDDB was one of the first Document-Oriented Distributed Databases implemented in Ruby. StrokeDB is a new actor in the scene. It was written by Yurii Rashkovskii and Oleg Andreev, who did a presentation at Euruko2008 (PDF slides). From the StrokeDB website:
StrokeDB is an embeddable distributed document database written in Ruby. It is schema-free, it scales infinitely, it even tracks revisions and perfectly integrates with Ruby applications.
StrokeDB is only 3 months old and offers already many interesting features, the basic ones for Distributed Databases:
  • Flat address space of documents identified by UUIDs.
  • JSON, schemaless document format.
  • References to other documents with automatic eager loading on access.
And some others that could differentiate itself from its competitors:
  • Documents revision control with diff/merge facilities built-in.
  • A flexible object-oriented API.
  • Simple search index over document slots.
  • Possibility to write native code for very specific performance issues.
Many more features are in the pipeline.

There's also a promise to port StrokeDB to thin client languages (JavaScript, ActionScript, etc.) to enable offline work with the data.

You can check out the StrokeDB code at GitHub and have a look at Yurii's short introduction to StrokeDB. While the authors are busy writing a clean API and adding new features, it will be interesting to see how the project evolves with maturity and later to have a look at benchmarks to check how it performs.
What problem are we solving here? by Eugene Tolmachev Posted
  1. Back to top

    What problem are we solving here?

    by Eugene Tolmachev

    Can someone explain what problems are we solving here?

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.