On Oct 2, 2013, at 10:24 PM, Mariano Martinez Peck <[email protected]> wrote:
> > > > On Wed, Oct 2, 2013 at 5:13 PM, Stéphane Ducasse <[email protected]> > 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 <[email protected]> wrote: >> Mariano, >> >> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <[email protected]> >> 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
