Documentation index
- ReadMe
- Things To Know
-
- New Style Rotation
Если вы используете только трейд - эта статья не имеет особого значения, тк трейд практически не создает нагрузки на mysql. Актуальная статья для тех, кто использует ротацию, причем с большими базами.
В большинстве своем данная статья повторяет то что знает любой админ и написано множество раз в сотнях тысяч статей. Тут будет отмечено скорее в отношении конкретно SmartCJ.
Вводные: данные базы хранятся на диске, работа с диском медленная (намного медленне чем с памятью). Дабы ускорить работу - придумали индексы. Если сильно упростить ситуацию: индекс это как оглавление в книге, когда вы знаете, что какие-то данные находятся в 3й главе например. Вы можете посомтреть оглавление, перейти сразу к 3й главе и уже искать там, тем самым избавившись от необходимости просматривать главы 1 и 2.
Вводная 2: базе есть таблицы, где хранятся данные галер\тумб. Условно тумба1 была показана 100 раз, кликнули по ней 20 раз и тп. Тк тумб и данных к ней много (не редкость базы по 500-600к тумб) то и данных получается довольно много (бывает и по гигу). Существует много типов хранения данных, но нас конкретно интерисуют 2 типа: MyISAM и InnoDB. MyISAM - дефолтный движек и он по дефолту он юзается в SmartCJ, но это устаревший движек, если можно так выразится.
В чем разница применительно к этой статье:
Основное, MyISAM хранит индекс и данные как 2 отдельных файлах, а InnoDB - как один файл и индекс встроен в этот файл. Как результат при запросе к таблице типа MyIsam, Mysql кеширует файл с индексами, поэтому крайне важно что бы сетинга key_buffer_size была достаточной, что б вместить туда все инедксы (они примерно 15% от размера данных). При запросе мускл смотрит по индексу с какого места начинать искать в датафайле и начинает искать. Этот датафайл лежит на диске и соответственно эта операция - медленная, и ее ускорением, насколько это возможно, занимается система (те обычный кеш операций с диском) с перменным успехом.
Если же мы используем InnoDB то, как уже было сказано выше, у него нет отдельного индексного файла, а он встроен в датафайл. Выглядит это так условно: в начале датафайлеа написано “в этой части у нас хранится инфа об ИД 1,2,3,4 и 5, следующуая часть начинается с 123784 байта этого файла”, mysql смотрит - 1-5 нам не надо, идем дальше к сл части и читаем начиная с позиции 123784 байт. Таким образом для InnoDB крайне важно держать в памяти весь датафайл и параметр отвечающий за это называется innodb_buffer_pool_size. Кеш самого mysql в отношении датафайлов эффективнее чем кеш самой системы и как результат, если датафайл полностью влезает в память - InnoDB в выборках обгоняет MyISAM на 25-35%. Однако как только файл перестает увлезать в память - у InnoDB начинается намного больше работы с диском, чем у MyIsam и как следствие он резко отстает от MyISAM.
К тому же у InnoDB есть понятие транзакций - это значит, что эти таблицы более устойчивы к сбоям в системе, у MyISAM такого нет. Цена этого - добавление данных в MyISAM быстрее. Но галеры добавляются обычно не так много, дабы обращать на это внимание.
И еще одно актуальное преимущество InnoDB перед MyISAM row lock VS table lock . Что это такое: например у нас есть таблица тех же тумб. В определенный момент крон пишет в таблицу обновленные ЦТР тумб, и пока он обновляет эти данные - лочится вся таблица тумб. Это значит что если обновремено в этот же момент пришел серфер и и для генерации страницы надо выбрать какие то данные из базы тумб, то скрипту придется ждать пока крон довыполняет обновление ЦТР. Серферу страница будет сгенерена медленее чем могла бы. У InnoDB - row lock, это значит если мы обновляем Цтр тумбы 1, то скрипт без проблем может в этот же момент получить данные о тумбе 2. Это сказывается на общей скорости работы сайта.
Исходя из того что:
будет поставлен скрипт , дефолтные таблицы - MyISAM, поскольку дефолтные настройки innodb очень маленькие.
Однако, если вы будете заниматься настрокой MySQL то сможете добиться 40% ускорения работы базы при условии того, что переведете ее на InnoDB. Однако не забывайте: как только датафайл перестанет влезать в память - скорость работы станет хуже, чем с MyIsam.
Одновные ньансы InnoDB:
И для MyISAM и для InnoDB:
Несомтря на то, что написано выше конвертировать толкьо 3 таблицы, многие конвертирую вообще всю базу. Это не очень хорошая идея с точки зреня экономии памяти. Если остальные таблицы, например таблица с реферами, конвертированы в иннодб то при обновлении информации там (а это каждую минуту)эта информация попадает в пул, тем самым занимая там место. Более того учитывая что обновляется она каждую минуту - mysql может посчитать что это достаточная интенсивность и держать там ее вытеснив какую то часть rot_*. Но при этом работа в rot_* идет постоянно, а реферы админ смотрит хорошо если раз в сутки.
Таким образом для экономии имеет смысл конвертировать только таблицы rot_* , а для еще бОльшей - rot_galleries, rot_gallery_stats* and rot_gallery_data*.