libraries: All content tagged as libraries in NoSQL databases and polyglot persistence
Google open sourced a while ago LevelDB , a C++ library that provides an ordered mapping key-value storage. LevelDB performance convinced Basho guys to experiment with adding LevelDB as a storage engine for Riak. And there’s also a benchmark comparing LevelDB with SQLite and Kyoto Cabinet.
The LevelDB project lists the following key features:
- Keys and values are arbitrary byte arrays.
- Data is stored sorted by key.
- Callers can provide a custom comparison function to override the sort order.
- The basic operations are
- Multiple changes can be made in one atomic batch.
- Users can create a transient snapshot to get a consistent view of data.
- Forward and backward iteration is supported over the data.
- Data is automatically compressed using the Snappy compression library.
- External activity (file system operations etc.) is relayed through a virtual interface so users can customize the operating system interactions.
- Detailed documentation about how to use the library is included with the source code.
You can check out also the old thread on Hacker News about LevelDB..
Original title and link: LevelDB: Google’s Fast Persistent Key-Value Store Library ( ©myNoSQL)
Silver: database cacher, indexer and searcher
Probably because Silver was released by a publisher, this new open source library got some press today:
Enter Silver. Silver is designed to be a simple, lightweight wrapper for all your calls to a database that you want to cache or index with Redis. It is completely database/web-service agnostic so you should be able to use if for anything you can imagine caching.
Couple of thoughts about this new Ruby library:
- it is not a transparent caching layer that can be used in your application. Basically you’ll have to rewrite your app to use it.
- there is not way to update the cache
- the indexer is — in their own words — “stupidly simple fuzzy text search”
Project is hosted on GitHub.
redis-store: Redis-backed Tomcat session store
Definitely not benefiting from the same media buzz, Jonathan Leibiusky pushed to GitHub a Redis-backed Tomcat session store. Plugging this into your Tomcat would require just updating the
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="true" maxActiveSessions="1" minIdleSwap="1" maxIdleSwap="1" maxIdleBackup="1"> <Store className="org.apache.catalina.session.RedisStore" host="localhost" port="6379" password="something" database="0" /> </Manager>
Tomcat default session store is disk, so if your app is a heavy session users, you’ll probably see a boost in performance.
For the moment I haven’t tried this myself and I suppose it’ll need some extensive testing before going into production. ↩
Rogue is a type-safe internal Scala DSL for constructing and executing find and modify commands against MongoDB in the Lift web framework. It is fully expressive with respect to the basic options provided by MongoDB’s native query language, but in a type-safe manner, building on the record types specified in your Lift models
Open sourced by Foursquare.
It sounds like someone is working on a Smalltalk client for Riak that (most probably) will be based on the Protocol Buffers-based Riak protocol — chosen for its performance compared to HTTP, the other protocol supported by Riak.
Smalltalk is one of the languages I’ve never really got through, so maybe that explains why. Haskell, OCaml are just a couple of other examples. ↩
I prefer the manner of declaring field types in MongoEngine to MongoKit, but that’s just me. If you’re coming from something like the Django ORM, MongoEngine is very similar.
If you need to make on-the-fly modifications to document schemas at runtime, MongoKit is the way to go. MongoKit also allows you to bypass validation.
Finally, compare the MongoKit and MongoEngine documentation. I find the MongoEngine documentation a much more useful reference (it’s easier to navigate and read — very much my opinion though):
While I’m not a very experienced Pythonista, nor have I used any of these libraries, I must confess that I’m finding both being too much inspired from ORMs. There is structure in document databases, but enforcing all the rules and strictness of a relational model seems a bit too restrictive. Plus, it is unclear on how you can actually take advantage of document databases schemaless when using these libraries.