Вопрос:

Плюсы и минусы идентификаторов Flake и идентификаторов криптографии

identity distributed-system

92 просмотра

1 ответ

72 Репутация автора

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

Интересно, каковы плюсы и минусы каждого метода.

Автор: Justin Lin Источник Размещён: 07.01.2018 07:39

Ответы (1)


2 плюса

7285 Репутация автора

Решение

Я собираюсь принять 128-битные идентификаторы, вроде как UUID. Давайте начнем с базовой линии, хотя

TL; DR : использовать случайные идентификаторы. Если и только если у вас есть проблемы с производительностью базы данных, попробуйте Flake ID.

Идентификаторы автоинкремента

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

Очевидным преимуществом является то, что идентификатор гарантированно уникален для вашей системы, хотя 128 бит, вероятно, излишни.

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

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

Случайные идентификаторы

Случайные идентификаторы - это когда вы просто генерируете 128 случайных байтов. v4 UUID 122- битные случайные идентификаторы (например 2bbfb5ba-f5a2-11e7-8c3f-9a214cf093ae). Они также практически уникальны.

Случайные идентификаторы избавляют от обоих недостатков идентификаторов автоинкремента: они не пропускают информацию и бесконечно масштабируются.

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

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

Flake ID

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

  1. 2bb fb5baf5a211e78c3f9a214cf093ae
  2. 2bb f9d4ec10c41049fb1671d6616b213
  3. 2bc 6bb66e5964fb59050fcf3beed51b1

Хотя вы можете потерять некоторую информацию, это не так много, если ваша kгранулярность и временная метка разработаны правильно.

Но если вы неправильно проектируете идентификаторы, они могут оказаться менее чем полезными, либо слишком редко обновляющимися, что приводит к тому, что b-деревья полагаются на верхние случайные биты, отрицая полезность, или слишком часто, когда вы перебиваете базу данных, потому что ваши обновления ,

Примечание. Под детализацией времени я подразумеваю, как часто меняются младшие биты метки времени. В зависимости от вашей пропускной способности вы, вероятно, захотите, чтобы это были часы, дека-минуты или минуты. Это баланс.

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

Криптографические идентификаторы

Я предполагаю, что это означает, что в идентификаторах зашифрована некоторая семантическая информация. Может, как хешид ?

Недостатков предостаточно:

  • У вас будут разные идентификаторы длины для разных данных, если у вас нет протокола фиксированной длины.
  • Вы будете склонны добавлять все больше и больше информации в идентификаторы.
  • Выглядите случайным образом, но без помех, чтобы добавить хлопьевидные временные метки на фронт
  • Идентификаторы становятся привязанными к системе, которая сделала это. Вы можете начать запрашивать у этой системы расшифрованные версии идентификатора, а не просто запрашивать данные, на которые она указывает.
  • Ваша система использует время для расшифровки идентификаторов для извлечения данных.
  • Вы добавляете проблемы с шифрованием
    • что произойдет, если утечка секретного ключа? (Лучше не иметь слишком чувствительных данных там, имени клиента, или небеса запрещают номер кредитной карты)
    • координация вращения клавиш.
    • Небольшие идентификаторы, такие как hashid, могут быть атаку грубой силой.

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

Например, я использую шифрование для токенов пагинации: зашифровано {last-id / context}из API пагинации. Я предпочитаю это тому, чтобы клиент передавал последний элемент предыдущей страницы, потому что мы скрываем контекст базы данных от пользователя. Это проще для всех, и шифрование - это чуть больше, чем запутывание (без конфиденциальной информации).

Автор: Michael Deardeuff Размещён: 10.01.2018 02:02
Вопросы из категории :
32x32