Доброго дня всем!
У меня есть задача: организовать взаимодействие некоторого числа (к примеру - 20) одновременно работающих программ с общими данными. Данных не много - в пределах 1МБ. Каждый из 20 экземпляров пишет в таблицу некоторые данные достаточно часто (к примеру - раз в секунду), и потом делает к этой таблице SQL-запрос.
Мне видится проблема в виде блокировок. Я поверхностно почитал про SQLite - когда идет запись - блокируется весь файл БД. Другие программы в этот момент не могут ни читать ни писать, ждут когда блокировка исчезнет. И мне видится что к примеру 20 программ, пишущих в базу некоторые данные с периодичностью раз в секунду будут мешать друг другу.
Повторюсь: данных не много, в основном - численные.
Получается - мне SQLite не подходит?

Если не подходит - посоветуйте альтернативы?
На самом деле, эти данные важны только первые 5 секунд. Потом они "прокисают") Я к тому что в идеале эта общая таблица должна висеть в оперативке, и все чтения и запись должны происходить в оперативке. Сохранность данных тут на последнем месте.
SQLite может конечно все держать в оперативке (in-memory), но такая in-memory БД будет для каждого экземпляра своя. А мне нужна общая для всех. Соответственно - это не вариант.
Далее: если таблица висит в оперативке - то у неё должен быть хозяин. Это уже сервер БД. Опять же - не хочется палить из пушки по воробьям - вместе с программой распространять еще и полновесный "условный MySQL".

Натолкните пожалуйста на правильные мысли.

White OwlМассив в памяти блокируемый мутексом (или несколькими) и все. СУБД для этой задачи нафиг не нужен.

Какие слова гуглить?)
Программа написана на Delphi.

Dima T , White Owl Спасибо за ответы!
Я забыл добавить, что экземпляры программ могут перезагружаться.
Пока мысль льется в таком направлении:
1. Если копать в сторону Shared Memory. Насколько я понимаю - один из экземпляров должен создать этот кусок Shared Memory.
Соответственно, когда создатель этого куска перезагрузится - кусок Shared Memory тоже пропадет. Не будет же бесхозный кусок памяти висеть в памяти. С другой стороны - можно при каждом обращении каждым экземпляром проверять наличие и если его нет - создавать и грузить туда данные. Сработает интересно?

2. Вариант с неким "диспетчером" - отдельный экземпляр, который работает в режиме сервера. Всем хорош. Но диспетчер всегда должен работать. А что если он отрубился по каким то причинам? Конечно вариант без диспетчера - более красив и гибок, но более гемороен , ибо при вставки данных в эту общую таблицу требуется функциональность SQL, поддержка уникальности ключей.
Ну и с SQL - ем работать просто привычней.