Оптимизация MySQL (конфигурация)

Пока, для старта я нарыл скриптик, запустив который покажет, что вам надо донастроить в мускуле.

http://day32.com/MySQL/

perl5 to python Введение

Почему?

Был я на конференции ua web. На ней докладывали о MVC от python – Django. Перед докладом я поговорил с докладчиком о питоне, сказал, что посматриваю на него как на альтернативный для себя язык. Он рассказал, что сам переходил с перла на него, быстро обучился, сейчас в полне доволен. Да и заточне он не только под веб.

Порыв чуть глубже: РИТ 2007 – Яндекс рассказывает про то, что в своих стартапах они юзают именно питон и именно этот фреймворк.

YouTube тоже питон, только они его компилят.

Справедливости ради необходимо заметить, что у перла тоже есть MVC, с очень большим сообществом, очень легко расширяемо – Catalyst .

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

Оптимизация MySQL (базовая)

Это на самом беде компиляция многих статей. О которых будет сказано вконце

Итак, подборка советов из newcontimemt.ru:

 

Оптимизация самих запросов.

 

• Используйте постоянные подключения к базе данных, чтобы избежать накладных расходов на текущие подключения. Если Вы не можете использовать постоянные подключения, и Вы делаете много новых подключений, стоит изменить значение переменной thread_cache_size
• Обязательно проверьте, что все Ваши запросы в самом деле используют индексы, которые Вы создали в таблицах. В MySQL Вы можете сделать это командой EXPLAIN.
• Избегайте сложных запросов SELECT на таблицах, которые часто модифицируются. Это должно помочь избежать проблем с блокировкой таблицы.
• Новые таблицы MyISAM могут вставлять строки в таблицу без удаленных строк в то же самое время, когда другой запрос ведет чтение. Если это важно для Вас, Вы должны рассмотреть методы, где Вы не должны удалить строки или выполните OPTIMIZE TABLE после того, как Вы удалили много строк сразу.
• Используйте вызов ALTER TABLE ... ORDER BY expr1,expr2... если Вы обычно получаете строки в порядке expr1,expr2,… . Используя эту опцию после внесения больших изменений для таблицы, Вы можете получить значительно более высокую эффективность.
• В некоторых случаях может иметь смысл представлять столбец, который является хэшем, основанным на информации из других столбцов. Если этот столбец короткий и приемлемо уникальный, это может быть намного быстрее, чем большой индекс на многих столбцах. В MySQL это очень легко в использовании: SELECT * FROM table_name WHERE hash=MD5(concat(col1,col2)) AND col_1='constant' AND col_2='constant'
• Для таблиц, которые часто изменяются, Вы должен пробовать избежать любых столбцов типов VARCHAR или BLOB. Вы получите динамическую длину строки, как только Вы используете хоть один стобец VARCHAR или BLOB.
• Если Вы очень часто должны вычислять значения, основанные на информации из большого количества строк (подобно количеству), вероятно, намного лучше представить новую таблицу и модифицировать счетчик в реальном времени. Модификация типа UPDATE table set count=count+1 where index_column=constant очень быстрая! Это действительно важно, когда Вы используете базы данных подобные MySQL, которые имеют только блокировку уровня таблицы. Это также даст лучшую эффективность с большинством баз данных, поскольку администратор блокировки строки в этом случае будет иметь куда меньше работы.
• Если Вы должны собрать статистику из больших таблиц файла регистрации, используйте итоговые таблицы вместо того, чтобы просмотреть целую таблицу. Поддержание резюме должно быть намного быстрее, чем попытка сделать живую статистику. Намного быстрее получить новые итоговые таблицы из файлов регистрации, когда происходит изменение, чем менять работающее приложение!
• Если возможно, нужно классифицировать отчеты как «живые» или «статистические», где данные, необходимые для статистических отчетов, сгенерированы только, исходя из итоговых таблиц, которые в свою очередь были сгенерированы из фактических данных.
• Воспользуйтесь преимуществом того факта, что столбцы имеют значения по умолчанию. Вставляйте значения явно только, когда значение, которое будет вставлено, отличается от значения по умолчанию. Это уменьшает синтаксический анализ, который MySQL должен сделать, и улучшает быстродействие вставки.
• В некоторых случаях удобно упаковывать и сохранить данные в blob. В этом случае Вы должны добавить некоторый дополнительный код к Вашей прикладной программе, чтобы упаковать/распаковать данные, но это может сохранить много времени доступа в некоторой стадии. Это удобно, когда Вы имеете данные, которые явно не соответствуют статической структуре таблицы.
• Обычно Вы должны пробовать хранить все данные неизбыточными (что названо третьей нормальной формой в теории базы данных), но Вы не должны бояться дублирования или создания таблиц-резюме, если Вы нуждаетесь в них, чтобы получить большее быстродействие.
• Сохраненные процедуры или UDF (определяемой пользователем функции) может быть хорошим способом получить большую эффективность. В этом случае Вы должны, однако, всегда иметь способ делать это некоторым другим (более медленным) путем, если Вы используете СУБД, которая не поддерживает это.
• Вы можете всегда получать неплохие результаты, кэшируя запросы/ответы в Вашей прикладной программе и пробуя делать много вставок/модификаций в то же самое время. Если Ваша база данных поддерживает блокировки таблиц (подобно MySQL и Oracle), это должно помочь гарантировать, что индексный кэш сбрасывается только однажды после выполнения всех модификаций.
• Используйте INSERT /*! DELAYED */, если Вы не должны знать, когда Ваши данные будут записаны. Это ускоряет дела потому, что много записей могут быть выполнены за один дисковый обмен.
• Используйте INSERT /*! LOW_PRIORITY */, когда Вы хотите, чтобы Ваши вызовы select были более важными.
• Используйте SELECT /*! HIGH_PRIORITY */, чтобы получить select, обходящий очередь. То есть select будет выполнен, даже если имеется кто-то ждущий, чтобы сделать запись в таблицу.
• Используйте многострочную инструкцию INSERT, чтобы сохранить много строк одной командой SQL (многие серверы SQL поддерживают это).
• Используйте LOAD DATA INFILE, чтобы загрузить большие количества данных. Это быстрее, чем нормальные вставки, а будет еще быстрее, когда myisamchk интегрирован в mysqld.
• Используйте столбцы с поддержкой AUTO_INCREMENT, чтобы сделать уникальные значения.
• Используйте OPTIMIZE TABLE время от времени, чтобы избежать фрагментации при использовании динамического формата таблицы.
• При использовании нормальной установки Web-сервера, изображения должны быть сохранены как файлы. То есть сохраните только ссылку на файл в базе данных. Основная причина для этого в том, что нормальный Web-сервер намного лучше при кэшировании файлов, чем содержание базы данных. Так что намного проще получить быструю систему, если Вы используете файлы.
• Используйте таблицы в памяти для некритических данных, к которым обращаются часто (подобно информации относительно последнего показанного баннера для пользователей, которые не имеют cookie).
• Столбцы с идентичной информацией в различных таблицах должны быть объявлены идентично и иметь одинаковые имена. До Version 3.23 Вы получали медленные объединения в противном случае. Старайтесь делать имена проще (например, name вместо customer_name в таблице заказчиков). Чтобы сделать Ваши имена переносными на другие SQL-серверы, Вы должны озаботиться тем, чтобы они не превышали в длину 18 символов.
• Если Вы нуждаетесь в ДЕЙСТВИТЕЛЬНО высокой скорости, Вы должны смотреть на интерфейсы низкого уровня для хранения данных, которые поддерживают различные серверы SQL! Например, обращаясь к MySQL MyISAM непосредственно, Вы могли бы получить увеличение быстродействия в 2-5 раз в сравнении с использованием интерфейса SQL. Чтобы сделать это, данные должны быть на том же самом сервере, что и прикладная программа, и обычно к ним можно обратиться только одним процессом (потому, что внешняя блокировка файла работает очень медленно). Можно было устранить вышеупомянутые проблемы, представляя команды MyISAM низкого уровня в сервере MySQL (это могло бы быть одним простым способом получить большее количество эффективности, если необходимо).
• Во многих случаях быстрее обратиться к данным из базы данных (используя открытое подключение), чем к текстовому файлу только потому, что база данных, вероятно, будет более компактна, чем текстовый файл (если Вы используете числовые данные), и это потребует меньшее количество дисковых доступов. Вы также уменьшите код потому, что Вы не должны анализировать Ваши текстовые файлы, чтобы найти в них границы столбца и строки.
• Объявление таблицы с DELAY_KEY_WRITE=1 будет делать модифицирование индексов быстрее, поскольку они не регистрируются на диске, пока файл не закрыт. Обратная сторона в том, что Вы должны выполнить myisamchk на этих таблицах прежде, чем Вы запускаете mysqld, чтобы гарантировать, что они правильные, если что-то уничтожило mysqld в середине запроса. Поскольку информация ключа может всегда генерироваться из данных, Вы не должны терять что-нибудь, используя DELAY_KEY_WRITE.

 

 

 

 

