Вы не предоставили достаточной информации о том, как на самом деле выглядят ваши запросы, но я покажу вам, как оценить приблизительный уровень реалистичности ваших ожиданий, используя PostgreSQL в качестве примера.
Подготовка фиктивной таблицы с 10M строками и 80 байтами данных заполнителя на строку:
create table foo as select
generate_series(1,10000000) as foo_id,
repeat('a', 80) as filler;
create unique index foo_foo_id on foo (foo_id);
vacuum analyze foo;
Эта таблица занимает 1400 МБ, включая индекс, поэтому она полностью помещается в кэш моей ОС, но не в общие буферы PostgreSQL.
Создание собственного сценария pgbench для выборки 70000 строк, упорядоченных по индексу:
\setrandom key 1 9000000
SELECT * FROM foo WHERE foo_id > :key ORDER BY foo_id LIMIT 70000;
Вот результаты запуска теста производительности моего 4-ядерного настольного компьютера (AMD Phenom II X4 955) в течение 1 минуты:
% pgbench -j 4 -c 4 -T 60 -n -f script.pgb
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 4
number of threads: 4
duration: 60 s
number of transactions actually processed: 3922
tps = 65.309954 (including connections establishing)
tps = 65.316916 (excluding connections establishing)
Обратите внимание, что здесь клиент (pgbench) и сервер находятся на одной физической машине. В действительности они были бы другими, поэтому в игру вступают такие вещи, как нагрузка на сеть и пропускная способность.
Эта наивная конфигурация может обрабатывать ~ 65 таких запросов в секунду. Намного ниже, чем «несколько сотен запросов в секунду», поэтому вам понадобится намного более мощный сервер для обработки такого рода рабочей нагрузки. Возможна репликация с несколькими ведомыми устройствами.
Чтобы получить более реалистичный результат, вам нужно настроить скрипт pgbench и проверить данные, чтобы они соответствовали вашей рабочей нагрузке.