Статьи

MySQL от 3 до 4 Миграция в реальном мире

Существуют всевозможные технические документы и документы по архитектуре, посвященные функциям и преимуществам перехода с MySQL 3 на MySQL 4. Иногда лучший вариант — это сделать это на переднем крае реального веб-бизнеса.

Недавно у меня была возможность пообщаться с Тайсоном Лоури, разработчиком и владельцем сайта онлайн-фэнтези-бейсбола SimDynasty.com, и узнать его опыт в продвижении MySQL, маркетинге сайта и его взгляды на Java и PHP.

Можете ли вы рассказать нам немного о себе?

Я вырос в Акроне, штат Огайо, до того, как поступил в Бостонский колледж, где специализировался в области компьютерных наук и бизнеса. После этого я начал работать в GE Capital (подразделение General Electric), где работал над различными проектами. Большинство технологий принадлежало Microsoft, а некоторые проекты Java и Oracle были разбросаны здесь и там.

После того, как я ушел из GE, я начал свою собственную консультацию по технологиям Teeloh Technology. Моя специальность — веб-приложения на основе баз данных, особенно в сфере финансовых услуг и недвижимости. Но в последнее время я занимался проектной работой и для игровых компаний.

Что заставило вас разработать и запустить сайт фэнтези-бейсбола?

Я действительно заинтересовался некоторыми технологиями с открытым исходным кодом, в частности Java и MySQL. Я начал заниматься симуляцией бейсбола, SimDynasty.com, по вечерам, работая в GE, в основном для экспериментов с Java и MySQL. Мало ли я знал, что это станет большим хитом.

Можете ли вы расширить на технологическую платформу сайта?

Конечно, но сначала позвольте мне рассказать вам немного о сайте, чтобы вы могли следовать примерам и понять, как мы используем MySQL немного лучше. Sim Dynasty — это симулятор бейсбола, который бросает вызов людям в вопросах владения командой и менеджеров в бейсболе. Каждый владелец команды набирает команду вымышленных бейсболистов и выступает в роли владельца и менеджера команды. Они могут торговать игроками, составлять составы, готовить игроков в младших лигах и т. Д.

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

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

Сайт работает с использованием Java, JSP и MySQL 4.0 на сервере Linux — мы немного используем PHP для форума и нескольких других небольших областей. В настоящее время мы находимся на MySQL 4.0.18. Я не могу ждать, пока 4.1 не станет готовым к производству — наконец, здесь есть выборки!

Когда вы запускаете сайт, кажется, вы были на MySQL 3.2x? Как вы планировали переход на 4.x?

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

Какие факторы заставили вас принять решение о миграции?

Основная причина, по которой мы обновились, заключалась в том, что InnoDB можно было использовать. Я заметил, что страницы были очень медленными, и осознал проблему при мониторинге количества заблокированных запросов в SHOW STATUS.

У нас интересная ситуация, с которой большинство сайтов не сталкиваются. На многих сайтах MySQL имеется масса запросов Select, но не так много вставок, удалений или обновлений. Или, если они есть, они сделаны в непиковые часы.

Природа нашего сайта имеет почти каждую таблицу обновляется от сотен до тысяч раз в час. Это сделало переход на 4.0 критическим по мере роста нашего сайта, чтобы мы могли использовать таблицы InnoDB. Использование InnoDB для часто обновляемых таблиц изменило нашу игру, поскольку при выполнении обновлений используется блокировка уровня строк вместо блокировки таблиц. Это позволяет нашим программам на Java и страницам JSP обновлять таблицы, в то время как наши посетители просматривают данные из таблиц или даже обновляют данные.

Можете ли вы поделиться некоторыми советами и хитростями MySQL, обнаруженными в процессе?

Некоторые из приемов, которые я изучил, не интуитивны. Если вы используете соединения между двумя таблицами, производительность значительно улучшается, если размеры столбцов одинаковы. Например, если у вас есть одна таблица с именем customer с первичным ключом customer_idorder_customer_idint(10)int(5) Например, изменение их обоих на int(10)

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

Я рекомендую вам включить медленный журнал запросов для MySQL. Это было хорошей отправной точкой для определения, какие запросы выполнялись медленно. Когда я нахожу медленный запрос, я использую запрос MySQL Analyze, который показывает, сколько строк читается из каждой таблицы и как они объединяются. Обычно вы можете найти лучший способ получить один и тот же набор результатов, не сканируя столько строк, либо добавляя индексы в таблицы, либо присоединяя запрос по-разному.

