Kafka: генерация уникальных идентификаторов для строк между разделами - PullRequest
0 голосов
/ 02 июля 2018

Я пытаюсь оценить, можно ли использовать Кафку для расширения нашего текущего решения. Я могу легко определить разделы. В настоящее время требуется 1500 разделов, каждый из которых имеет 1-2 события в секунду, но будущее может достигать 10000 разделов.

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

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

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

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

Чтобы проиллюстрировать проблему: каждый раздел представляет собой компьютер в сети. Каждое событие - это действие на компьютере. События необходимо упорядочивать для каждого компьютера, чтобы события, которые изменяют состояние компьютера (например, пользователь вошел в систему), могли влиять на другие типы событий, и упорядочение является критически важным для этого. Например. пользователь открыл приложение, файл записан, вставлена ​​флешка и т. д. И мне нужно, чтобы каждое приложение, файл, флешка или многие другие имели уникальные идентификаторы на всех компьютерах. Это тогда используется, чтобы вычислить статистику вниз по течению. И иногда событие может иметь несколько таких, например. операция над конкретным файлом на определенной флешке.

1 Ответ

0 голосов
/ 10 июля 2018

Отказ от ответственности: я бы добавил это как комментарий, если бы мог.

Очень хороший пост о kafka и blockchain . Это коллективная работа, и я думаю, что это может решить проблему масштабируемости ваших идентификаторов. Для решения обратитесь к «Блокчейн: причины». часть. Все работы принадлежат соответствующим авторам.

  • Идея проста, но эффективна:
    • Данные основаны на хэше, со ссылкой на предыдущий блок
    • Данные могут быть очень хорошими хешами, ссылками на соответствующие блоки типов
    • Специальное решение для цепочки блоков означает, что вы управляете кодированием / декодированием данных
    • Каждая хеш-цепочка является автономной, и, по сути, может быть вашим процессом (hdd / ram / cpu / word / app и т. Д.)
    • Каждая хеш-цепочка может быть самим сообщением
  • Бонус: статистика и аналитика могут очень хорошо храниться в цепочке блоков, с высокой поддержкой сжатия и репликации. Потребители довольно дешевы в этом контексте (масштабируемость).

Процесс:

  • Решена проблема с уникальным идентификатором
  • Все записи связаны между собой и благодаря kafka & blockchain высоко упорядочены
  • Расширяемые данные
  • Кафка свойства применяются

Минусы:

  • Шифрование / дешифрование требует значительных ресурсов процессора
  • Растущий уровень сложности вычисления хеша

Проблема: без проблемного контекста трудно приблизиться к ограничениям, которые необходимо устранить в дальнейшем. Однако при условии, что вычисленное решение имеет конечный характер, у вас не должно возникнуть проблем с регулярным масштабированием решения.


Итог: Без знания требований с точки зрения скорости / стоимости / качества трудно дать лучший, обоснованный ответ с рабочим примером. Облачное расширение ЦП может быть сравнительно дешевым, хранение данных - зависит от времени, как долго и какого объема данных вы хотите хранить, возможности воспроизведения и т. Д. Это хороший кусок работы. Прототип? Концепция в ссылочной статье.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...