Какая СУБД хороша для сверхбыстрого чтения и простой структуры данных?

Я разрабатываю продукт, который, как часть его работы, должен отслеживать большое количество файлов / каталогов. Идея состоит в том, чтобы сохранить статистическую информацию в базе данных, а затем при загрузке создать часы для каждого файла. Изменяемые файлы будут поставлены в очередь (в базе данных) для синхронизации группы с удаленной базой данных. Они будут синхронизированы в порядке приоритета, число от 1 до 10.

Информация о базе данных:

• <100 000 записей статистики
• Вся база данных читается при загрузке, нужен только путь к файлу
• У файлов в очереди будет приоритетное поле (больше ничего не нужно искать)
• Вставки могут быть медленными

Я нашел пару баз данных, которые, я думаю, будут работать, но я не уверен, что будет лучше:

• Redis - сохранить путь к файлу в качестве ключа, данные статистики в качестве значения; очередь будет список
• MongoDB - больше вариантов запросов, чем в Redis, но все еще быстро

Я думаю, что база данных NoSQL была бы лучшим решением здесь, так как здесь не слишком много реляционной логики и общий объем данных не слишком велик (что-то вроде <100 мб, ближе к <30 мб). Я посмотрел на SQLite, потому что он кажется достаточно простым для встраивания в устанавливаемое приложение.

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

Таким образом, вопрос, какая база данных будет наиболее подходящей для этой ситуации?

Кроме того, есть ли другие базы данных, которые имеют больше смысла для такого приложения?

Первое, что приходит на ум, - это знакомая мне конкретная СУБД. Я признаю, однако, что это не может быть лучшим для этого приложения.

Итак, мой совет - использовать базу данных, которая вам знакома. Если вы знакомы с Redis или MongoDB, то выберите один из них. Если вы более знакомы с SQLite, то выбрали это.

В базе данных такого размера все будет довольно быстро. Даже базы данных, которые являются более загруженными дисками, будут использовать какое-то кэширование, поэтому скорость диска не является большой проблемой.

Если вы не заинтересованы в реляционной логике, хотите действительно быстрой скорости чтения и хотите работать с RDBMS, я бы рискнул сказать MySQL. Почему ???

У механизма хранения MyISAM есть опция, позволяющая дополнить физическую структуру таблицы для повышения производительности. Что это за вариант? Опция ALTER TABLE ROW_FORMAT.

Например, книга MySQL Database Design and Tuning рекомендует использовать ROW_FORMAT = FIXED на страницах 72,73. Это внутренне преобразует все поля VARCHAR в CHAR. Это увеличит размер таблицы MyISAM, но выполнение SELECT для нее будет намного быстрее. Я могу лично засвидетельствовать это. Однажды у меня был стол, который был 1,9 ГБ. Я изменил формат с помощью ALTER TABLE tblname ROW_FORMAT = FIXED. Таблица закончилась 3,7 ГБ. Скорость SELECTs против него была на 20-25% быстрее без улучшения или изменения чего-либо еще.

Что если у вас уже есть таблица MyISAM, заполненная данными? Вы можете получить метрики для рекомендуемых определений столбцов на основе данных, представленных в таблице MyISAM. Какой запрос представляет эти показатели?

SELECT * FROM tblname PROCEDURE ANALYSE();

ПРОЦЕДУРА АНАЛИЗА () Это не будет отображать данные. Он будет читать значение каждого столбца и рекомендовать определения столбцов. Например, если у вас есть столбец типа со значениями от 1 до 4, он будет предлагаться с использованием ENUM из этих 4 значений. Затем вы можете использовать TINYINT или CHAR (1), поскольку они занимают одинаковое количество места (1 байт).

Вот еще кое-что, чтобы рассмотреть: так как вы думали об использовании NoSQL DB, задумывались ли вы когда-нибудь об использовании MyISAM в режиме NoSQL? Это вполне возможно. Страница 175 той же книги, о которой я упоминал предлагается использовать структуры HANDLER для чтения таблицы без реляционного багажа . Фактически, страница 175 дает этот пример:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

Эта таблица содержит миллионы строк. Предположим, вам нужно создать приложение для анализа данных, которое соответствует следующим требованиям:

• Необходимо извлекать блоки информации как можно быстрее.
• Исходя из пользовательского ввода или других факторов, он, скорее всего, «прыгнет» в таблице.
• Он не связан с параллелизмом или другими проблемами целостности данных.
• Перекрестная блокировка таблицы не требуется.

Эти команды разрешают быстрое и грязное чтение из таблицы:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

Я надеюсь, что это даст пищу для размышлений. Пожалуйста, посмотрите на это.

ПРЕДОСТЕРЕЖЕНИЕ

Что иронично в том, что я пишу этот конкретный пост, так это то, что я написал более ранний пост об использовании HANDLER в двоичных файлах Percona Server и думал, что его использование устарело . С тех пор я не думал, что когда-нибудь напишу что-нибудь в поддержку структур HANDLER. Я сейчас исправлюсь.