Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research. I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. Thanks a lot in advance, -- Mariano http://marianopeck.wordpress.com
Mariano, On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
I do not understand. IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ? As you most probably know, you can get pretty far with Pharo. After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does. You will always find more tools and libraries on the Pharo side, as the community is much larger. Sven
Thanks a lot in advance,
-- Mariano http://marianopeck.wordpress.com
I am also asking myself the same questions. But there are ways to achieve it all with Pharo I think. It may require more shuffling of data but it can be done. Especially when looking at the problems with uncoupling the parts (like I do here w/ RabbitMQ and Stamp). Much easier to use services (returning json or Ston (better)) to load user views on data. Not as nice as pure OO everywhere but still very productive. Phil On Wed, Oct 2, 2013 at 9:42 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Mariano,
On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
I do not understand.
IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ?
As you most probably know, you can get pretty far with Pharo. After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does.
You will always find more tools and libraries on the Pharo side, as the community is much larger.
Sven
Thanks a lot in advance,
-- Mariano http://marianopeck.wordpress.com
On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Mariano,
On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
I do not understand.
IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ?
More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well....
As you most probably know, you can get pretty far with Pharo.
Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high.
After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does.
Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo.
You will always find more tools and libraries on the Pharo side, as the community is much larger.
Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same. Thanks for the discussion! -- Mariano http://marianopeck.wordpress.com
Mariano why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? Of course Pharo is limited and I hope that with the new Cog it will be different but soon it will not fit in the ram of your OS. Stef
On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Mariano,
On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
I do not understand.
IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ?
More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well....
As you most probably know, you can get pretty far with Pharo.
Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high.
After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does.
Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo.
You will always find more tools and libraries on the Pharo side, as the community is much larger.
Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same.
Thanks for the discussion!
-- Mariano http://marianopeck.wordpress.com
On Wed, Oct 2, 2013 at 5:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Mariano
why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb?
Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then.
Of course Pharo is limited and I hope that with the new Cog
Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing.
it will be different but soon it will not fit in the ram of your OS.
Stef
On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Mariano,
On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
I do not understand.
IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ?
More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well....
As you most probably know, you can get pretty far with Pharo.
Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high.
After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does.
Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo.
You will always find more tools and libraries on the Pharo side, as the community is much larger.
Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same.
Thanks for the discussion!
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Oct 2, 2013, at 10:24 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Wed, Oct 2, 2013 at 5:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Mariano
why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb?
Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then.
Indeed so you will have to find a real solution to manage your data and having a large database in memory may not be the way to go.
Of course Pharo is limited and I hope that with the new Cog
Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing.
it will be different but soon it will not fit in the ram of your OS.
Stef
On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Mariano,
On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
I do not understand.
IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ?
More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well....
As you most probably know, you can get pretty far with Pharo.
Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high.
After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does.
Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo.
You will always find more tools and libraries on the Pharo side, as the community is much larger.
Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same.
Thanks for the discussion!
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Wed, Oct 2, 2013 at 5:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
On Oct 2, 2013, at 10:24 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Wed, Oct 2, 2013 at 5:13 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Mariano
why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb?
Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then.
Indeed so you will have to find a real solution to manage your data and having a large database in memory may not be the way to go.
Yes, I will probably need quite a lot of data in memory for a very particular use-cases. Still, notice still 5GB or 10GB is way less than my server, which has 32GB.
Of course Pharo is limited and I hope that with the new Cog
Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing.
it will be different but soon it will not fit in the ram of your OS.
Stef
On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Mariano,
On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
I do not understand.
IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ?
More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well....
As you most probably know, you can get pretty far with Pharo.
Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high.
After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does.
Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo.
You will always find more tools and libraries on the Pharo side, as the community is much larger.
Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same.
Thanks for the discussion!
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
participants (4)
-
Mariano Martinez Peck -
phil＠highoctane.be -
Stéphane Ducasse -
Sven Van Caekenberghe