Пользовательский UUID в качестве первичного ключа

Я читал о преимуществах и недостатках использования UUID в качестве первичного ключа в базе данных.

Главный аргумент, который я слышал против такой практики, заключается в том, что если они не генерируются последовательно, они могут фрагментировать ваши индексы и создавать проблемы с подкачкой страниц (я также слышал, что это приводит к уменьшению размера ваших баз данных, но давайте оставим это для сейчас).

MSSQL Server позволяет создавать последовательные UUID в базе данных с помощью пользовательского метода (например, CREATE TABLE MyUniqueTable(UniqueColumn UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID()).

Однако проблема в том, что он создает UUID, не соответствующий стандартам, который явно не является последовательным. Я разработал формат в обратном порядке и инкапсулировал его в класс строителя для использования или изучения:

/**
 * <p>
 * Reverse engineering effort to replicate how SQL Server creates ordered 
 * UUIDs so that we may construct them within the application. The builder will 
 * only accept version 1 and version 14 (Microsoft specific) uuid objects as a 
 * seed.
 * </p>
 * <p>
 * The algorithm is reversible so that a version 1 uuid may be created from a version
 * 14 uuid and vice versa.
 * </p>
 * @author Michael Lambert
 *
 */
public static class MsSqlOrderedUuidBuilder {

    private static final TimeBasedGenerator generator = Generators.timeBasedGenerator();

    private final UUID uuid;

    public MsSqlOrderedUuidBuilder(UUID uuid) {

        if(uuid.version() != 1 && uuid.version() != 14) {
            throw new IllegalArgumentException(String.format("UUID is not a version 1 UUID (version is %d)", uuid.version()));
        }
        this.uuid = uuid;
    }

    public MsSqlOrderedUuidBuilder() {
        this(generator.generate());
    }

    private long getMostSignificantBits() {

        ByteBuffer buffer = ByteBuffer.wrap(new byte[8]);

        buffer.putLong(uuid.getMostSignificantBits());
        buffer.rewind();

        byte[] timeLow = new byte[4];
        buffer.get(timeLow);

        byte[] timeMid = new byte[2];
        buffer.get(timeMid);

        byte[] timeHigh = new byte[2]; // time_high and version
        buffer.get(timeHigh);

        buffer.clear();

        buffer.order(buffer.order().equals(ByteOrder.LITTLE_ENDIAN) ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN);

        buffer.put(timeHigh);
        buffer.put(timeMid);
        buffer.put(timeLow);

        return buffer.getLong(0);
    }

    private long getLeastSignificantBits() {
        return uuid.getLeastSignificantBits();
    }

    public UUID build() {
        return new UUID(getMostSignificantBits(), getLeastSignificantBits());
    }
}

Если я попытаюсь использовать этот класс для хранения результирующих UUID в другой базе данных (мне также придется писать в MySQL), это не приведет к упорядочению, и я вернусь к своей первоначальной проблеме.

Моим решением было создать мой собственный обратимый пользовательский UUID, который при сериализации в байтовый массив последовательно упорядочивается:

/**
 * <p>
 * Creates a custom UUID type with sequential bytes. The builder must be seeded with a version 1 uuid and the
 * algorithm is reversible.
 * </p>
 * @author Michael Lambert
 *
 */
public static class SequentialUuidBuilder {

    private static final TimeBasedGenerator generator = Generators.timeBasedGenerator();

    private final UUID uuid;

    public SequentialUuidBuilder(UUID uuid) {

        if(uuid.version() != 1 && uuid.version() != 13) {
            throw new IllegalArgumentException(String.format("UUID is not a version 1 UUID (version is %d)", uuid.version()));
        }
        this.uuid = uuid;
    }

    public SequentialUuidBuilder() {
        this(generator.generate());
    }

    private long getVersion13MostSignificantBits() {

        if(uuid.version() == 1) {

            // System.out.println(String.format("original: %x", version1.getMostSignificantBits()));
            //
            // System.out.println(String.format("lowa %x", timeLowA));
            //
            // 0xAAAAA00000000000L
            // 0x0000000AAAAA0000L
            //
            long timeLowPartA = (uuid.getMostSignificantBits() & 0xFFFFF00000000000L) >>> 28;
            //
            // 0x00000BBB00000000L
            // 0x0000000000000BBBL
            //
            long timeLowPartB = (uuid.getMostSignificantBits() & 0x00000FFF00000000L) >>> 32;
            //
            // System.out.println(String.format("lowb %x", timeLowB));
            //
            // 0x00000000MMMM0000L
            // 0x000MMMM000000000L
            //
            long timeMid = (uuid.getMostSignificantBits() &  0x00000000FFFF0000L) << 20;
            //
            // System.out.println(String.format("med %x", (timeMid)));
            //
            // 0x0000000000000HHHL
            // 0xHHH0000000000000L
            //
            long timeHigh = (uuid.getMostSignificantBits() & 0x0000000000000FFFL) << 52;
            //
            // System.out.println(String.format("high %x", timeHigh));
            //
            // 0x000000000000V000L
            // 0x000000000000V000L
            //
            // long version = (version1.getMostSignificantBits() &  0x000000000000F000L);
            //
            // System.out.println(String.format("version %x", version));
            //
            // 0x0000000AAAAA0000L
            // 0x0000000000000BBBL
            // 0x000MMMM000000000L
            // 0xHHH0000000000000L
            // 0x000000000000V000L <-- we don't change where the version is stored because we want to respect that part of the spec
            // ____________________
            // 0xHHHMMMMAAAAAVBBBL
            //
            long ordered = timeLowPartA | timeLowPartB | timeMid | timeHigh | 0x000000000000D000L; // custom version

            return ordered;
        }
        return 0;
    }

    public long getVersion1MostSignificantBits() {
        //
        // 0xHHHMMMMAAAAAVBBBL
        //
        long timeLowPartA = (uuid.getMostSignificantBits() & 0x0000000FFFFF0000L) << 28;
        long timeLowPartB = (uuid.getMostSignificantBits() & 0x0000000000000FFFL) << 32;
        long timeMid = (uuid.getMostSignificantBits() &  0x000FFFF000000000L) >> 20;
        long timeHigh = (uuid.getMostSignificantBits() & 0xFFF0000000000000L) >> 52;
        //
        // 0xAAAAA00000000000L
        // 0x00000000MMMM0000L
        // 0x00000BBB00000000L
        // 0x0000000000000HHHL
        // 0x000000000000V000L
        // ___________________
        // 0xAAAAABBBMMMMVHHHL
        //
        long bits = timeLowPartA | timeLowPartB | timeMid | timeHigh | 0x0000000000001000L; // reinstate version

        return bits;
    }

    private long getMostSignificantBits() {
        return (uuid.version() == 13) ? getVersion1MostSignificantBits() : getVersion13MostSignificantBits();
    }

    private long getLeastSignificantBits() {
        return uuid.getLeastSignificantBits();
    }

    public UUID build() {
        return new UUID(uuid.version() == 13 ? getVersion1MostSignificantBits() : getMostSignificantBits(), getLeastSignificantBits());
    }
}

МОЙ ВОПРОС: это приемлемая практика? Могу ли я использовать BINARY(16) для хранения первичного ключа, и можно ли использовать собственный идентификатор таким образом?

Спасибо всем заранее. Vive la Stackru!

1 ответ

Используйте генератор последовательности, если вам действительно не нужны ваши ключи, чтобы быть универсально уникальными.

Другие вопросы по тегам