очевидна что та которая тербует масштабирования

а так делать и не надо

да почти никакая не требует, так-то

Та, с которой, при которой при всей оптимизации со стороны бд наблюдаются неприемлемые тайминги из-за большого кол-ва операций с ней, которое в свою очередь вытекает из большого кол-ва данных.

операции чтения или записи?

А можно пример запроса такого

из личного опыта: иногда делают шардинг, иногда - просто перенос холодных данных в другую базу

вы самую важную часть вопроса хотите проскочить

Простой селект по уникальному ключу, если таких запросов тысячи в секунду

партиционирование не помогает?

и индексы?

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

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

а тут очень узкий селект по уникальному ключу 🙂

если тысячи в секунду и рандомные - не поможет

я в mysql бахал табличку на 128 миллионов на 6 поле интовых + выборка по ним

только на индексах

вопрос - насколько быстро вам надо

если сделать партиционирование по этом ключу и индекс по нему же, то не поможет?

У меня есть таблица на десятки миллионов записей. При росте данных в ней, тайминги увеличились. Запросы - а основном селекты по уникальному ключу. намного реже есть агреригующие запросы.Если сделать шардирование - те несколько инстансов бд и там хранить порции данных, то для запросов по уникальному ключу все становится лучше, но больше и сложнее становится агрегирующий запрос, ТК с ним приходится обходить все шарды, потом собирать все данные в кучу.
Вот такую картину я имею.