Ara,

I completely agree with you on the general point. However, I'm not concerned 
with speed so much as where the data lives. This is a server/storage system 
that should only have the user's data on the main disk, and I'm planning to 
move the boot filesystem to CompactFlash. Therefore I want to get data either 
to memory (for transient stuff) or to specific locations on disk (probably 
simple YAML files) since I really don't need the full features of a database.

On the memory side, I tried redis [1] at the suggestion of another list member 
(thanks Gabe!) and so far it's great. It replaces memcache directly--simple 
get/put of key/value pairs--but it also provides atomic list operations and 
therefore replaces beanstalk (the queuing system) as well. It was trivial to 
rewrite my own job queue system on redis.

I also took the opportunity to remove direct references to memcache in our code 
base and replace them with a generic KeyValueStore class; that way if redis 
doesn't cut the mustard I can switch to database tables with little trouble.

Best regards,
Josh

[1]: http://code.google.com/p/redis/

On Feb 14, 2010, at 5:04 PM, ara.t.howard wrote:

> On Wed, Feb 10, 2010 at 11:46, Josh Carter <[email protected]> wrote:
>> So my question for the group is: does anyone have recommendations and 
>> first-hand experience with a lightweight database that would meet these 
>> needs?
> 
> prove that your database is too slow first.  then prove that you
> cannot optimize it to be faster - all of mysql, postgresql, oracle,
> sqlite, etc support pure memory tables - which should perform
> extremely fast and require 0 extra setup.
> 
> if you *still* have issues there are lot of alternatives, but i doubt
> you will have issues if you look deeply into tweaking your current db
> to support your usage pattern for a subset of  it's relations.
> 
> -- 
> -a
> --
> be kind whenever possible... it is always possible - h.h. the 14th dalai lama
> _______________________________________________
> Bdrg-members mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/bdrg-members

_______________________________________________
Bdrg-members mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/bdrg-members

Reply via email to