[Glass] Question about mapping my DBs to separate extents

Jon Paynter kittle31 at gmail.com
Fri Jun 27 16:40:31 PDT 2014


How much data are you trying to transfer? .. a few MB? or hundreds of GB?

If its something that needs doing often, you may want to write some custom
export / import code.  If its a 1-time operation, then Dale's method would
work good.


On Fri, Jun 27, 2014 at 3:28 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Mariano,
>
> I don't think that multiple extents is quite what you are looking for ...
> extents do not partition user data then simply allow you to map your data
> base across multiple spindles and/or make it possible to bring up multiple
> aio pageservers to keep up with the creation of dirty pages in the SPC ...
>
> If you want to share large amounts of data between reach user stone, then
> I think you might consider using multiple gemstone users in a single stone
> ... you can arrange to isolate the data that should not be accessible to
> other users and you can arrange that the shared data can be seen and shared
> by all of the users ... the code itself can also be managed in the same way
> ...
>
> I don't know of any really efficient ways of sharing huge object graphs
> between stones I think that solutions can be built from a number of
> different angles, ...
>
> Why are you finding the need to move this data ... are you moving a user
> account from one stone to another or is it more along the lines of creating
> a new stone to manage the size of the repository?
>
> If you are doing a transplant, you might consider copying an extent and
> then pruning out all of the data that you don't want moved and leave only
> the data that you want to keep ... this technique doesn't allow for updates
> of existing structure or merging one structure with another structure in a
> single stone ...
>
> Dale
>
>
>
> On Fri, Jun 27, 2014 at 2:58 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> HI guys,
>>
>> First, let me explain my scenario a bit. I have multiple "databases"
>> (say, clientsDB, transctionsDB, etc) for one site (one deployed version of
>> the app). Each site (I may have a few sites) has a separate stone. Each
>> stone as a main dict in the user list, whose keys and values are these
>> databases. Each database is (at the end) almost like a normal dictionary.
>> Each database is isolated from the rest from the "references/pointers"
>> point of view. So for example they could be serialized and moved to other
>> site and materialized there without problems.
>>
>> The problem I am facing now is that I want to move  these DBs from one
>> stone to another. Right now I am using SIXX, but it is very very slow, and
>> it has a very low limit in which it doesn't scale more. My DBs are larger
>> than what SIXX can handle.
>>
>> I was reading about PassiveObject but I was disappointed by its
>> limitations and that the fact that it is text-based. So I guess I will have
>> almost the same limits as I have now with SIXX.
>>
>> Then I thought about GemStone extents. So what if instead of having the
>> whole site on the same extent, each DB is placed on a different extent?
>> That way, possibly, each of the DB of a site could be in a separate file.
>> This makes very very easy to move a DB from one site to another and very
>> performant since I am using gemstone format directly.
>>
>> So...before experimenting more with this idea...how does it sound?
>> Possible?
>>
>> Any other possibility to solve my problem?
>>
>> Thanks in advance,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140627/cba85731/attachment.html>


More information about the Glass mailing list