Forem: Ban Duong

The Evolution of UUIDs: How v7 Improves Database Efficiency

Ban Duong — Sat, 22 Feb 2025 10:47:45 +0000

What is a UUID?
UUID Format and Generation Methods
Comparing UUID v1, v4, and v7
How UUID v4 and UUID v7 Affect Databases
- Understanding B-Tree Indexing
- Page Splits in B-Trees
Why UUID v4 Causes Fragmentation and Cache Inefficiency
- Example of UUID v4 Inserts
- How Random Writes Lead to Cache Inefficiency
Why UUID v7 is Better for Databases
- Example of UUID v7 Inserts
- Comparison of UUID v4 vs UUID v7 in Databases
Conclusion
- TL;DR
- Long Version

1. What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit unique identifier used in computing and data management. It ensures global uniqueness without requiring a central authority, making it ideal for distributed systems.

UUIDs are commonly used in:

Databases (as primary keys to uniquely identify records).
Distributed systems (ensuring uniqueness across multiple nodes).
Session tracking (assigning unique session IDs for users).
Transaction identifiers (maintaining consistency in financial systems).

2. UUID Format and Generation Methods

A UUID is represented as a 36-character string with a standardized format:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

M → UUID version (1, 4, 7, etc.).
N → Variant (typically 8, 9, A, or B).
Other parts contain timestamps, random values, or hashed data, depending on the UUID version.

How UUIDs Are Generated

UUIDs can be created using different methods:

Time-based (e.g., UUID v1, UUID v7) → Uses timestamps, sometimes combined with MAC addresses or randomness.
Random (e.g., UUID v4) → Generated using a random number generator.
Hash-based (e.g., UUID v3, UUID v5) → Generated using hashes of fixed input values.

3. Comparing UUID v1, v4, and v7

Feature	UUID v1 (Timestamp + MAC)	UUID v4 (Random)	UUID v7 (Timestamp + Random)
Generation Method	Time-based + MAC address	Fully random	Time-based + Random
Uniqueness	High (MAC ensures uniqueness)	High (randomized)	High (timestamp + random)
Sortability	❌ Mostly ordered, but has imperfections	❌ Not sortable	✅ Fully sequential
Database Performance	❌ Causes minor fragmentation due to timestamp format	❌ Random inserts (poor indexing)	✅ Optimized for indexing
Privacy	❌ MAC address is exposed	✅ Secure	✅ Secure
Use Case	Legacy systems	General purpose, distributed systems	Databases, logs, event tracking

4. How UUID v4 and UUID v7 Affect Databases

1. Understanding B-Tree Indexing

Most relational databases (like MySQL InnoDB, PostgreSQL, and SQLite) use B-Tree indexes to organize primary keys efficiently.

How B-Trees Work

A B-Tree is a self-balancing tree structure where nodes store multiple sorted keys.
When searching for a key (like a UUID), the database traverses the tree from root to leaf.
Since data is sorted, operations like searching, inserting, and deleting run in O(log n) time complexity.

2. Page Splits in B-Trees

Each node (page) has a fixed size (e.g., 16KB in MySQL InnoDB).
When a new key is inserted in sorted order, it usually fits into an existing page.
But if the page is full, the database splits it into two new pages, increasing fragmentation.

5. Why UUID v4 Causes Fragmentation and Cache Inefficiency

UUID v4 is fully random, meaning:

New inserts land anywhere in the index, not in a predictable order.
The database must modify different pages, causing frequent page splits and fragmentation.
Queries on recent records require loading multiple scattered pages, making caching inefficient.

Example of UUID v4 Inserts

Imagine a B-Tree index with 4 pages, each storing sorted UUIDs:

Page 1: [ UUID1 | UUID5 | UUID8 | UUID12 ]  
Page 2: [ UUID15 | UUID18 | UUID22 | UUID26 ]  
Page 3: [ UUID30 | UUID35 | UUID40 | UUID45 ]  
Page 4: [ UUID50 | UUID55 | UUID60 | UUID65 ]

