[Pharo-project] Writing an object graph into a no-sql database [WAS] Re: [Seaside] ESUG SummerTalk - Fuel, binary object serializer
I am looking at using Riak ( http://wiki.basho.com/ ) with Pharo. When storing a âbusiness objectâ you have two choices:
- Store a binary BLOB representing your object graph. - Store the object graph as JSON data.
The last option essentially means you must do something similar to OR mapping, so I would prefer the first option. With Riak, you will soon be able to store additional indexed properties, which you later will be able to query. So you store your whole business object as a BLOB, together with those properties you need to query.
Hi guys. Sorry to come back with this old post, but now I am interested ;) Right now, I have a requirement where I need to write a graph into a file. I am using Fuel for that. Each graph, has its own file. In the image side I just store the filename, When I need to load it it reads such file and materialize it with Fuel. I was thinking going a step forward and use a key/value (a.k.a no-sql) database. With Fuel, I can take a graph, and serialize directly into a ByteArray, hence I can take a graph to swap, I assign an ID, and and save it into the database. In the image side, I keep that ID. Then, when needed, I search it in the database and then after with that ByteArray found, I materialize it with Fuel. So...first question is, do you think that could be faster/better than directly writing into a file as I am doing now? Now, which are the available Pharo wrappers for no-sql databases that let me do that? I would appreciate any link or documentation about them. What do I need to use such databases from Pharo? FFI and a library installed in my machine? are there binaries for Mac OS? Thanks in advance, -- Mariano http://marianopeck.wordpress.com
On Aug 5, 2011, at 11:57 52AM, Mariano Martinez Peck wrote:
I am looking at using Riak ( http://wiki.basho.com/ ) with Pharo. When storing a âbusiness objectâ you have two choices:
- Store a binary BLOB representing your object graph. - Store the object graph as JSON data.
The last option essentially means you must do something similar to OR mapping, so I would prefer the first option. With Riak, you will soon be able to store additional indexed properties, which you later will be able to query. So you store your whole business object as a BLOB, together with those properties you need to query.
Hi guys. Sorry to come back with this old post, but now I am interested ;)
Right now, I have a requirement where I need to write a graph into a file. I am using Fuel for that. Each graph, has its own file. In the image side I just store the filename, When I need to load it it reads such file and materialize it with Fuel. I was thinking going a step forward and use a key/value (a.k.a no-sql) database.
Whether this is "a step forward" really depends on if you need what they have to offer. If there's not more than one client reading the same objects from DB, I suggest staying with simple file persistency. KISS.
With Fuel, I can take a graph, and serialize directly into a ByteArray, hence I can take a graph to swap, I assign an ID, and and save it into the database. In the image side, I keep that ID. Then, when needed, I search it in the database and then after with that ByteArray found, I materialize it with Fuel.
So...first question is, do you think that could be faster/better than directly writing into a file as I am doing now?
Depends. If the DB does not guarantee writing to disk before returning success, it might. IIRC, this is (used to be?) a much criticized default mode of CouchDB.
Now, which are the available Pharo wrappers for no-sql databases that let me do that? I would appreciate any link or documentation about them. What do I need to use such databases from Pharo? FFI and a library installed in my machine? are there binaries for Mac OS?
http://www.squeaksource.com/SCouchDB http://www.squeaksource.com/EpigentRiakInterface AFAICT, They both communicate with the databases directly through HTTP, so no extra libraries should be required. Cheers, Henry
Personally I'd only consider a no-sql db if you are working with a distributed environment or have multiple apps using the data. If you're on a single tier/single app scenario then probably easiest to stick with file system. On 05 Aug 2011, at 11:57 AM, Mariano Martinez Peck wrote: So...first question is, do you think that could be faster/better than directly writing into a file as I am doing now?
Thanks guys for all you answers. I am taking them into account. On Fri, Aug 5, 2011 at 12:53 PM, Carlo <snoobabk@yahoo.ie> wrote:
Personally I'd only consider a no-sql db if you are working with a distributed environment or have multiple apps using the data. If you're on a single tier/single app scenario then probably easiest to stick with file system.
On 05 Aug 2011, at 11:57 AM, Mariano Martinez Peck wrote:
So...first question is, do you think that could be faster/better than directly writing into a file as I am doing now?
-- Mariano http://marianopeck.wordpress.com
On 08/07/2011 04:00 PM, Mariano Martinez Peck wrote:
Thanks guys for all you answers. I am taking them into account.
A few remarks: - If you want "just add another box" for true master less scalability and fault tolerance (same k/v pairs stored at say 3 machines in parallell), then Riak is an incredibly cool and nice db right now. And while it can use JSON values it is not tied to it. - If you want crazy speed on a single box then you can use Tokyo Tyrant (or its newer cousin, don't recall its name). I wrote a binary binding for it a while back and it is an insanely fast k/v store. - CouchDB is also nice but IMHO Riak is more interesting at this time. regards, Göran
participants (4)
-
Carlo -
Göran Krampe -
Henrik Johansen -
Mariano Martinez Peck