SQLite быстрее, чем MySQL?
Я хочу настроить сервер teampeak 3. Я могу выбирать между SQLite и MySQL в качестве базы данных. Ну, я обычно склонен "не использовать SQLite в производстве". Но с другой стороны, это сервер teampeak. Ну хорошо, просто дайте мне погуглить это... Я нашел это:
- скорость
SQLite3 намного быстрее, чем база данных MySQL. Это потому, что файловая база данных всегда быстрее, чем сокет Unix. Когда я запросил редактирование канала, это заняло около 0,5-1 с в базе данных MySQL (127.0.0.1) и почти мгновенно (0,1 с) в SQLite 3. [...]
http://forum.teamspeak.com/showthread.php/77126-SQLite-vs-MySQL-Answer-is-here
Я не хочу начинать дебаты SQLite против MySQL. Я просто хочу спросить: действительно ли его аргумент верен? Я не могу представить, что это правда, что он говорит. Но, к сожалению, я не достаточно опытен, чтобы ответить на этот вопрос сам.
Возможно, у разработчиков TeamSpeak есть некоторые существенные различия в их архитектуре БД между SQLite и MySQL, что объясняет огромную разницу в скорости (я не могу себе это представить).
4 ответа
В первый раз время доступа появится быстрее в SQLite
Время доступа к SQLite вначале будет отображаться быстрее, но это происходит с небольшим количеством пользователей в сети. SQLite использует очень упрощенный алгоритм доступа, он быстрый, но не обрабатывает параллелизм.
По мере того, как база данных начинает расти, и от количества одновременного доступа она начнет страдать. Способ, которым серверы обрабатывают несколько запросов, совершенно другой, более сложный и оптимизированный для обеспечения высокого уровня параллелизма. Например, SQLite заблокирует всю таблицу, если происходит обновление, и поставит в очередь заказы.
СУБД делает много дополнительной работы, которая делает их более масштабируемыми
Например, MySQL, даже с одним пользователем, создаст QUEUE доступа, частично заблокирует таблицы вместо того, чтобы разрешать только одно пользовательское выполнение, и другие довольно сложные задачи, чтобы гарантировать, что база данных все еще доступна для любого другого одновременного доступа.
Это замедлит соединение с одним пользователем, но окупится в будущем, когда сотни пользователей будут в сети, и в этом случае простая процедура "ЗАБЛОКИРОВАТЬ ВЕСЬ СТОЛ И ВЫПОЛНИТЬ ОДИНОЧНЫЙ ЗАПРОС КАЖДОГО ВРЕМЕНИ" SQLite приведет к перегрузке сервера,
SQLite сделан для простоты и автономных приложений баз данных.
Если вы ожидаете одновременной записи 10 записей в базу данных одновременно, SQLite может работать хорошо, но вам не нужно приложение для 100 пользователей, которое постоянно записывает и считывает данные в базу данных с использованием SQLite. Он не был разработан для такого сценария, и он будет уничтожать ресурсы.
Учитывая ваш сценарий TeamSpeak, вы, вероятно, будете в порядке с SQLite, даже для некоторого бизнеса это нормально, некоторые веб-сайты нуждаются в базах данных, которые будут только для чтения, если только при добавлении нового контента.
Для такого использования SQLite - это дешевое, простое в реализации, самодостаточное, идеальное решение, которое выполнит работу.
Отличие заключается в том, что SQLite использует гораздо более простой алгоритм блокировки (простая глобальная блокировка базы данных).
Использование мелкозернистой блокировки (как это делают MySQL и большинство других серверов БД) намного сложнее и медленнее, если существует только один пользователь базы данных, но необходимо, если вы хотите разрешить больше параллелизма.
Я лично не тестировал SQLite против MySQL, но в Интернете легко найти примеры, которые говорят об обратном ( например). Вы задаете вопрос, который не настолько религиозен: этот аргумент действителен?
Во-первых, суть аргумента несколько показательна. Сокет Unix будет использоваться для связи с сервером базы данных. "Файловая база данных", по-видимому, относится к тому факту, что связь осуществляется через скомпилированный интерфейс. В терминологии SQLite это не сервер. Большинство баз данных хранят данные в файлах, поэтому терминология "файловая база данных" немного вводит в заблуждение.
Производительность базы данных зависит от нескольких факторов, таких как:
- Передача запроса в базу данных.
- Скорость компиляции (возможность хранить предварительно скомпилированные запросы здесь является плюсом).
- Скорость обработки.
- Способность обрабатывать сложные обработки.
- Оптимизация компилятора и алгоритмы исполнения.
- Передача результатов обратно в приложение.
Компилирование интерфейса влияет на первый и последний из них. Нет ничего, что мешало бы безлимитной базе данных превзойти остальных. Однако на серверах баз данных обычно миллионы строк кода - намного больше, чем в SQLite. Многое из этого поддерживает дополнительную функциональность. Некоторые из них поддерживают улучшенную оптимизацию и лучшие алгоритмы.
Как и в большинстве вопросов о производительности, ответ заключается в том, чтобы самостоятельно протестировать системы на своих данных в вашей среде. Отсутствие сервера - это не автоматическое увеличение производительности. Наличие сервера не делает базу данных "лучше". Это разные приложения, предназначенные для разных точек оптимизации.
Коротко:
- Для баз данных локальных приложений, однопользовательских приложений и небольших простых проектов, хранящих небольшие данные, SQLite является победителем.
- Для приложений сетевых баз данных, многопользовательского режима и параллелизма, балансировки нагрузки и управления растущими данными, безопасности и проверки подлинности на основе роликов, крупных проектов и широко используемых сервисов вам следует выбрать MySql.
В вашем вопросе я мало знаю о серверах teampeak и о том, какие данные ему действительно нужно хранить в своей базе данных, но если ему просто нужна локальная СУБД и не нужно обрабатывать много параллелизма и управления, я выберу SQLite.