Now, inserting a random UUID v4 (UUID33):

It lands between UUID30 and UUID35 in Page 3.
If Page 3 is full, the database splits it into two pages.
More inserts increase fragmentation, making reads slower.

How Random Writes Lead to Cache Inefficiency

Databases store frequently accessed pages in memory (buffer pool).
But since UUID v4 spreads inserts randomly, each query loads different pages, constantly evicting older pages.
This leads to more disk I/O and poorer cache performance.

6. Why UUID v7 is Better for Databases

UUID v7 solves the fragmentation issue because:

The first 48 bits are a timestamp, making it sequentially ordered.
The last 80 bits are random, ensuring uniqueness.
New inserts always go to the last page in a B-Tree index, avoiding fragmentation.

Example of UUID v7 Inserts

Page 1: [ UUID1 | UUID5 | UUID8 | UUID12 ]  
Page 2: [ UUID15 | UUID18 | UUID22 | UUID26 ]  
Page 3: [ UUID30 | UUID35 | UUID40 | UUID45 ]  
Page 4: [ UUID50 | UUID55 | UUID60 | UUID65 ]  
Page 5: [ UUID70 | UUID75 | UUID80 | UUID85 ]  ← New inserts go here

Since new entries always append to the last page:

Fewer page splits → Less fragmentation → Faster inserts.
Queries on recent data remain in memory → Better cache performance.

Comparison of UUID v4 vs UUID v7 in Databases

Factor	UUID v4 (Random Inserts)	UUID v7 (Sequential Inserts)
Write Pattern	Inserts anywhere, causing fragmentation	Writes append to the last page
Page Splits	❌ Frequent, due to random insert locations	✅ Rare, only when last page is full
Cache Efficiency	❌ Poor – random pages evicted frequently	✅ High – recent data stays in memory
Query Performance	❌ Slow – queries require loading multiple pages from disk	✅ Fast – queries read from cached pages

7. Conclusion

TL;DR

Why UUID v4 is inefficient:

Random inserts cause index fragmentation and frequent page splits.
Sequential queries suffer, requiring multiple page fetches.
Cache performance drops, as pages are constantly replaced.

Why UUID v7 is better:

Sorted inserts lead to fewer page splits.
Faster sequential reads, as queries load a single page.
Recent data remains in memory, improving database performance.

Long Version

Why UUID v4 is Inefficient

1. Random Inserts Cause Index Fragmentation

UUIDv4 values are completely random, meaning new entries can be inserted anywhere in the B-Tree index. This leads to data fragmentation, as records are scattered across different pages instead of being grouped together.

2. Frequent Page Splits Increase Write Overhead

When a UUID v4 is inserted into a full page, the database must split the page to make room for new values. Since inserts happen randomly, page splits occur more frequently, increasing the database's workload and reducing efficiency.

3. Poor Sequential Read Performance

Because UUID v4 values are unordered, reading a range of UUIDs requires fetching data from multiple non-contiguous pages. This results in:

More disk I/O, slowing down queries.
Inefficient caching, as different pages are loaded into memory instead of reusing recently accessed ones.

Why UUID v7 is Better

1. Sequential Inserts Improve Write Performance

UUID v7 is sorted by timestamp, meaning new values are always appended to the latest page. This results in:

Fewer random writes, reducing fragmentation.
Minimal page splits, since new entries naturally go to the end of the index.

2. Faster Sequential Reads

Since UUID v7 values are stored in increasing order, sequential queries can retrieve data from a single page or adjacent pages, making range scans much faster.

3. Better Cache Efficiency

With UUID v7, recent data remains in memory longer because:

New records are appended rather than scattered.
Queries accessing recent entries will likely hit cached pages, reducing disk reads and improving performance.

[Java] Overriding and Hiding

Ban Duong — Sun, 28 Apr 2024 08:44:08 +0000

Context

In Java, static methods can't be overridden. But in a child class, we can still have the same static method as in the parent class, and the compiler doesn't throw any error about that. In this case, it's not called method overriding; it's called method hiding.

