Предложение по дизайну базы данных - интенсивная вставка и удаление большого количества записей

Question

У нас есть база данных с очень простой схемой:

 CREATE TABLE IF NOT EXISTS tblIndex(
     frame_type  INT, 
     pts  VARCHAR(5),
     ts_start  INT primary key,
     ts_end  INT)

И сценарий приложения:

1. Каждый второй пользователь будет вставлять 2 ~ 50 записей, и поля ts_start этих записей всегда увеличиваются. Через 8 часов не более 1_800_000 записей. Если вы выключите режим синхронизации, производительность покажется нормальной. И поскольку данные каждой записи имеют только 16 байтов, мы можем использовать некоторый буфер, даже если скорость вставки не слишком высокая.

2. Через 8 часов пользователь скажет мне удалить самые старые данные, указав верхнюю границу ts_start, поэтому я сделаю

   DELETE FROM tblIndex WHERE ts_start < upper_bound_ts_start.

   Удаление 90_000 (то есть записей за полчаса) из 1_800_000 теперь занимает 17 секунд. Подстилка немного длиннее, чем ожидалось. Есть ли способ уменьшить это? Нам все равно, синхронизируются ли записи на жесткий диск немедленно. Мы думаем запустить отдельный поток для удаления, чтобы сделать этот вызов асинхронным. Я не уверен, что удаление (долгое время) повлияет на производительность вставки, если они используют одно и то же соединение? Или я должен использовать отдельное соединение для вставки и удаления? Но, таким образом, нужно ли их синхронизировать на уровне приложения?

3. Поиск. SELECT ts_start FROM tblIndex WHERE ts_start BETWEEN ? AND ? - Поскольку ts_start является первичным ключом, производительность в настоящее время удовлетворительная для наших нужд. Я думаю, что я должен использовать отдельное соединение для поиска, верно?

Конфигурация SQLite:

hard disk database (usb interface)
cache size is 2000
page size is 1024
sync mode is 0 (off)
journal_mode mode is truncate

Спасибо за любые предложения по улучшению производительности удаления или по поводу общего дизайна.

РЕДАКТИРОВАТЬ: 350M MIPS CPU, не слишком много памяти (<2M) специально для этого приложения. </p>

Answer 1

Поскольку данные временные - и маленькие - зачем вы используете базу данных?

Вы были бы намного счастливее с простым каталогом плоских файлов.

Ваш веб-запрос может просто прочитать соответствующий набор файлов и вернуть требуемые результаты. 1_800_000 записей по 16 байт - это всего лишь 28 МБ данных файла. Вы можете прочитать все это в памяти, выполнить обработку в памяти и представить результаты.

Отдельный процесс может удалять старые файлы раз в день в полночь.

Третий процесс может добавлять 2-50 16-байтовых записей в рабочий файл каждую секунду.

• Запись и очистка, чтобы файл был правильным и завершенным после каждого ввода-вывода. Если ваш читатель корректно обрабатывает неполную последнюю запись, вам даже не нужна блокировка.

• Назовите каждый файл с порядковым номером, основанным на времени. Например, вы можете взять системное время (в секундах), разделенное на 4 * 60 * 60, и усечь ответ. Это порядковый номер, который будет обновляться каждые 4 часа, создавая новый файл. 8 часов данных - это 3 из этих файлов (2 предыдущих 4-часовых файла плюс текущий рабочий файл).

Answer 2

Как насчет одной базы данных sqlite на каждые полчаса? Другими словами, запускайте новый файл базы данных каждые полчаса и просто удаляйте старый.