[db] Improve performance of DBUserStorageResource.update(...) #3151
Conversation
geropl
force-pushed
the
gpl/fix-update-res
branch
from
e978b45 to
c0f5b95
Compare
| export class UserStorageUserIdChar1612781029090 implements MigrationInterface { | ||
|
|
||
| public async up(queryRunner: QueryRunner): Promise<any> { | ||
| await queryRunner.query("ALTER TABLE d_b_user_storage_resource MODIFY userId char(36);"); |
There was a problem hiding this comment.
is it a problem?
changing userId varchar(255) to fixed char(36) sound like there is some risk.
There was a problem hiding this comment.
is it a problem?
Yes, it is for the lookup performance. The DB cannot assume that the 219 characters that are always blank. Ideally they all end up in one leaf of the Red-Black-tree but one never know. Also, it blows up the memory used up by the index.
changing userId varchar(255) to fixed char(36) sound like there is some risk.
There is no risk to break something as we never used anything else than UUIDs (36 characters), and we're maintaining that limit with the current id change.
During deployment however this might be a problem as it might take some time because it requires re-creating indexes.
|
Just tested. Works fine. |
geropl
changed the title
geropl
force-pushed
the
gpl/fix-update-res
branch
from
c0f5b95 to
c05795b
Compare
geropl
changed the title
…-io#3151) * [db] UserStorageResource: make userId char(36) instead of varchar(255) * [db] Use INSERT INTO ... ON DUPLICATE KEY UPDATE for user storage
This does improve the performance of
update(...)onUserStorageResourceDBImplby:char(36)for userId instead ofvarchar(255)INSERT INTO ... ON DUPLICATE KEY UPDATEinstead of the update logic in the clientNote: The type change will trigger a index re-build and should be initiated offline.