public class Parent {

    public static void staticMethod() {
        System.out.println("Static method of parent class");
    }

    public void instanceMethod() {
        System.out.println("Instance method of parent class");
    }
}

public class Child extends Parent {

    public static void staticMethod() {
        System.out.println("Static method of child class");
    }

    @Override
    public void instanceMethod() {
        System.out.println("Instance method of child class");
    }

}

public class App {

    public static void main(String[] args) {
        Parent p = new Child();
        //it invokes an instance method of the child class
        p.instanceMethod();
        //it invokes a static method of the parent class
        p.staticMethod();
    }
}

What is the difference?

1.Overriding

Let's take a look at the above example. We can see that the Child class has overridden the 'instanceMethod' in the Parent class. So when we invoke 'p.instanceMethod()', it invokes the method in the Child class instead of the method in the Parent class. This is called polymorphism. Although we declare the variable 'p' with the declared type Parent, we create it as a Child. So, at runtime, the JVM (Java Virtual Machine) finds that 'p' is a Child instance, and it will invoke the method in Child.

2.Hiding

Unlike with overriding, when we invoke 'p.staticMethod()', it invokes the method in the Parent class instead of the Child class. So, what happens here? The static method is resolved at compile time, not at runtime, so it can't exhibit polymorphism. At compile time, 'p' is seen as a Parent instance, while 'p' is only seen as a Child instance at runtime.

Conclusion

We can't override a static method, so when invoking a static method, instead of using 'p.staticMethod()', which can lead to confusion, we should use 'Parent.staticMethod()' or 'Child.staticMethod()' to provide clearer clarification.

[Java] Singleton and Static

Ban Duong — Thu, 18 Apr 2024 17:18:40 +0000

Context

Both the singleton pattern and the static keyword are concepts that involve shared resources within an application. But when should we use each of them? This article aims to provide clarity on this matter.

What is singleton pattern?

The singleton pattern is one of the common design patterns. It ensures that the class has only one instance created. For example, we only need one instance when using a logger or accessing the configuration of the application.

public class Logger {
    private static Logger instance;

    private Logger() {
        // Private constructor to prevent instantiation outside this class
    }

    public static Logger getInstance() {
        if (instance == null) {
            instance = new Logger();
        }
        return instance;
    }

    public void log(String message) {
        System.out.println("[LOG] " + message);
    }
}

What is static keyword in Java?

In Java, the static keyword can be used for variables, methods, and classes.

With static variables and methods, it means these entities belong to the class itself rather than to individual objects. They can be accessed through the class without the need to create an instance.

Regarding static classes, only nested classes can be static; the outer class cannot be static. However, a common use case is to make the class final and have static methods inside it.

public final class Utility {

    public static final int num = 10;

    public static void doSomething() {
    }
}

So which one we should use?

1.Initialization

If initialization is required for an instance, we should use a singleton because it allows initialization in the singleton constructor, while static methods provide straightforward access without initialization. Conversely, if initialization is not needed, we can use a static class because it simplifies the code and offers better performance due to static binding at compile time.

Example of the singleton approach

public class Logger {
    private static Logger instance;
    private PrintWriter writer;