Использовался материал:

 

1) http://newcontinent.ru/h/mysqlc/14.htm

2) http://dev.mysql.com/doc/refman/5.1/en/query-speed.html

случайно в инете наступил на пару топов перл модулей

http://qa.perl.org/phalanx/100/

http://www.serpentine.com/blog/2008/02/19/peruse-popular-perl-packages/

Прошелся по блогам.

Сегодня прошелся по некоторым блогам, которые втянуты у меня в ридер. Там поди под 3000 постов ждут своего прочтения.

Наткнулся на множество интересных новостей:

Jevix – средство автоматического применения правил набора текстов, наделённое способностью унифицировать разметку HTML/XML документов, контролировать перечень допустимых тегов и атрибутов, предотвращать возможные XSS-атаки в коде документов.

Тема вроде интересная надо завтра попробовать покушать.

И наткнулся на видео материалы РИТ-2007 Ну там вообще не паханое поле. ЗАвтра мож буду просматривать и мож на чонить интересное наткнусь.

Состояние на текущий момент.

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

КодеИДЕ – на серверной части – Perl (Catalyst,POE) , lighttpd nginx. На стороне клиента – JQuery

В киосках больше упор идет на секьюр.

Ну и как всегда буду рассказывать вам про интересные новости из инета, а также новые и интересные сервисы.

