Входные данные:
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.

Arm79Artemeeyпропущено...


Спасибо! ТАРАНtool мне показался интересным и вероятным решением из NoSQL.
На самом деле проблем с записью на диск не так уж и много. Допустим 1000 соединений. Создать файл, записать небольшую порцию данных туда, закрыть файл - примерно 0,2 мс, итого до 5000 тысяч мелких файлов в секунду в зависимости от диска. SSD в этом плане побыстрее даже будет.

Но и это можно обойти и ускорить. Например, выравнивая приходящие сообщения по размеру и записывая их в файл (но не закрывая сам файл) с принудительным сохранением буфера. Тогда не будет тратиться время на получение соответствующего handle, а удаление записи - обычной пометкой как удаленную. При новых сообщениях (учитывая, что они равны в размерах) тупо писать на место помеченной как удаленная либо добавлять в конец.

И, естественно, вести в памяти индекс, например на основе avl деревьев. То есть такая своеобразная localdb получится.

Работы там на пару дней всего + еще пару - тестирование.

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

Всем спасибо. Решение было найдено. MySql стал справляться с нагрузкой. Логика была переписана.

golovonometr,

Что значит без каких либо баз данных, а место хранение этой очереди где будет?
Я видимо не совсем понял, что вы имеете ввиду. Подскажите, пожалуйста решение.

Так же в этой очереди должны храниться результаты обработки и статус самой задачи.

P.S. Вопрос закрыт, задача решена.