Тестирование производительности join без индексов чем-то похоже на тестирование скорости болидов формулы один, с незаведенными двигателями. Самую главную фишку выключили и вперед:) Без обид, но правда, джоины в первую очередь тем и хороши, что позволяют все сшивать по индексам, а не делать тупой фуллскан. Статья несомненно представляет интерес, особенно в меру сравнения InnoDB и MyISAM, но уж очень теоретический, в меру редкости подобных вещей.
Новичкам действительно часто не советуют джоины, т.к. расставлять индексы и правильно джоинить это скилл определённого уровня. Но если новичек дорос до разговоров о производительности, то неплохо бы ему вначале научиться этому искусству. Если Вы сможете добавить индексы и прогнать те же тесты на том же конфиге, то имхо будет намного интереснее. Особенно если Вы добавите еще хотя бы одну ситуацию, когда фуллскан быстрее использования индексов, как Вы упоминали тут. Заодно это было бы полезно как линк для новичков, в плане что почитать о пользе индексов.
p.s.: Конфигов mysql не осталось? Было бы интересно глянуть.
Один из смыслов определённо в том, что набор книг един и места где закончил читать отмечены, и всё это доступно на любом устройстве. Иногда удобнее взять с собой один ипад, чем брать еще ипад и киндл, а почитать захотется может.
Если бы Вы сломали пару экранов у покетбуков, возможно Ваше мнение было бы иным:)
HDD на SSD меняют в ноутах, например, зачастую именно по причине устойчивости к ударам, а не из-за скорости.
Да и к вопросу о ноутбуках складываемых в 4 раза — концепты уже есть.
Если говорить о фрилансе и западных заказчиках, то... На php5 лично сдавался экзамен еще в 2008 году, во время фрилансерства на «загнивающий запад», по требованию заказчика. Без ZCE просто не было бы этой работы, а работа была неплохая. Последующие годы опять же проще было говорить с заказчиками, особенно учитывая что почти все проекты под NDA и показывать их нельзя. Помогало в общем. Пару раз задавались вопросы заказчикам — зачем Вам мол именно ZCE человек. Смысл сводился к тому, что грамотный программер сдаст сертификацию без проблем, поэтому отсутствие у него ZCE сертификата это сродни тому, что соискатель пришел на собеседование в грязных носках пьяным в дымину. А ZCE единственный ценный по php. Плюс это нехилый отсев на первоначальном этапе, когда заказчику в его фриланс проект пишет 256 исполнителей и ему надо как-то отобрать хотя бы 20% из них.
На постоянке и/или в россии ZCE практически не котируется, по личному опыту. Объяснение тоже достаточно простое. На собеседование на постоянку приходит допустим даже 20 человек, а не 250, и принимаются они на год-два, а не на месяц-три. Поэтому нет смысла в первоначальном отборе по ZCE. По этой же причине нет смысла в первоначальном отборе по ZCE и на русском фрилансе, русских ZCE кот наплакал по сравнению с другими странами.
p.s.: К вопросу о ценности сертификата/теста, несколько раз приходилось искать программеров в команду для работы, использовались вопросы из теста ZCE или даже просто давалась ссылка на тест с зенд сайта (тот легкий, из 10 вопросов). С одного русского фриланса сайта это помогало отсеять 90% обращавшихся. И это без собеседования, проверки тестовых заданий и прочих трат времени.
Всегда несколько настораживали фразы вида «да наш конкурент никто, его вообще пожалеть надо» (с). Почему-то возникают смутные подозрения в искренности. Или это паранойя?
Фильтрация ввода от пользователя нужна в любом случае, поэтому обработка полей вводе не является дополнительной опцией и не является минусом.
танцы с бубном вокруг случаев, когда пользователь вводит вперемешку utf8 и entities
молчу, что «Ива́ново» вы в cp1251 в базе не найдете никогда
посмотрите, как оно реализовано в ЖЖ/ya.ru — именно так, как я говорю, а значит — пользователи к этому привыкли.
Хабрапарсер, форумы на vbb/ipb с Вами не согласятся по поводу «привыкания» пользователей.
Но даже по ЖЖ, по Вашему совету было проверено
И как-то не всё так однозначно как Вы говорите:
1) В визуальном редакторе все вроде бы ок…
2) Однако уже в html виде видны «сущности» и «отдельные ударения»…
3) Как это выглядит в html коде ЖЖ — жуткая жуть…
4) Поиска родного у ЖЖ нет вроде? Но яндекс ищет «Ива́ново» как «Ива'ново», а вот сейчас на хабре знак ударения при написании коммента стоит вообще над «н», хотя в превью уже над «а»… и непонятно что будет после отправки.
Отсюда, внимание, вопрос: вы уверены, что накладные расходы себя оправдают?
Иногда оправдают, иногда нет.
Целью публикации было показать какие именно потери по производительности в БД возможны в случае выбора utf там, где достаточно cp1251, что бы каждый для своей ситуации мог бы сделать оптимальный выбор.
Часть ответов на Ваши вопросы добавлена в статью. Результаты для InnoDB в общем те же что для MyISAM. Что логично.
Для memory таблиц используется char, т.к. blob и text не поддерживаются, а varchar работает так же как char. Кроме того, следует отметить, что varchar(50) в cp1251 будет использовать 50 байт против 150 в utf8, отсюда и различие в размерах и очевидно скорости.
Для обычных таблиц использовалось изначально MyISAM/text, сейчас добавлено и innoDB/text. С индексами InnoDB не тестировалась, т.к. фултекста там нет, а в varchar эту базу индексировать бессмысленно.
Если под cp1251 заточена только база (что дает ровно те преимущества по скорости что описаны), а скрипты написаны под utf (например как описано тут в комменте), то смена кодировки на utf займет:
написание строк mysqldump/mysql — 97.4 секунды (примерно)
mysqldump экспорт в файл 8.8 сек (1251)
mysql импорт из файла 13.8 сек (utf)
Итого: 2 минуты:)
Потому, что ru_RU и en_EN в данном случае задают culture — сортировку символов, преобразование регистра, форматы чисел, валют и т.д.
Точный пример вспомнить трудно, но если по памяти/аналогии привести пример «с потолка», то очень сильно смущает, что iconv Königsberg //ignore //translit может превратиться в Konigsberg, может в Ko'nigsberg, или допустим в K«onigsberg или даже в Koonigsberg в зависимости от локализации „универсальной“ кодировки UTF.
Неплохой промежуточный вариант: приложение на utf, а база в cp1251. при set names utf затраты на перекодировку ничтожно малые (пусть даже с десяток строк запросов конвертнуть туда сюда), а производительность БД будет именно как с cp1251, что ощутимо.
Пожалуй Вы правы, но результаты были достаточно близкие, поэтому их даже не осталось:(
Однозначно колебания по результирующему столбцу были максимум в пределах 5% от значения. Т.е. если 1.13 в последнем столбце, то худший коэфф. был не ниже 1.0735, а лучший не выше 1,1865.
Что касается экономии. При условии что utf избыточен, то в коммерческом продукте однобайтовая кодировка это бесплатный способ сделать сайт чуть быстрее. А в некоммерческом, живущем на самоокупаемости и не более, это может оказаться гранью между выживанием и закрытием.
При чем экономия-то может получится не такая маленькая. Да, есть цифры типа 1.09х, но есть и 6.42х.
Убирав из статьи «панику» в сухом остатке можно оставить утверждение: «если ты пишешь в твиттере/блоге где находишься и выступаешь с заранее запланированными публичными докладами, кто-то внимательный может догадаться где ты находишься».
фильтровать запрещенное как-то некошерно.
вспомнить хотя бы знаменитый j a v a s c r i p t и аналоги.
плюс введут завтра какой-нибудь новый небезопасный тэг и что?
А в Hetzner могут не просто дать сервер в аренду, но ещё и поднять на этом сервере почтовик и проводить техподдержку?
Нет, такой услуги у хетзнера однозначно нет.
У них есть managed сервера, но этот managed выражается в том, что вместо хождения в панель и нажатия кнопки «ребут» в вебформе, Вы пишите письмо на e-mail и за Вас это делает их суппорт. На самом деле чуть больше, но не намного. Спец.софт никто ставить и настраивать не будет, даже если он весьма стандартный и даже если Вы готовы платить по часам.
Однако есть соразмерное количество фирм занимающихся администрированием, которые готовы оказывать подобную услугу на чужих серверах. И даже с учетом стороннего админства, получается вполне бюджетненько.
По поводу пинга стоит добавить. Если аудитория сайта не чисто «Москва», то из некоторых регионов пинги до Москвы зачастую длиннее чем до германии/хетзнера или украины/мхоста. Поэтому зарубежное расположение может иметь плюсы даже по этому пункту. Пути пинга неисповедимы.
Без обид, но правда, джоины в первую очередь тем и хороши, что позволяют все сшивать по индексам, а не делать тупой фуллскан. Статья несомненно представляет интерес, особенно в меру сравнения InnoDB и MyISAM, но уж очень теоретический, в меру редкости подобных вещей.
Новичкам действительно часто не советуют джоины, т.к. расставлять индексы и правильно джоинить это скилл определённого уровня. Но если новичек дорос до разговоров о производительности, то неплохо бы ему вначале научиться этому искусству.
Если Вы сможете добавить индексы и прогнать те же тесты на том же конфиге, то имхо будет намного интереснее. Особенно если Вы добавите еще хотя бы одну ситуацию, когда фуллскан быстрее использования индексов, как Вы упоминали тут. Заодно это было бы полезно как линк для новичков, в плане что почитать о пользе индексов.
p.s.: Конфигов mysql не осталось? Было бы интересно глянуть.
HDD на SSD меняют в ноутах, например, зачастую именно по причине устойчивости к ударам, а не из-за скорости.
Да и к вопросу о ноутбуках складываемых в 4 раза — концепты уже есть.
Если говорить о фрилансе и западных заказчиках, то...
На php5 лично сдавался экзамен еще в 2008 году, во время фрилансерства на «загнивающий запад», по требованию заказчика. Без ZCE просто не было бы этой работы, а работа была неплохая. Последующие годы опять же проще было говорить с заказчиками, особенно учитывая что почти все проекты под NDA и показывать их нельзя. Помогало в общем.
Пару раз задавались вопросы заказчикам — зачем Вам мол именно ZCE человек. Смысл сводился к тому, что грамотный программер сдаст сертификацию без проблем, поэтому отсутствие у него ZCE сертификата это сродни тому, что соискатель пришел на собеседование в грязных носках пьяным в дымину. А ZCE единственный ценный по php. Плюс это нехилый отсев на первоначальном этапе, когда заказчику в его фриланс проект пишет 256 исполнителей и ему надо как-то отобрать хотя бы 20% из них.
На постоянке и/или в россии ZCE практически не котируется, по личному опыту. Объяснение тоже достаточно простое. На собеседование на постоянку приходит допустим даже 20 человек, а не 250, и принимаются они на год-два, а не на месяц-три. Поэтому нет смысла в первоначальном отборе по ZCE. По этой же причине нет смысла в первоначальном отборе по ZCE и на русском фрилансе, русских ZCE кот наплакал по сравнению с другими странами.
p.s.: К вопросу о ценности сертификата/теста, несколько раз приходилось искать программеров в команду для работы, использовались вопросы из теста ZCE или даже просто давалась ссылка на тест с зенд сайта (тот легкий, из 10 вопросов). С одного русского фриланса сайта это помогало отсеять 90% обращавшихся. И это без собеседования, проверки тестовых заданий и прочих трат времени.
Хабрапарсер, форумы на vbb/ipb с Вами не согласятся по поводу «привыкания» пользователей.
Но даже по ЖЖ, по Вашему совету было проверено
И как-то не всё так однозначно как Вы говорите:
1) В визуальном редакторе все вроде бы ок…
2) Однако уже в html виде видны «сущности» и «отдельные ударения»…
3) Как это выглядит в html коде ЖЖ — жуткая жуть…
4) Поиска родного у ЖЖ нет вроде? Но яндекс ищет «Ива́ново» как «Ива'ново», а вот сейчас на хабре знак ударения при написании коммента стоит вообще над «н», хотя в превью уже над «а»… и непонятно что будет после отправки.
Иногда оправдают, иногда нет.
Целью публикации было показать какие именно потери по производительности в БД возможны в случае выбора utf там, где достаточно cp1251, что бы каждый для своей ситуации мог бы сделать оптимальный выбор.
Для memory таблиц используется char, т.к. blob и text не поддерживаются, а varchar работает так же как char. Кроме того, следует отметить, что varchar(50) в cp1251 будет использовать 50 байт против 150 в utf8, отсюда и различие в размерах и очевидно скорости.
Для обычных таблиц использовалось изначально MyISAM/text, сейчас добавлено и innoDB/text. С индексами InnoDB не тестировалась, т.к. фултекста там нет, а в varchar эту базу индексировать бессмысленно.
написание строк mysqldump/mysql — 97.4 секунды (примерно)
mysqldump экспорт в файл 8.8 сек (1251)
mysql импорт из файла 13.8 сек (utf)
Итого: 2 минуты:)
Однозначно колебания по результирующему столбцу были максимум в пределах 5% от значения. Т.е. если 1.13 в последнем столбце, то худший коэфф. был не ниже 1.0735, а лучший не выше 1,1865.
Что касается экономии. При условии что utf избыточен, то в коммерческом продукте однобайтовая кодировка это бесплатный способ сделать сайт чуть быстрее. А в некоммерческом, живущем на самоокупаемости и не более, это может оказаться гранью между выживанием и закрытием.
При чем экономия-то может получится не такая маленькая. Да, есть цифры типа 1.09х, но есть и 6.42х.
вспомнить хотя бы знаменитый j a v a s c r i p t и аналоги.
плюс введут завтра какой-нибудь новый небезопасный тэг и что?
Нет, такой услуги у хетзнера однозначно нет.
У них есть managed сервера, но этот managed выражается в том, что вместо хождения в панель и нажатия кнопки «ребут» в вебформе, Вы пишите письмо на e-mail и за Вас это делает их суппорт. На самом деле чуть больше, но не намного. Спец.софт никто ставить и настраивать не будет, даже если он весьма стандартный и даже если Вы готовы платить по часам.
Однако есть соразмерное количество фирм занимающихся администрированием, которые готовы оказывать подобную услугу на чужих серверах. И даже с учетом стороннего админства, получается вполне бюджетненько.
Сразу почему-то в голову не пришло, а длина ВПП какая нужна?