[Glass] Large collection and common practice

[Smalltalk via Glass]

John,

The UUID can not be changed because is a data created in a Java 
application passed to GemStone as a parameter in a service.

regards

bruno


El 04/01/2017 a las 11:29, John McIntosh via Glass escribió:
> Although UUID are used as unique keys, I find them to be rather 
> wasteful, and it takes time to hash, etc.
>
> In a number of application I have found that pulling a 64bit 
> cryptographically random number, checking for uniqueness before use, 
> and if so using it as a primary 64 bit integer key reduces bloat and 
> just better for most access operations.
>
> On Wed, Jan 4, 2017 at 6:23 AM, Smalltalk via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>     Dale,
>
>     Is there any measure of from what size a Dictionary could have
>     this problem ? Maybe it also depends in the length of the key...
>
>     (if the problem arise from 1.000.000 entries in a dictionary -->
>     is not a problem for me right now)
>
>     The keys of my Dictionary is an UUID like:
>     93b1205cec32b42993b9382a9b0d89046fd937c8
>
>     At this stage i think i will use 2 Rc collections (one dictionary
>     + one bag) in the future maybe this approach has to be changed...
>
>     For now i will keep it simple !
>
>     regards
>
>     bruno
>
>     El 03/01/2017 a las 17:46, Dale Henrichs escribió:
>
>
>         As the size of the collections gets very large, you have to
>         keep in mind that Dictionary-based structures have to be
>         rebuilt periodically to keep the collision bucket size
>         manageable and some of the dictionaries like
>         RcKeyValueDictionary will rebuild automatically on insertion
>         and depending upon the size of the dictionary that could lead
>         to long and unpredictable delays for end users ... the btree
>         structures used in GemStone indexes do splits and merges on
>         individual leaf nodes limiting the cost of insertions ...
>
>
>
>     ---
>     El software de antivirus Avast ha analizado este correo
>     electrónico en busca de virus.
>     https://www.avast.com/antivirus <https://www.avast.com/antivirus>
>
>
>     _______________________________________________
>     Glass mailing list
>     Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>     http://lists.gemtalksystems.com/mailman/listinfo/glass
>     <http://lists.gemtalksystems.com/mailman/listinfo/glass>
>
>
>
>
> -- 
> ===========================================================================
> John M. McIntosh. Corporate Smalltalk Consulting Ltd 
> https://www.linkedin.com/in/smalltalk
> ===========================================================================
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass



---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170104/4f3091a5/attachment-0001.html>