MySQL против SQLite + УНИКАЛЬНЫЕ Индексы

Question

По причинам, которые не имеют отношения к этому вопросу, мне нужно будет запустить несколько баз данных SQLite вместо более распространенного MySQL для некоторых из моих проектов, я хотел бы знать, как SQLite сравнивается с MySQL с точки зрения скорости и производительность в отношении дискового ввода-вывода (база данных будет размещена на USB-накопителе USB 2.0 ).

Я прочитал страницу сравнения скорости базы данных по адресу http://www.sqlite.org/speed.html и должен сказать, что был удивлен производительностью SQLite, но поскольку эти тесты устарели, я искал более обновленный тест (SQLite 3 против MySQL 5), опять же моя главная проблема - производительность диска, а не CPU / RAM .

Также, поскольку у меня нет такого большого опыта работы с SQLite, мне также любопытно, есть ли в нем что-то похожее на события TRIGGER (при обновлении, удалении) в движке InnoDB MySQL. Я также не смог найти способ объявить поле УНИКАЛЬНЫМ, как у MySQL, только PRIMARY KEY - я что-то упускаю?

В качестве последнего вопроса я хотел бы знать, существует ли хороший (желательно бесплатный или с открытым исходным кодом) менеджер баз данных SQLite.

Answer 1

Несколько вопросов:

1. Что касается ограничений дискового ввода-вывода, я бы не подумал, что ядро ​​базы данных имеет большое значение. Там может быть несколько мелких вещей, но я думаю, что это в основном только то, может ли база данных читать / записывать данные так быстро, как этого хочет ваше приложение. Поскольку вы будете использовать один и тот же объем данных с MySQL или SQLite, я думаю, что это не сильно изменится.
2. SQLite поддерживает триггеры: Синтаксис CREATE TRIGGER
3. SQLite поддерживает УНИКАЛЬНЫЕ ограничения: синтаксис определения ограничения столбца .
4. Для управления базами данных SQLite я использую надстройку Firefox SQLite Manager . Это очень хорошо, делает все, что я хочу.

Answer 2

Что касается ограничений дискового ввода-вывода, я бы не подумал, что ядро ​​базы данных большая разница.

В Mysql / myISAM данные хранятся НЕПРАВИЛЬНО, поэтому RANGE читает ON PRIMARY KEY теоретически потребуется для выполнения нескольких операций HDD SEEK.

В Mysql / InnoDB данные сортируются по PRIMARY KEY, поэтому чтение RANGE по PRIMARY KEY будет выполняться с использованием одной операции DISK SEEK (теоретически).

Подводя итог: myISAM - данные на жестком диске записаны без порядка. Медленный диапазон PRI-KEY считывает, если pri key не является уникальным полем AUTO INCREMENT.

InnoDB - данные упорядочены, что плохо для флэш-накопителей (поскольку данные должны быть переупорядочены после вставки = дополнительные записи). Очень быстро для чтения PRI KEY, медленно для записи.

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

myISAM / innoDB имеет огромное значение для обычных и флэш-накопителей (я не знаю, что насчет SQLite), но я бы предпочел использовать mysql / myisam.

Answer 3

Я на самом деле предпочитаю использовать SQLiteSpy http://www.portablefreeware.com/?id=1165 в качестве интерфейса SQLite. Он поддерживает такие вещи, как REGEXP, которые могут пригодиться.