В очередной раз призываю к помощи великих Гуру:) Вопрос немного оффтоп от Perl, но имхо достаточно интересный и важный.

Есть база данных из двух таблиц, по сути - это база данных товаров от разных поставщиков.

В первой хранится список товаров, в виде: ID группы, Бренд, Артикул. Связка
Бренд+Артикул - уникальная, ID группы может повторяться.

Таблица нужна для идентификации товара и для поиска аналогов товаров - все
товары с одинаковым ID группы это товары-заменители.

В этой таблице примерно 15 миллионов записей, изменения вносятся редко, т.е. в
основном таблица работает на SELECT.

Во вторую таблицу пользователи могут загрузить свои предложения, а другие пользователи делают по ней поиск. Тут может быть и много INSERTов и много SELECTов. Каждый пользователь может загрузить до 100К позиций. Размер базы находится в пределах 100 млн - 10 млрд записей. Т.е. когда пользователь делает поиск, то сайт ему показывает результаты и прямые и все предложения по товарам-аналогам. И ещё, когда пользователь загружает своё предложение, то каждая позиция проверяется по Таблице 1, что там этот товар есть, которых нет - отображаются пользователю списком после загрузки.

Сейчас это всё работает в MySQL, но пока что пользователей очень мало и соответственно позиций в базе тоже мало. Миллиарда строк в таблице прайса ещё нет, а когда будет - начнутся страшные тормоза.

Поэтому, внимание вопрос - как это всё правильно архитектурно организовать, чтобы и поиск не пострадал, и загрузка новых предложений работала быстро.

Сейчас у меня идея такая - Nginx + Unievent::HTTP + Clickhouse. Надо ли использовать тут какую-нибудь прокладку в виде Редиса? Может, Таблицу 1 вообще полностью запихнуть в Redis? Как это максимально эффективно организовать? В общем, буду благодарен за любые идеи.

Кликхаус вообще для такого не предназначен, это не замена SQL базе.  тогда уж талантул брать

Tarantool для обеих таблиц, или только для первой? Почему не Redis?

Ну из описания видно что тебе нужно эти данные хранить и гонять по ним всякие запросы. Redis это не про хранить и не про хитрые запросы.

Объем данных о товарах какой?

В первой таблице около 15 миллионов строк (данные о товаре), во второй (прайс) - от 100 миллионов до 10 миллиардов строк

Но вообще по описанию не очень понятно почему оно должно тормозить при достаточности железа и правильной расстановке индексов

В гигабайтах то это сколько? В 128 влезет?

Данные о товаре в память, поиск по товарам делат ьв памяти.

если 10 пользователей начнут загружать свои прайсы по 100К строк - начнутся тормоза, имхо даже если я всё хорошо оптимизирую, но может я и ошибаюсь

т.е. всё в память получается?

или только Таблицу 1?

Нет... Все прайсы в память не надо. Только текущий прайс для которого ищется решение.

какой размер одной строки то? 1кб, 10кб, 100Мб?

думаю в 1кб точно должна вложиться

Тогда из базы выбирается только текущий прайс для обработки и по нему уже все в памяти ищется.

А... Частота запросов к этому решению - какая?

Просто судя по всему тебе будет достаточно 16-32Гб оперативки для того чтобы засунуть все товары в память и по ним уже искать.

А базу можешь и на Pg сделать. Один индекс по прайсам по id прайса и все. Он тебе нужен чтобы выбирать конкретный прайс.

так это у тебя 100Мб на прайс получается, даже на дешманском сервере все в память влезет