views:

536

answers:

7

I am developing a simple internal use application with an intended user base of around 100 people. The application does a lot of reads and very few writes. The dataset size is fairly small and we do not want to use a RDBMS if possible. In fact, the relational requirements are fairly small. I am looking at using some NoSQL database and I am looking for one with the following requirements.

  1. A simple, stable implementation which can be accessed easily from Java (i.e has a Java client).
  2. I would like to be able to run a test application from a Windows box although the final deployment is on a Linux box.
  3. Setup of the NoSQL DB should be minimal.
  4. I am not concerned with scaling the DB because we expect to limit the dataset size and trim old data occasionally.

Any suggestions would be helpful. I am currently considering redis + jredis

EDIT: One of my main motivations for this project is also to look into the programming model and ways of usage of NoSql DBs. I understand I can use flat files, blobs etc.

+2  A: 

If you're looking for a simple stable implementation of a NoSQL DB system, look no further than Apache (they have over 10 years of development experience).

Few that comes to mind:

  • CouchDB
  • Cassandra. Developed by Facebook but now under Apache. Twitter, Facebook, Digg, etc. are using Cassandra. It's fully written in Java and can be accessed via Java using Thrift or Avro.
  • Redis (although Redis doesn't run flexibly well on Windows OS). It's owned by VMWare.
The Elite Gentleman
You do *NOT* want to use Cassandra for this. It would be the exact wrong choice for your requirements.
ericflo
@ericflo - Can you elaborate a bit more please?
Thimmayya
+1  A: 

A document database has a very simple storage model and basic query abilities. MongoDB for example, seems to have everything you need in terms of compatibility and is very easy to set up.

Niels van der Rest
+5  A: 

I've had great success with Neo4J. The database is embedded so the amount of effort required to get the system running is minimal. Additionally the client interface to the DB is a pleasure to work with.

The entire setup is two additional jars on the classpath.

gpampara
Thanks. I will look it up.
Thimmayya
+1 for neo4j. I've been using it in a project and found it integrates very easily into a project. My only gripe is version 1.1 doesn't have a way to get a relationship between two nodes by providing a method getRelationship(node1, node2). Otherwise, it's been awesome. I'd recommend it.
+4  A: 

What you're looking for is SQLite, who cares if it's a SQL db.

Alex Gaynor
+1  A: 

Definitely OrientDB (http://www.orientechnologies.com):

  • It's 100% written in Java (requires JRE 1.6 for the client/server version, otherwise JRE 1.5)
  • Elegant Java APIs
  • Really fast. About 50.000 insert/sec on common HW
  • Small: less than 1Mb for all
  • Support for SQL with extension for links, graphs and objects
  • Native support for Security
  • Run as embedded or in client/server configuration. Next releases will support clustering and partitioning
  • Apache 2 license: free for any use
  • Much more
Lvca
A: 

Take a look at db4o (http://developer.db4o.com/), a leading open source object database. I think it will do everything you want.

Dirk
+1  A: 

I would choose between 2 options:

1) Berkeley DB: it's very mature and at the same time very simple key-value storage. It could be the best choice in not one big issue: it was bought by Oracle and some licensing issues can occur now. Read carefully info about licensing and it your requirements don't break the agreement then go with it.

2) MySql on MyISAM engine without any foreign keys (i.e. several independent not normalized tables). You'll use it just as a key-value storage. Read this answer about using MySql as NoSql storage. If I were in your shoes, I'd go with this option just because I know that it would show great performance, there are mature tools for working with MySql, many people have experience with it and at any time you can easily use all its relational potential if you eventually decide to go back to RDBMS solutions.

Roman