    private Logger() {
        try {
            writer = new PrintWriter(new FileWriter("log.txt", true));
            writer.println("Log file initialized.");
            writer.flush();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static Logger getInstance() {
        if (instance == null) {
            instance = new Logger();
        }
        return instance;
    }

    public void log(String message) {
        writer.println(message);
        writer.flush();
    }
}

Example of the static approach

public class Logger {
    private static PrintWriter writer;

    static {
        try {
            writer = new PrintWriter(new FileWriter("log.txt", true));
            writer.println("Log file initialized.");
            writer.flush();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void log(String message) {
        writer.println(message);
        writer.flush();
    }
}

In the static approach, the 'writer' isn't initialized in the constructor method; instead, it's initialized in a static block and will be created when the class is loaded. In the singleton approach, the 'writer' is initialized in the constructor method and is created when we call the getInstance method.

2.Extension

With singletons, we can utilize inheritance and polymorphism to extend a base class, implement an interface, and provide different implementations through method overriding. However, static methods cannot be overridden since their resolution occurs at compile time rather than runtime.

class Animal {
    void makeSound() {
        System.out.println("Animal makes a sound");
    }

    static void eat() {
        System.out.println("Animal eats");
    }
}

class Dog extends Animal {
    // Overriding the makeSound method
    @Override
    void makeSound() {
        System.out.println("Dog barks");
    }

    // Hiding the eat method (not overriding)
    static void eat() {
        System.out.println("Dog eats bones");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal animal = new Animal();
        Animal dog = new Dog();

        // Calling non-static method, resolved at runtime
        animal.makeSound(); // Output: Animal makes a sound
        dog.makeSound();    // Output: Dog barks (method overridden)

        // Calling static method, resolved at compile time
        Animal.eat(); // Output: Animal eats
        Dog.eat();    // Output: Dog eats bones (method hidden)
    }
}

3.Loading

Singletons can be initialized via lazy loading, while static classes are initialized during the first load.

Let's use the example in section one: Initialization. In the singleton approach, the 'writer' will only be created when the constructor method is invoked through the getInstance method. This means if we haven't used the Logger instance yet, it won't be initialized. However, with the static approach, the 'writer' will be created when the class is loaded.

4.Managing State

Singletons are a better option when state management is required because they offer control over initialization and finalization, which static classes do not provide.

Example of the singleton approach

public class DatabaseConnection {
    private static DatabaseConnection instance;
    private boolean isConnected;

    private DatabaseConnection() {
        isConnected = false;
    }

    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }

    public void connect() {
        isConnected = true;
        System.out.println("Connected to database");
    }

    public void disconnect() {
        isConnected = false;
        System.out.println("Disconnected from database");
    }
}

Example of the static approach

public class DatabaseConnection {
    private static boolean isConnected;

    private DatabaseConnection() {}

    public static void connect() {
        isConnected = true;
        System.out.println("Connected to database");
    }

    public static void disconnect() {
        isConnected = false;
        System.out.println("Disconnected from database");
    }
}

In a static approach, everything from methods to variables needs to be static as well. This makes it less encapsulated, and it doesn't have an instance state to manage because static variables belong to the class itself, not the instance. With a singleton, we can control initialization and finalization at runtime, but with static, it's automatically created when the application starts and only destroyed when the application exits.

Conclusion

If the purpose is a class with utility functions, requiring no state or initialization, opt for a static class. Otherwise, if state management or initialization is necessary, choose a singleton instead.

Forem: Ban Duong

The Evolution of UUIDs: How v7 Improves Database Efficiency

Table of Contents

1. What is a UUID?

2. UUID Format and Generation Methods

How UUIDs Are Generated

3. Comparing UUID v1, v4, and v7

4. How UUID v4 and UUID v7 Affect Databases

1. Understanding B-Tree Indexing

How B-Trees Work

2. Page Splits in B-Trees

5. Why UUID v4 Causes Fragmentation and Cache Inefficiency

Example of UUID v4 Inserts

How Random Writes Lead to Cache Inefficiency

6. Why UUID v7 is Better for Databases

Example of UUID v7 Inserts

Comparison of UUID v4 vs UUID v7 in Databases

7. Conclusion

TL;DR

Why UUID v4 is inefficient:

Why UUID v7 is better:

Long Version

Why UUID v4 is Inefficient

1. Random Inserts Cause Index Fragmentation

2. Frequent Page Splits Increase Write Overhead

3. Poor Sequential Read Performance

Why UUID v7 is Better

1. Sequential Inserts Improve Write Performance

2. Faster Sequential Reads

3. Better Cache Efficiency

[Java] Overriding and Hiding

Context

What is the difference?

1.Overriding

2.Hiding

Conclusion

[Java] Singleton and Static

Context

What is singleton pattern?

What is static keyword in Java?

So which one we should use?

1.Initialization

2.Extension

3.Loading

4.Managing State

Conclusion