Які СУБД корисні для надшвидкого зчитування та простої структури даних?

Я розробляю продукт, який в рамках своєї операції повинен відслідковувати велику кількість файлів / каталогів. Ідея полягає у збереженні статистичної інформації в базі даних, після чого під час завантаження створюйте годинник для кожного файлу. Файли, які змінюються, будуть в черзі (у базі даних) для групової синхронізації з віддаленою базою даних. Вони будуть синхронізовані в порядку черговості, число між 1-10.

Інформація про базу даних:

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

Я знайшов пару баз даних, які, на мою думку, спрацюють, але я не впевнений, що було б найкраще:

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

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

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

Тож питання, яка база даних буде найбільш застосовна для даної ситуації?

Також, чи є інші бази даних, які мали б більше сенсу для такого додатка?

Перше, що мені спадає на думку, це конкретна знайома мені RDBMS. Однак я визнаю, що це може бути не найкращим для цієї програми.

Отже, моя порада - перейти до знайомої вам бази даних. Якщо ви знайомі з Redis або MongoDB, тоді перейдіть з одним із них. Якщо ви більше знайомі з SQLite, тоді вибрали саме це.

У базі даних такого розміру все буде досить швидко. Навіть більш важкі диски будуть використовувати кешування, щоб швидкість диска не викликала особливих проблем.

Якщо вас не стосується реляційна логіка, ви хочете по-справжньому швидку швидкість читання, і ви готові працювати з RDBMS, я б з упередженням зважився сказати MySQL. Чому ???

Двигун зберігання даних MyISAM має опцію, яка дозволяє дозволити покращення фізичної структури таблиці для кращої роботи. Що це за варіант? Параметр ALTER TABLE ROW_FORMAT.

Наприклад, книга MySQL Database Design and Tuning рекомендує використовувати ROW_FORMAT = FIXED на сторінках 72,73. Це внутрішньо перетворить усі поля VARCHAR у CHAR. Це зробить таблицю MyISAM більшою, але виконані SELECTs проти неї будуть набагато швидшими. Я особисто можу це засвідчити. Колись у мене був стіл, який був 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, чи замислювалися ви над тим, щоб використовувати 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. Я зараз стою виправлений.