mayton2019

Можно посмотреть curses. Там по идее должны быть функции определения размера окна терминала.

Но если пользователь возьмет и мышкой потаскает терминал туда-сюда - то надо как-то обновить ширину и обновить view.

Обычно сборщик обладает свойством генерации архе-типов. Например типичное Scala-akka приложение создается так.
$ sbt new akka/akka-quickstart-scala.g8

Вот вам надо создать такое. Сборщик там или просто генератор - не суть важно. Ваш шаблон - это архе-тип.

Да можно. Но что ты напишешь в резюме? Обычно выделяется какой-то ключевой тег. Например С++ разработчик для геймдева. Это понятно. Или фронт-енд со знанием Angular/React/Node. И рекрутер точно понимает что человек профилирован.

Если распыляться 50 на 50 то на собеседовании ты так и не сможешь ответить все таки на какую позицию идешь. В 2000-е когда я оканчивал универ было модно писать в резюме все подряд. Писали чертовщину. C++/Photoshop/3Dmax/CorelDraw/Сисадмин Unix и еще и паяльником умелец. Тоесть складывалось ощущение что нанимают разнорабочего который и мусор убирает и гипсокартон и плитку...

И ещё хотелось бы понять, почему каждый такой указатель является константой?

Это - тяжелое наследие старых систем. В данном примере ты разбираешся с ASCIIZ-строками. С массивами символов которые завершаются нулем. Такая организация позволяет хранить строки компактно. Маркер const защищает строку от случайного изменения. И правильно делает. От этого больше проблем. Тот формат и тот способ хранения строки вообще не предполагает активных изменений. Особенно с размером. Максимум что можно делать - только читать.

С точки зрения современного бизнес-программирования ASCIIZ строки устарели. Но поскольку этот формат является единственным транспортом который понимает ядро ОС - то его часто можно встретить в исходниках.

Для С++ более удобной строкой является std::string. Его использовать приятнее. И с размерами там веселее.
В легаси исходниках можно встретить причудливые CString (MFC), TString (Borland). Это все разные реализации строк.

Для Qt есть тоже свой тип строк.

Непонятно. Если это одноразовое действие - то можно написать наверное софт который просто вызывает imagemagic и все сделает. Но у вас - сайт. И это должно работать на основе некого процесса верстки контента.
Дизайнер закинул картинку. Дальше она сжалась и создалось штук 5 уровней thumnails для preview. Вот второй сценарий - более интересен к разработке.

Смотри. Обычно реляционная алгебра рассматривает коллекции внутри ячеек как потенциальную проблему. Проблему денормализации. Если скин у тебя это сложный объект с другими свойствами и эти свойства вдруг (!) внезапно обрастают связями с другими сущностями БД - то тогда считается что БД плохо спроектирована. Невозможно отслеживать целостность. Или представь что какой-то скин ты решил удалить из системы. Тебе придется сделать поиск всех коллекций всех плееров и поискать его и удалить. И те-же проблемы с вставкой и обновлением.

Но если ты никогда этого не будешь делать и тебе плевать на реляционные связи от скинов к другим элементам системы - то тогда можешь хранить в JSON. MySQL его поддерживает в угоду современным трендами на NoSQL.

Хотя тема NoSQL - гораздо более обширная и сложная чем просто денормализация. Про нее можно говорить часами.

Немного бухгалтерии. Если взять по максимуму.

Размер одной записи должен быть порядка 60 + 32 +8 = 100 символов (байт для простоты)

При 50 млрд записей объем хранимых данных должен быть порядка

50 000 000 000 * 100 = 5 000 000 000 000 = 5 триллионов байт.

В дисковом хранении это будет примерно 4.5 терабайта. Задачка для in-memory неподъемная. Нужен диск + мемори.

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

Вобщем нужна дисковая БД которая встраивается в приложение. На требование менеджеров которые запретили использовать БД забейте. Они ничего не понимают. Делайте БД встраиваемую в приложение. В качестве таких (встраиваемых систем можно поробовать) LevelDb, BerkeleyDb, RocksDb. Они поддерживают индекс класса B+Tree и это даст возможность искать группы записей по одному ID. Для этого класса систем любую запись можно найти за 4-5 дисковых IOPS. Если какдый IOPS стоит 15 мс (это я так мерял свой собственный магнитный HDD) то любой поиск группы ключей для TTFB будет порядка 15 * 5 = 75 милисекунд. Ну если вы поставите SSD - то быстрее.

По поводу предложений хранить в файлах. До того как обсуждать это - надо уяснить требования по времени отклика. Сколько секунд вы согласны ждать - насколько можно и партицировать (или шардировать ваш файл).
В простейшем случае мы делим большой CSV файл на 512 partitions по хешу от ID и получаем соотв время фулл-скана всего файла поделенное на 512. Дальше - играйтесь с этим параметром партишенинга выводя его на доступный уровень отклика. Из недостатков - будет россыпь файлов. Надо почиать документацию на вашу файловую систему (ext4?) и тюнить ее так чтоб она не сдохла от такого числа inodes.

Я поддержу оба сценария. И с встраиваемой БД и с файлами. Но с БД надежнее т.к. есть транзакции а файлы у вас могут быть в крешнутом состоянии долго. И вы об этом ничего знать не будете.

По поводу Parquet. Не взлетит. Скорее всего индекс по данному типу файла - это совсем не то что вкладывают туда релационные системы. Обычно Parquet/Orc/Delta вкладывают в индекс смысл - отбрасывания тех полосок данных (stripes) которые бесполезны при чтении всего файла. Такой индес - обычно просто либо range-признак либо карта Блума. И в случае с range - дает эффект на сортированных данных. Для прочих - будет бесполезно т.к. фулл-скан все равно обеспечен. А если фулл-скан то зачем тогда вообще индекс.

Вобщем для дизайна архитектуры нам нужны цифры. Средние длины по колонкам. И я-бы еще запросил кардинальность по полю ID.

С 2005 года достигнут инженерный предел наращивания тактовой частоты. Грубо говоря, современные инфосистемы отказались от движения в ту сторону. Поэтому вопрос поставлен некорректно.

Не что важно. А что мы вообще можем сделать в этой ситуации.

@tailrec
def getDrinksWithStep(g : Int, step : Int, i : Int = 1, r : Int = 0) : Int = 
  if (i <= g) getDrinksWithStep(g, step, i + step, r + i) else r

Богдан. Обычно реляционные БД так не работают. Клиент - спрашивает. БД отвечает. Обратное не делают обычно.

Отслеживание новых записей - это технически сложная задача потому что нужен буфер и умножение этого буфера на количество подписчиков. Тоесть приходим к полноценной MQ-системе. Обычно БД конфигурируется так что лишних ресурсов на это нет. Да и зачем БД рассылвать уведомления когда это задача сервера приложений.

Если вы все таки решили спрашивать на зарубежных форумах - то не говорите слово MySQL/SQL. Пишите просто - информационная система и хранилище. Пускай вам советуют с чистого листа как это надо дизайнить.

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

Покажи код консьюмера. Это твоя логика. И ты решаешь где тебе делать фиксацию пачки и где не делать.