Входные данные:
1) Сервер любой (не имеет значение, т.е. будет куплен любой по необходимости)
2) Таблица содержит до 100 тыс. записей. Это правда немного, но все записи находятся в ПОСТОННОМ режиме вставки, чтения, удаления.
3) Каждую секунду к БД идет соединений: 400-800шт. Одно обращение это:
.
Если кто-то не понял логики, объясню: так делается для того, чтобы одну и ту же запись не могли получить одновременно два разных соединения.
4) Через некоторое время (3-5 сек.):
(каждая запись имеет уникальный идентификатор `id`)

Вопрос : какую БД лучше использовать?
Может быть есть какой-то другой алгоритм контроля, чтобы одну строку могло прочитать (использовать) только одно соединение?

P.S. Пробовал на MySql с таблицей типа InnoDB с индексами на `id` и `process_id`. До 5 тыс. записей в таблице молниеносно все работает. Но если записей становится около 20 тыс. в статусе операций БД видно много запросов с ожиданием "wite lock".

Видимо 300 (примерное число) одновременных соединений, выполняя UPDATE мешают друг другу и ждут окончания каждого. Если соединений еще больше, и записей больше происходит, что то похожее на "deadlock" - но все же не "deadlock", со временем операции все завершаются, но из-за медленного выполнения, количество одновременных соединений увеличивается, что и вызывает потерю памяти и еще больше блокировок (количество открывающихся соединения растет, а выполненных и закрывающихся падает).а завершающихся падает.

P.S. P.S.
Как вариант - запретить подключение к базе более 800 соединений. Этот вариант я рассмотрел и мне он не подходит. Просто каждую минуту соединения не будут открываться с ошибкой "max connect" - это не решение. Каждую секунду они должны как открываться, так (через равные промежутки времени) и закрываться (как было бы, если бы не было блокировок).

Dimitry Sibiryakov,

При отключения питания сервера, данные не пропадут?

Dimitry Sibiryakov,

Про питание я дли примера сказал. 99.99% меня уже не утсроит (потеря 00.001%). Остановка может быть вызвана не только прекращением питания.

DPH3,

авторПоищите любую очередь сообщений с гарантией

А она точно будет быстрее работать чем 800 заданий в сек.? Если да, то посоветуйте пожалуйста очередь сообщения с гарантией.

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

Dimitry Sibiryakov,

Нынешний алгоритм, при потере питания сохраняет данные в базе.
Вариант с оперативной памятью не подходит.

Dimitry Sibiryakov,

Вы сами предложили использовать оперативку для хранения данных, чтобы все было быстро. Если будем эти данные каждый раз сохранять с высокой частотой на диск, вернемся к первому вопросу. В каком виде хранить такие данные. Я использую Mysql.

Arm79см. тарантул, вполне потянет такую мелочь как тысячи соединений и тысячи операций чтения/записи в секунду.

Спасибо! ТАРАНtool мне показался интересным и вероятным решением из NoSQL.