Обзор свободных сервисов в помощь дизайнеру. Фото сервисы

Итак… Вы не дизайнер, точнее вы знаете, что такое тег «БР», и примерно представляете, как состряпать табличку, а в ней еще одну табличку, а в той еще одну, нужные моменты выделим тегом Б, все и вот и все что вы знаете о дизайне. Так и есть? СУПЕР! Могу вас поздравить, вы знаете о дизайне столько же, сколько и я )

Мой любимый Стамбл наткнул меня на статью:

http://www.snap2objects.com/2007/06/06/85-killer-resources-every-designer-should-know/

85+ безплатных, убивающих ресурсов, которые должен знать каждый дизайнер.

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

В этом посте расскажу про архивы фоток, бекграундов, анимаций, вобщем архивы картинок необходимых дизайнеру.

MorgueFile

morgue – морг, покойницкая (французский термин)

короче тупо склад фоток, и довольно удобный их просмотр.

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

Image*After

Сразу предупреждаю, выглядит довольно серенько, посему слабонервным и куртым дизайнерам можно пропустить, хотя видок довольно раритетненький. Хотя при наведении подгружает увеличенную фотку ( что видел не во всех ресурсах такого типа)

Зато тут сразу все просто, тыцнул, увидел, стырял, счаслив.

Вверху и внизу маленькие фотки с внешних ресурсов с ссылками на них, так что можно пополнить коллекцию букмарков прямо там.. Хотя я откровенно не понимаю сервисы которые так делают. Нашел прикольную Фотку через него.

Раздел Абстрактный поиск… вот и мне страшно.

dreamstime

На сколько я понял идея такая – мы вам показываем картинку, хотите ее с хорошим разрешением, то придется доплатить. На этом и зарабатываем. Ну так… и по сайту ж видно, что зарабатывает!!!
Фрии у них тоже есть, но регатся надо, я регнусь, обязательно регнусь, но потом, блин за окном уже 11 так что перейдем к фликру.
Регнулся, блин… раздел фрии у них глюкавый… и правда.. ну зачем следить за той частью, которая фрии

Flickr и его Тур

Не знаю, по-моему тут и рассказывать не надо Огромная коллекция фоток, возможность составлять свой собственный фотоальбом.

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

Wikimedia Commons

Попытка использовать виковский движок для фотоальбома. Знаете что из этого получилось? Отличная идея располагать на странице по 200 фоток сразу, т.е. куда бы вы не зашли сразу будьте любезны отслюнявить полторушку метра на нужды развивающегося проекта, а если вдруг вам захотелось заглянуть в раздел анимации, то уж будьте любезны расстаться с 30тью метрами.

PD Photo

Как по мне не богатый но очень красивый каталог фоток

Gimp Savvy

Еще один каталог фоток. Когда заглядываешь в раздел Ключевых слов , понимаешь, что о модерации здесь знают лишь понаслышке.

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

PicFindr

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

Через это скрипт посылается запрос к 10 ти сайтам.

http://pdphoto.org
http://www.freedigitalphotos.net
http://gimp-savvy.com
http://www.sxc.hu
http://www.dreamstime.com (в два раздела бесплатный и платный)
http://freerangestock.com
http://www.freephotosbank.com

И к некоторым на прямую (наверно к тем, где его еще не забанили )

http://morguefile.com
http://www.imageafter.com

Ну, мож пользоваться и можно, но результате все равно не все показывает.

В общем в нете этого добра хватает, да и к тому же уже сейчас почти каждый поисковик оснащен поиском по фотографиям.

Дальше хочу еще продолжить обзоры некоторых типов сервисов.

Hello world!

Итак, открываю свой не первый блог, но надеюсь, что он таки будет последним.

Было у меня пару попыток открывать блоги, ничего из этого не вышло, по разным причинам, то впадлу, то времени небыло, то еще чтото, вобщем не получалось у меня ну никак (

Давненько уже наткнулся на вордпресс, очень функциональная хрень, очень понравилась. Ну вот решил попробывать, чтож выйдет то у меня.

Так, теперь надо сказать о самом блоге. Блог сам, будет о том, чем увлекается его автор, ну в конце концов, пишу то для себя, а потом уже мож и бля других, если вдруг кому понравится. А увлекаюсь я программированием, Perl, JavaScript, ActionScript. Базами Данных MySQL Postgresql . И все надеюсь когда нить написать таки свою игру.

Сейчас занимаюсь разработкой сайта www.CodeIDE.com