New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic UUID/GUIDs for better performance #15518
Comments
hi You can replace the |
@maliming I'm talking about replacing GUID's enterily, with any variable-coding capable ID format. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@yuriy-yarosh You can create Store Procedure name next_uuid as I do. This code work as ULID with data type is uuid. modelBuilder.Entity<ResCompany>(entity => Or you replace default IGuidGenerator with your own: public override void ConfigureServices(ServiceConfigurationContext context) I used in my project BambooERP |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Description
GUID Generation Documentation clearly says that:
There's nothing wrong with the GUID's themselves it's just they're causing RDBMS Index Bloat and inherent perf degration during index traversal. Is it possible to implement a custom GUID mapping, on top of EF Core, for Dynamic GUID Sizing ?
People do often consider ULIDs to be a better replacement, and most of the existing benchmarks show that this actually can be a perf limitation fairly often, alongside with the entropy pool leaks.
Analysis
I do like the way instagram handles their complex PKey / uuid situation with constrained 64bit keys, and I find it the most performant and flexible approach.
From DBA side of things there are really clever ways to handle such cases, even if it means extending the database engine directly. At the framework side, such issues perceived as non-critical, even if it literally means speeding up inserts about 10x times and reducing the indices about 3x times.
The text was updated successfully, but these errors were encountered: