[Pharo-project] Persistence Options
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have 2. What persistence is used in your Pharo application today 3. Which persistence solution you want to use/would you like to see in Pharo's future 4. What would you recommend. Comments as ever appreciated ... Bye T.
http://www.seaside.st/documentation/persistence#180087651 might be a good start as a place to collect these comments. James On Dec 17, 2012, at 10:08 AM, Torsten Bergmann wrote:
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have 2. What persistence is used in your Pharo application today 3. Which persistence solution you want to use/would you like to see in Pharo's future 4. What would you recommend.
Comments as ever appreciated ...
Bye T.
Hey! On 12/17/2012 07:08 PM, Torsten Bergmann wrote:
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have 2. What persistence is used in your Pharo application today 3. Which persistence solution you want to use/would you like to see in Pharo's future 4. What would you recommend.
I can give some light on a few options that I have been involved in: TokyoTyrant =========== The "binding" I wrote hasn't been touched since I wrote it, but it is binary over SocketStream and VERY fast. There is now a new similar database called KyotoTycoon from the same author that he recommends as superior. Some differences: http://stackoverflow.com/questions/4178414/what-is-the-difference-between-to... I am not using nor maintaining this library anymore though. Still the raw speed is amazing and if that is what you want then this one is hard to beat. NOTE: Not sure how it operates under Pharo but since it runs on top of SocketStream I suspect it just works. If someone tries it out, let me know. Phriak ====== This is a binding to Riak, perhaps the most insanely cool NoSQL database IMHO. Yeah, MongoDB is also very nice, but some aspects of Riak really makes me comfy and warm inside. The binding was started by Runar Jordahl called "EpigentRiakInterface", then I did a friendly fork and improved it even more, and then Nicolas Petton joined and improved it LOTS more, and now lately Paul De Bruicker has also joined with commits. Phriak is intentionally focused on Pharo and uses the Zinc components to implement the API which is HTTP based. Riak has protocol buffers too, but we haven't looked at that. This binding is maintained, pretty complete and very easy to use. Riak is also extremely easy to install. Oak === This is a not so well known little side project from Nicolas Petton that I also am messing around with now. Oak is an "OODBish layer" that first was written abstractly to work on top of Riak, MongoDB etc. Now we are refocusing it on Riak only, possibly keeping optional Memcache support. Oak uses two other very nice new technologies in Pharo: Fuel and Ghost. Fuel is well known, very good serialization library basically. Ghost is a new small library for making well behaving proxies, using a smarter approach than the old "subclass ProtoObject and implement #doesNotUnderstand:". Net result is a semi transparent OODB which stores objects as Fuel blobs in Riak with UUIDs as keys. The auto faulting is done using Ghost proxies (so parts of your domain model are loaded "on demand" when you send messages to them). Oak is not super automagic like Magma - it doesn't do GC for example. But it is quite fast, small codebase and since it has a very simple model you can use other aspects of Riak through Phriak on the side. Oak is live and kicking and we are improving it by the day. So consider it a very interesting alpha, but still, small and simple codebase so you can use it already if you are not afraid to get your hands dirty. regards, Göran
Hey! On 12/18/2012 09:35 AM, Göran Krampe wrote:
TokyoTyrant =========== The "binding" I wrote hasn't been touched since I wrote it, but it is binary over SocketStream and VERY fast. There is now a new similar database called KyotoTycoon from the same author that he recommends as superior. Some differences:
http://stackoverflow.com/questions/4178414/what-is-the-difference-between-to...
I am not using nor maintaining this library anymore though. Still the raw speed is amazing and if that is what you want then this one is hard to beat.
NOTE: Not sure how it operates under Pharo but since it runs on top of SocketStream I suspect it just works. If someone tries it out, let me know.
Just noticed that KyotoTycoonClient is available on SS using WebClient by Masashi Umezawa: http://map.squeak.org/packagebyname/kyoto Cool :) Not sure if it works in Pharo of course. regards, Göran
tx goran for the list! Stef On Dec 18, 2012, at 9:35 AM, Göran Krampe wrote:
Hey!
On 12/17/2012 07:08 PM, Torsten Bergmann wrote:
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have 2. What persistence is used in your Pharo application today 3. Which persistence solution you want to use/would you like to see in Pharo's future 4. What would you recommend.
I can give some light on a few options that I have been involved in:
TokyoTyrant =========== The "binding" I wrote hasn't been touched since I wrote it, but it is binary over SocketStream and VERY fast. There is now a new similar database called KyotoTycoon from the same author that he recommends as superior. Some differences:
http://stackoverflow.com/questions/4178414/what-is-the-difference-between-to...
I am not using nor maintaining this library anymore though. Still the raw speed is amazing and if that is what you want then this one is hard to beat.
NOTE: Not sure how it operates under Pharo but since it runs on top of SocketStream I suspect it just works. If someone tries it out, let me know.
Phriak ====== This is a binding to Riak, perhaps the most insanely cool NoSQL database IMHO. Yeah, MongoDB is also very nice, but some aspects of Riak really makes me comfy and warm inside.
The binding was started by Runar Jordahl called "EpigentRiakInterface", then I did a friendly fork and improved it even more, and then Nicolas Petton joined and improved it LOTS more, and now lately Paul De Bruicker has also joined with commits.
Phriak is intentionally focused on Pharo and uses the Zinc components to implement the API which is HTTP based. Riak has protocol buffers too, but we haven't looked at that.
This binding is maintained, pretty complete and very easy to use. Riak is also extremely easy to install.
Oak === This is a not so well known little side project from Nicolas Petton that I also am messing around with now. Oak is an "OODBish layer" that first was written abstractly to work on top of Riak, MongoDB etc. Now we are refocusing it on Riak only, possibly keeping optional Memcache support.
Oak uses two other very nice new technologies in Pharo: Fuel and Ghost. Fuel is well known, very good serialization library basically. Ghost is a new small library for making well behaving proxies, using a smarter approach than the old "subclass ProtoObject and implement #doesNotUnderstand:".
Net result is a semi transparent OODB which stores objects as Fuel blobs in Riak with UUIDs as keys. The auto faulting is done using Ghost proxies (so parts of your domain model are loaded "on demand" when you send messages to them). Oak is not super automagic like Magma - it doesn't do GC for example. But it is quite fast, small codebase and since it has a very simple model you can use other aspects of Riak through Phriak on the side.
Oak is live and kicking and we are improving it by the day. So consider it a very interesting alpha, but still, small and simple codebase so you can use it already if you are not afraid to get your hands dirty.
regards, Göran
On Tue, Dec 18, 2012 at 5:35 AM, Göran Krampe <goran@krampe.se> wrote:
Hey!
On 12/17/2012 07:08 PM, Torsten Bergmann wrote:
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list
to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have 2. What persistence is used in your Pharo application today 3. Which persistence solution you want to use/would you like to see in Pharo's future 4. What would you recommend.
I can give some light on a few options that I have been involved in:
TokyoTyrant =========== The "binding" I wrote hasn't been touched since I wrote it, but it is binary over SocketStream and VERY fast. There is now a new similar database called KyotoTycoon from the same author that he recommends as superior. Some differences:
http://stackoverflow.com/**questions/4178414/what-is-the-** difference-between-tokyo-**cabinet-and-kyoto-cabinet<http://stackoverflow.com/questions/4178414/what-is-the-difference-between-to...>
I am not using nor maintaining this library anymore though. Still the raw speed is amazing and if that is what you want then this one is hard to beat.
NOTE: Not sure how it operates under Pharo but since it runs on top of SocketStream I suspect it just works. If someone tries it out, let me know.
Phriak ====== This is a binding to Riak, perhaps the most insanely cool NoSQL database IMHO. Yeah, MongoDB is also very nice, but some aspects of Riak really makes me comfy and warm inside.
The binding was started by Runar Jordahl called "EpigentRiakInterface", then I did a friendly fork and improved it even more, and then Nicolas Petton joined and improved it LOTS more, and now lately Paul De Bruicker has also joined with commits.
Phriak is intentionally focused on Pharo and uses the Zinc components to implement the API which is HTTP based. Riak has protocol buffers too, but we haven't looked at that.
This binding is maintained, pretty complete and very easy to use. Riak is also extremely easy to install.
Oak === This is a not so well known little side project from Nicolas Petton that I also am messing around with now. Oak is an "OODBish layer" that first was written abstractly to work on top of Riak, MongoDB etc. Now we are refocusing it on Riak only, possibly keeping optional Memcache support.
Oak uses two other very nice new technologies in Pharo: Fuel and Ghost. Fuel is well known, very good serialization library basically. Ghost is a new small library for making well behaving proxies, using a smarter approach than the old "subclass ProtoObject and implement #doesNotUnderstand:".
:) Hope to have a journal paper soon!
Net result is a semi transparent OODB which stores objects as Fuel blobs in Riak with UUIDs as keys. The auto faulting is done using Ghost proxies (so parts of your domain model are loaded "on demand" when you send messages to them). Oak is not super automagic like Magma - it doesn't do GC for example. But it is quite fast, small codebase and since it has a very simple model you can use other aspects of Riak through Phriak on the side.
Oak is live and kicking and we are improving it by the day. So consider it a very interesting alpha, but still, small and simple codebase so you can use it already if you are not afraid to get your hands dirty.
Yes, Oak is cool. We should continue with it! Cheers, -- Mariano http://marianopeck.wordpress.com
Yes, I'd really like to see Oak becoming more than a prototype. It requires more manpower though :) Nico Mariano Martinez Peck <marianopeck@gmail.com> writes:
On Tue, Dec 18, 2012 at 5:35 AM, Göran Krampe <goran@krampe.se> wrote:
Hey!
On 12/17/2012 07:08 PM, Torsten Bergmann wrote:
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list
to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have 2. What persistence is used in your Pharo application today 3. Which persistence solution you want to use/would you like to see in Pharo's future 4. What would you recommend.
I can give some light on a few options that I have been involved in:
TokyoTyrant =========== The "binding" I wrote hasn't been touched since I wrote it, but it is binary over SocketStream and VERY fast. There is now a new similar database called KyotoTycoon from the same author that he recommends as superior. Some differences:
http://stackoverflow.com/**questions/4178414/what-is-the-** difference-between-tokyo-**cabinet-and-kyoto-cabinet<http://stackoverflow.com/questions/4178414/what-is-the-difference-between-to...>
I am not using nor maintaining this library anymore though. Still the raw speed is amazing and if that is what you want then this one is hard to beat.
NOTE: Not sure how it operates under Pharo but since it runs on top of SocketStream I suspect it just works. If someone tries it out, let me know.
Phriak ====== This is a binding to Riak, perhaps the most insanely cool NoSQL database IMHO. Yeah, MongoDB is also very nice, but some aspects of Riak really makes me comfy and warm inside.
The binding was started by Runar Jordahl called "EpigentRiakInterface", then I did a friendly fork and improved it even more, and then Nicolas Petton joined and improved it LOTS more, and now lately Paul De Bruicker has also joined with commits.
Phriak is intentionally focused on Pharo and uses the Zinc components to implement the API which is HTTP based. Riak has protocol buffers too, but we haven't looked at that.
This binding is maintained, pretty complete and very easy to use. Riak is also extremely easy to install.
Oak === This is a not so well known little side project from Nicolas Petton that I also am messing around with now. Oak is an "OODBish layer" that first was written abstractly to work on top of Riak, MongoDB etc. Now we are refocusing it on Riak only, possibly keeping optional Memcache support.
Oak uses two other very nice new technologies in Pharo: Fuel and Ghost. Fuel is well known, very good serialization library basically. Ghost is a new small library for making well behaving proxies, using a smarter approach than the old "subclass ProtoObject and implement #doesNotUnderstand:".
:) Hope to have a journal paper soon!
Net result is a semi transparent OODB which stores objects as Fuel blobs in Riak with UUIDs as keys. The auto faulting is done using Ghost proxies (so parts of your domain model are loaded "on demand" when you send messages to them). Oak is not super automagic like Magma - it doesn't do GC for example. But it is quite fast, small codebase and since it has a very simple model you can use other aspects of Riak through Phriak on the side.
Oak is live and kicking and we are improving it by the day. So consider it a very interesting alpha, but still, small and simple codebase so you can use it already if you are not afraid to get your hands dirty.
Yes, Oak is cool. We should continue with it!
Cheers,
-- Mariano http://marianopeck.wordpress.com
-- Nicolas Petton http://nicolas-petton.fr
Am 17.12.2012 um 19:08 schrieb Torsten Bergmann <astares@gmx.de>:
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have
I like to add plain fuel. I store e.g. configurations with it as these change rarely. For reliability I applied a sequence file to it. Meaning I write files with .fl.1, .fl.2, etc. and a file seq containing the last written number extension. The mechanic is to first write the fuel file and then overwrite the seq file with the actual sequence number (if a write fails the seq file isn't changed). Reads are reading first the seq file and then the fuel file.
2. What persistence is used in your Pharo application today
GemStone, MongoTalk (maybe soon it will be voyage, too), Fuel, Sixx. And in testing phase riak (no phriak, yet).
3. Which persistence solution you want to use/would you like to see in Pharo's future
A decent implementation of LOOM. I think as long as there are different types of memory (main memory, disc storage,..) this is something nice to have.
4. What would you recommend.
Reify object references :) Norbert
participants (7)
-
Göran Krampe -
James Foster -
Mariano Martinez Peck -
Nicolas Petton -
Norbert Hartl -
Stéphane Ducasse -
Torsten Bergmann