On Wed, Oct 2, 2013 at 5:29 PM, Stéphane Ducasse <[email protected]>wrote:
> > 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. > > 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 <[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 > > > -- Mariano http://marianopeck.wordpress.com
