Смотри. Партиции - это инструмент перформанса а не бизнес атрибут. Поэтому если ты сразу сходу
создашь 100 тыщ партиций то тебе надо некоторое количество дисковых хранилищ и серверов
сразу. Беря во внимание что обычно бизнес нагрузка эволюционирует плавно то скорее всего
тебе эти мощности сразу будут не нужны. Но будучи созданными они будут зря тратить деньги
за uptime.
Ты можешь для начала создать 16 партиций а свои топики отобразить на на партиции по ключу (Key).
Кафка поддерживает ключ в каждом месседже поэтому создай себе правильную хеш функцию
которая отображает ключи на партиции. Это в кафке заложено. Вот. Если мощности не хватит - тогда
сделай 32 партиции. Потом 64 и так далее. Вот это и будет правильный подход.
Почему один ключ должен "мешать" другому я не понимаю. Если такое было то у тебя должен
быть реальный кейс такой ситуации из практики. Но я в этом сомненваюсь.
ugin_root, я не совсем понимаю что значит "переключится" на другую.
Может быть ты имеешь в виду диспетчеризацию внутри процесс-консюмера?
Например я - процесс потребитель событий. И с одной стороны я могу подключаться к 10 топикам Kafka.
Сливать все 10 в один внутренний для обработки. Те события которые удалось обработать - коммитить
в кафку (да там есть режим фиксации транзакций). А те которые еще не готовы к обработке
я буду вращать по кругу во внутреннем буфере. Какое-то время. 5-10 минут. Выбери сам.
Потом сказать Кафке rollback. Дескыть пока не судьба. Положу обратно на полочку.
Наверное идет конкурентный доступ к текстовому файлу. В результате один процесс или поток файл
закрывает раньше и дальше ... надо проверять. Семантика файловых операций в Windows и Linux
сильно отличается.
Вы обязаны проверять всю цепочку до тех пор пока
- не найдете нужный элемент
- не найдете пустое место
- пока идут надгробные камни
- пока вы не исчерпали лимит проверок. Например при размере OA hashtable например в
миллион элементов и при линейном опробировании вы можете по кругу пройти
всю адресную емкость таблицы.
Rsa97, согласен. Но я предполагаю что игры со 100Мб кешом нацелены на практическое
подавление константы которая стоит перед всеми формулами. Грубо говоря логарифмический
поиск in memory в некоторых случаях быстрее двух констант memory + disk.
Я вот думаю о математической части этой постановки. Сортированный сет
чисел можно представить как график. Монотонный.
А 100 мб индекс можно представить как некую кусочно-линейную интерполяцию
этого графика. Причем интерполяцию не "внутри" а "снизу" графика.
Тогда поиск (или его оптимизация) будет заключаться просто в грубой оценке первого прыжка на графике. Тоесть куда нам нужно прыгнуть чтоб
быстрее подойти и искомому интервалу чисел.
Ты пришел сюда решать уравнение - так решай. Любые переборные методы - это
частный случай генетики. Поэтому или занимайся эффективными алгоритмами
или просто играйся.
По поводу клаватурных паролей типа 1q2w3e4r5t6y где текст набит "треугольником" или в линию.
У меня была идея создать генератор для радужных таблиц. Но мне кажется что кто-то такое
уже создал. Только как оно может называться ХЗ.
создашь 100 тыщ партиций то тебе надо некоторое количество дисковых хранилищ и серверов
сразу. Беря во внимание что обычно бизнес нагрузка эволюционирует плавно то скорее всего
тебе эти мощности сразу будут не нужны. Но будучи созданными они будут зря тратить деньги
за uptime.
Ты можешь для начала создать 16 партиций а свои топики отобразить на на партиции по ключу (Key).
Кафка поддерживает ключ в каждом месседже поэтому создай себе правильную хеш функцию
которая отображает ключи на партиции. Это в кафке заложено. Вот. Если мощности не хватит - тогда
сделай 32 партиции. Потом 64 и так далее. Вот это и будет правильный подход.
Почему один ключ должен "мешать" другому я не понимаю. Если такое было то у тебя должен
быть реальный кейс такой ситуации из практики. Но я в этом сомненваюсь.