OK, I finally got to this point in design and production.
I generate a COMB_GUID where the upper 32 bits are based on the bits 33
through 1 of Unix time in milliseconds. So, there are 93 bits of randomness
every 2 milliseconds and the rollover on the upper bits happnes every 106
When inserting in postgres the ratio of speed between a fully random UUID
and a COMB _GUID holds as beneficial for the COMB_GUID.
The COMB_GUID is 2X faster.
In ElasticSearch, there is NO discernible difference between the two for
indexing. I'm still going to use COMB_GUIDS in case content goes to BTREE
indexes anywhere in the chain as if the content is fed time related, or can
be presorted on the id field so that it IS timer related and partially
sequential, it will speed up.
On Monday, May 14, 2012 7:00:42 PM UTC-7, Dennis wrote:
Anyone ever looked at the indexing (i.e. INSERTing in database parlance)
speed using the random generated uuids or COMB uuids in ElasticSearch?
There are also string equivalent, and base 64 equivalents. I may try a
simple bash script and see what happens.
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.