[0.9][BC break][dbal] Store UUIDs as binary data. Improves performance #280
Conversation
|
|
|
@dkarlovi thank you for sharing this. Unfortunately it requires |
pkg/dbal/DbalProducer.php
Outdated
| throw new \LogicException('The generated uuid is empty'); | ||
| } | ||
| $hasNativeGuid = $this->context->getDbalConnection()->getDatabasePlatform()->hasNativeGuidType(); | ||
| $uuid = Uuid::uuid4(); |
There was a problem hiding this comment.
Why not Uuid::uuid1()? It is more efficient for the database to index a time-based UUID than a random v4 UUID.
There was a problem hiding this comment.
Honestly, I dont know I've been using uuid4 everywhere. I'll look into it.
Thanks.
There was a problem hiding this comment.
good write up on this https://www.sohamkamani.com/blog/2016/10/05/uuid1-vs-uuid4/
There was a problem hiding this comment.
@makasim check the link from Percona linked in my comment.
There was a problem hiding this comment.
@dkarlovi yeah, I saw it. Unfortunately I am not sure we can adopt it since it is MySQL\InnoDB specific stuff. We have to support or DBAL transport hence the solution should be flexible enough to work on all of those platforms
There was a problem hiding this comment.
No, I meant the influence of random on performance. v1 vs v4 should be considered here IMO.
|
@dkarlovi updated PR with uuid1 and the use of time ordered codec. |
|
Publish and consume 100 000 messages enqueue/dbal 0.8 Publish took 80.730087995529 seconds, 40.152kb memory enqueue/dbal 0.9 Publish took 74.140038013458 seconds, 191.248kb memory It turned out that the difference is not that big. |
[0.9][BC break][dbal] Store UUIDs as binary data. Improves performance
fixes #279
fixes #276