mayton2019

Непонятно. Если это одноразовое действие - то можно написать наверное софт который просто вызывает 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. Пишите просто - информационная система и хранилище. Пускай вам советуют с чистого листа как это надо дизайнить.

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

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

Посмотри Collaborative Filtering https://spark.apache.org/docs/latest/ml-collaborat...

Нужно материализовать ответы. И класть их на быстрое хранилище рядом с кешом типа nginx.

Современные ssd имеют большой мото-ресурс. Скорее всего они будут убиты чем угодно но не торрентом.

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

У тебя что сервер?

Вам определенно нужен девопс который автоматизирует вам выполнение ваших скриптов по календарю. Добавит дашборды с графиками и прочее.

DataGrip насколько я понимаю это среда разработки. Тоесть она активна пока у вас крышка ноутбука отрыта. Закрыли - всё. Капец все планам.

Поэтому девопс и еще раз девопс.