Были ли какие-то икоты или уроки на этом пути?

Решение о том, какие таблицы перемещать в InnoDB из MyISAM, является постоянным процессом. MyISAM имеет тенденцию работать лучше при чтениях — если вы можете избежать блокировки всей таблицы. В нашей основной базе данных 34 таблицы, 7 из которых являются таблицами InnoDB.

Есть несколько других таблиц, которые могут быть кандидатами на изменение в будущем. Мы отслеживаем запросы, чтобы увидеть, становится ли блокировка проблемой с любым из них. Хороший инструмент, который мы нашли, называется mytop. Он как бы берет то, что вы видели в MySQL из SHOW STATUS и несколько других команд, и представляет его в формате, похожем на команду top Linux. Вы можете видеть, что запросы выполняются прямо перед вами — вы можете видеть, сколько времени они занимают, и заблокированы ли какие-либо запросы.

Другой недостаток, который мы заметили, заключается в том, что в некоторых случаях в течение нескольких дней каждый месяц или около того таблица может испытывать период, когда она действительно сильно страдает от обновлений. Например, плей-офф всех наших лиг происходит примерно в одно и то же время. Таким образом, есть определенные таблицы, которые будут читаться и записываться довольно часто, но это длится всего около 3 дней, и это происходит только раз в два месяца. В течение этого времени мы фактически переключаем таблицу на InnoDB, чтобы использовать блокировку на уровне строк, и возвращаем ее в MyISAM в остальное время — когда она обычно не записывается в.

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

Как насчет результатов? Отслеживали ли вы какие-либо показатели производительности после миграции?

Извините, я хотел бы иметь некоторые цифры. Я могу просто сказать с точки зрения клиента, что сайт летит. Когда мы запускали наши игры-симуляторы в течение дня, это было настолько медленно, что нам приходилось запускать бесплатные игры в одночасье, чтобы остальная часть сайта не была слишком медленной. Это больше не проблема.

Количество игроков, в которых мы играем, значительно выросло, и я думаю, что многое из этого связано с лучшей производительностью сервера. Иногда в прошлом загрузка определенных страниц могла занимать до 10 секунд — это может утомить человека изо дня в день, и я думаю, что из-за этого мы потеряли много людей.

Вы используете Java и PHP, это правильно? У вас есть какой-либо совет или есть какие-то методы, которые вы выбрали, используя Java на MySQL, в отличие от PHP?

И JSP, и PHP имеют свои преимущества и недостатки. Если вам понадобятся программы для запуска на сервере, моя философия заключается в том, что вам следует использовать решение J2EE, чтобы вы могли делиться кодом между исполняемыми программами и сервлетами или JSP. Но PHP обычно создает меньшую нагрузку на сервер, чем Tomcat, и кажется, что с PHP меньше движущихся частей с точки зрения настройки и конфигурации сервера — это означает, что меньше вещей может пойти не так.

Что касается взаимодействия с MySQL, я не заметил много различий в производительности. PHP немного сложнее для начинающих, чтобы понять, как подключиться к базе данных. Но с точки зрения производительности я не видел большой разницы. Было бы интересным экспериментом выполнить те же самые запросы с использованием PHP и JSP и измерить результаты — возможно, что-то, что я могу сделать в дождливый день.

Как вы продали сайт? Это привело к увеличению числа подписчиков?

Сайт в основном продавался с использованием платных поисковых систем, таких как Google Adwords и Overture. Мы также размещаем рекламу на других сайтах, связанных с бейсболом. Обычно на нашем сайте ежедневно просматривается от 75 000 до 100 000 просмотров, а количество зарегистрированных пользователей достигает 25 000.

У нас также есть программа «Пригласи друга», поэтому новости сайта распространяются из уст в уста.

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

Мы начали использовать некоторые сценарии мониторинга на сервере, чтобы сообщить нам, когда возникли проблемы с сайтом. Но одна из проблем, с которой мы столкнулись, заключалась в том, что если бы возникла серьезная проблема, сценарии также перестали бы работать. Теперь мы используем компанию Alerta для мониторинга наших сайтов. В течение нескольких долларов в месяц они просматривают нас, если есть проблема с неработающим сайтом.

Webmasterworld.com — это универсальный веб-сайт с полезными советами по всем вопросам — от поиска хостинговой компании до маркетинга вашего сайта и вопросов о синтаксисе HTML. Это действительно ценный сайт, если вы не видели его раньше.

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

SitePoint благодарит Тайсона за его время. Проверьте SimDynasty.com .