Преимущества Cassandra UUID против TimeUUID и недостатки

Ответ 1

UUID и TIMEUUID сохраняются одинаково в Cassandra, и они действительно представляют собой две различные реализации сортировки.

TIMEUUID сначала сортируются по их компонентам времени, а затем по их сырым байтам, тогда как столбцы UUID сначала сортируются по их версии, тогда, если оба являются версией 1 по их временной составляющей и, наконец, их сырой байт. Любопытно, что реализации сортировки компонентов времени дублируются между UUIDType и TimeUUIDType в коде Cassandra, за исключением различного форматирования.

Я думаю о вопросе UUID vs. TIMEUUID в первую очередь как о документации: если вы выберете TIMEUUID, вы говорите, что вы храните вещи в хронологическом порядке и что эти вещи могут происходить одновременно, поэтому простой временной метки недостаточно. Использование UUID говорит, что вы не заботитесь о заказе (даже если на практике столбцы будут упорядочены по времени, если вы поместите в них UUID версии 1), вы просто хотите убедиться, что у вещей есть уникальные идентификаторы.

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

Вероятно, это не имеет большого значения в великой схеме вещей, но сортировка UUID не-версии 1 немного быстрее, чем версия 1, поэтому, если у вас есть столбец UUID и сгенерируйте UUID самостоятельно, перейдите к другой версии.

Ответ 2

A TimeUUID является простым старым UUID в соответствии с документацией.

A UUID - это просто 128-битное значение. Подумайте об этом как о невообразимо большом количестве.

Конкретные биты могут быть определены любым из нескольких методов. оригинальный метод включал в себя MAC-адрес компьютерной сети аппаратное обеспечение, сочетающее текущую дату и время, а также произвольное число и случайное число. Сбросьте все это, чтобы получить практически уникальный номер.

Позже по различным причинам (безопасность, конфиденциальность) были изобретены другие методы для сборки битов при генерации значения UUID. Эти другие методы опускают дату-время и/или MAC-адрес в качестве ингредиента. Дело в том, что не все значения UUID имеют встроенное значение даты.

Документ Cassandra неправильно ссылается на свой TimeUUID как "UUID типа 1". Правильный термин - UUID версии 1. Эта версия иногда называется "временной версией".

Немного о совете

Кажется, что Кассандра идентифицирует эту конкретную версию UUID с целью извлечения части времени и времени из 128 бит. Извлечение даты-времени из UUID является плохой идеей.

С одной стороны, UUID никогда не собирался использоваться для такого отслеживания истории. Действительно, спецификация для UUID специально признает, что (а) компьютерные часы могут быть reset и поэтому (b) UUID, сгенерированные позже, могут фактически записать более раннее время-время, чем предыдущие UUID. Другая причина не извлекать дату-время из UUID - это то, что у вас могут быть UUID, которые не были созданы методом времени, поэтому вы будете строить значение времени данных на основе бит, которые на самом деле не представляют дату-время творения. Третья причина заключается в том, что при повторном рефинансировании кода программирования UUID может быть сгенерирован в другое время, чем запись базы данных, поэтому использование даты UUID будет вводить в заблуждение.

Если вам нужно отслеживать историю дат, сделайте это явно. Создайте в ваших данных поле даты и времени. Кстати, отслеживайте это время в UTC, но это другая тема.

Ответ 3

Все сказали, вам нужно создать кого-то, чтобы поверить им. Timeuuids являются версией/уровнем 1 UUID только кажутся рандомизацией первых 8 символов, как вы можете видеть ниже, поэтому есть вероятность конфликта, но все же timeuuid лучше, чем использование самой метки времени. Если uuid random важна, использование UUID версии/уровня 4 - лучший выбор с почти невероятным столкновением.

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

insert into test_tuuid(1, now())
insert into test_tuuid(1, now())
insert into test_tuuid(1, now())
insert into test_tuuid(1, now())

49cbda60-961b-11e8-9854-134d5b3f9cf8
49d1a6c1-961b-11e8-9854-134d5b3f9cf8
49d59e61-961b-11e8-9854-134d5b3f9cf8
49d8d2b1-961b-11e8-9854-134d5b3f9cf8