Нужно ли мне больше системных ресурсов для запуска DB2 вместо MySQL?
Мне нужно преобразовать мое веб-приложение из MySQL для работы на DB2. Мне нужно заранее знать, нужен ли мне сервер с высокими техническими характеристиками, чтобы веб-приложение работало с той же скоростью, что и сейчас на MySQL.
Приложение представляет собой приложение для анализа данных с интенсивным использованием базы данных и интерфейсом браузера. Сейчас он использует только около 20% доступной мощности процессора и 30% памяти на сервере. Потребуется ли больше ЦП или памяти при преобразовании в DB2? Нужен ли мне сервер высокой спецификации?
Я просто ищу общее представление о том, потребуется ли обновление сервера для преобразования MySQL в DB2, если все остальное останется равным (размер базы данных, трафик и т. Д.).
3 ответа
Вы используете isam или innodb?
Как правило, DB2 требует меньше системных ресурсов, чем текущие версии mysql. однако, если вам нужна производительность и размер базы данных не слишком велик, вы, возможно, захотите переключиться на postgresql, поскольку он значительно менее "полезен" (читай: раздутый), чем mysql., иногда вам НУЖНО mysql, но если вы этого не сделаете, обычно лучше использовать pgsql.
Я не думаю, что это будет иметь большое значение, если вы запустите MySQL или DB2. Однако вы не будете уверены в производительности, если не попробуете это сами. Я рекомендую вам попробовать его в среде тестирования, аналогичной вашей текущей системе.
DB2 должна довольно эффективно использовать память на сервере, если вы оставите ее включенной функцию самонастраивающегося управления памятью (STMM) при условии, что процессы вне DB2 распределяют и освобождают свою память в хорошем режиме. STMM регулирует размер нескольких важных буферов и куч памяти, чтобы приспособиться к постоянно меняющейся рабочей нагрузке базы данных. Эта функция была включена по умолчанию для последних двух основных выпусков DB2 и обычно имеет параметры памяти, которые почти идентичны базе данных, настроенной вручную экспертом DB2. Одним из предостережений STMM является то, что в дизайне запрещено делать резкие скачки в размерах памяти, что означает, что STMM может потребоваться внести несколько дополнительных изменений, чтобы приспособиться к резкому скачку или падению использования базы данных. DB2 предлагает множество встроенных функций мониторинга, которые помогут вам отслеживать эффективность и схемы роста внутренних структур памяти, чтобы вы могли быстро получить представление о том, как "нормально" выглядит для конкретной рабочей нагрузки.
Со стороны ЦП одним из самых больших рисков для хорошей производительности и масштабируемости является сканирование, которое сжигает циклы ЦП, даже когда все необходимые страницы данных уже кэшированы в памяти буферного пула. Понимание того, как работают индексы и когда они будут использоваться или игнорироваться для конкретных операторов SQL, особенно важно по мере роста таблиц и расширения запросов. Иногда неприемлемое сканирование происходит не из-за плохих предикатов индексации или паршивого соединения, а из-за того, что статистика кардинальности и распределения таблицы, собираемая RUNSTATS, устарела, что вводит в заблуждение оптимизатор запросов DB2 на основе затрат, чтобы недооценить последствия использования частичного или полного сканирования, Утилита db2expln покажет план доступа для предложенного запроса с учетом текущей статистики. Во время выполнения также можно отслеживать количество прочитанных (отсканированных) строк по сравнению с фактически выбранными строками, что может дать вам представление о том, сколько происходит оттока для получения наборов результатов для вашей рабочей нагрузки.