Ограничена ли скорость доступа к базе данных MySQL в первую очередь БД или языком, используемым для доступа к ней?

Question

Мне нужно быстро обновить большой БД. Возможно, будет проще писать код на языке сценариев, но я подозреваю, что программа на Си сделает обновление быстрее. Кто-нибудь знает, были ли сравнительные тесты скорости?

Answer 1

Вас беспокоит скорость, потому что вы уже сталкиваетесь с ситуацией, когда скорость является проблемой, или вы просто планируете заранее?

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

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

В конце концов, четвертый компонент LAMP - это язык сценариев. При тонкой настройке memcache становится опцией, а также постоянными интерпретаторами (например, mod_perl в веб-среде).

Answer 2

Не будет. Скорость обновления зависит от:

• конфигурация базы данных (используется двигатель, db config)
• аппаратное обеспечение сервера, особенно подсистема HDD
• пропускная способность сети между источником и целевой машиной
• количество переданных данных

Я подозреваю, что вы думаете, что язык сценариев станет боровом в этой последней части - количестве передаваемых данных.

Любой язык сценариев будет достаточно быстрым для доставки данных. Если у вас есть большой объем данных, которые вам нужно быстро проанализировать / преобразовать - тогда да, C определенно будет предпочтительным языком. Однако, если он отправляет простые строковые данные в базу данных, это не имеет смысла, хотя не так сложно создать простую C-программу для операции UPDATE. Это не так сложно сделать в C, это почти наравне с использованием PHP-функций mysql_ с точки зрения «сложности».

Answer 3

Большинство затрат в транзакциях базы данных лежат на стороне базы данных.Стоимость интерпретации / компиляции вашего оператора SQL и оценки выполнения запроса намного более существенна, чем любая разница в языке, который его отправил.

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

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

Answer 4

API C будет немного быстрее по той простой причине, что любой другой язык (независимо от того, является ли он «языком сценариев» или полностью скомпилированным языком), вероятно, на каком-то уровне будет отображать этот язык наC API.Использование C API напрямую, очевидно, будет на несколько десятков циклов ЦП быстрее, чем выполнение операции отображения, а затем использование C API.

Но это просто плевок в океане.Даже доступ к основной памяти на порядок или два медленнее, чем циклы ЦП на современной машине, а операции ввода-вывода (доступ к диску или сети) по-прежнему на несколько порядков медленнее.Нет смысла оптимизировать процесс, чтобы ускорить отправку запроса на микросекунду, если на выполнение запросов, которые являются сложными или для проверки / возврата больших объемов данных, потребуется полсекунды (или даже несколько секунд).

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

Answer 5

Поскольку C - язык более низкого уровня, у него не будет накладных расходов при разборе / преобразовании типов, как у языков сценариев. MySQL int может отображаться непосредственно в C int, тогда как PHP int имеет различные метаданные, которые необходимо заполнить / обновить.

С другой стороны, если вам нужно будет выполнять какие-либо манипуляции с текстом в рамках этого большого обновления, любой выигрыш в скорости C будет, вероятно, потерян при наложении / отладке из-за его слабой поддержки манипуляции со строками по сравнению с тем, что вы могли бы сделать с тривиальным легкость в языке сценариев, таких как Perl или PHP.

Answer 6

Я слышал предположение, что C API работает быстрее, но я не видел никаких тестов. Для быстрого выполнения операций с большой базой данных независимо от языка программирования используйте хранимые процедуры: http://dev.mysql.com/tech-resources/articles/mysql-storedprocedures.html.

Скорость объясняется тем, что в сети снижается нагрузка.

По этой ссылке:

Хранимые процедуры быстрые! Ну мы пока не могу доказать это для MySQL, и Опыт каждого будет отличаться. Какие мы можем сказать, что сервер MySQL использует некоторые преимущества кэширования, просто как подготовленные заявления делают. Здесь нет компиляция, поэтому SQL хранится процедура не будет работать так быстро, как процедура написана с внешним язык, такой как C. Основная скорость выигрыш приходит от сокращения сети движение. Если у вас есть повторяющееся задание что требует проверки, зацикливания, несколько утверждений, и нет пользователя взаимодействие, сделать это с помощью одного звонка к процедуре, которая хранится на сервер. Тогда не будет сообщений переходя назад и вперед между сервером и клиент, на каждом этапе задача.

Answer 7

Я обнаружил, что для больших пакетов данных (гигабайтов или более) обычно быстрее выгрузить данные из mysql в файл или несколько файлов на компьютере приложения.Затем обработайте его там (с вашим любимым инструментом, здесь: Perl) и используйте LOAD DATA LOCAL INFILE, чтобы отбросить его обратно в новую таблицу, делая при этом как можно меньше в SQL.При этом вы должны

• удалить индексы из таблицы перед ЗАГРУЗКОЙ (может быть, это не нужно для MyISAM, но не всегда).

• всегда, ВСЕГДА загружайте данные в порядке PK!

• добавляйте индексы после завершения загрузки.

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

В любом случае.Большие наборы данных обычно означают, что DB является узким местом.