Всегда несколько настораживали фразы вида «да наш конкурент никто, его вообще пожалеть надо» (с). Почему-то возникают смутные подозрения в искренности. Или это паранойя?
Фильтрация ввода от пользователя нужна в любом случае, поэтому обработка полей вводе не является дополнительной опцией и не является минусом.
танцы с бубном вокруг случаев, когда пользователь вводит вперемешку 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 и за Вас это делает их суппорт. На самом деле чуть больше, но не намного. Спец.софт никто ставить и настраивать не будет, даже если он весьма стандартный и даже если Вы готовы платить по часам.
Однако есть соразмерное количество фирм занимающихся администрированием, которые готовы оказывать подобную услугу на чужих серверах. И даже с учетом стороннего админства, получается вполне бюджетненько.
По поводу пинга стоит добавить. Если аудитория сайта не чисто «Москва», то из некоторых регионов пинги до Москвы зачастую длиннее чем до германии/хетзнера или украины/мхоста. Поэтому зарубежное расположение может иметь плюсы даже по этому пункту. Пути пинга неисповедимы.
Желание нефтяного лобби защищать нефть несколько преувеличено, равно как и превозносимая дешевизна альтернативных источников энергии.
Нефтянникам не нефть нужна как таковая, а доход. Как только будут альтернативные источники коммерчески выгодными, нефтянники явно не последними будут кто в них вложится. Топливные ячейки надо кому-то производить, а инфраструктура вокруг производства аккумуляторов и их утилизации тоже вполне даже прибыльная штука.
Что касается цены альтернативной энергии, не всё так просто. Вы знаете какая доля налогов в том же бензине? Если убрать налоги из него, то бензин тоже станет очень недорогим, возможно даже дешевле чем вышеописываемый листик солнечной батарейки.
Если смотреть по оригиналу, то все немного лучше чем кажется:)
Nocera's device uses inexpensive materials that are widely available. It can use water from any source and is highly stable. He has shown that a prototype of his leaf in the laboratory operated continuously for at least 45 hours without a drop in activity.
Устройство использует недорогие материалы и воду из любого источника.
Прототип проработал в лабораторных условиях 45 часов подряд без снижения КПД.
По спецификациям неплохо download.intel.com/design/flash/nand/325212.pdf
Однако про 510 серию thg писал, что интел заточился на скорость последовательного чтения/записи, что бы понтануться быстрыми sata интерфейсами.
Хабрапарсер, форумы на 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 и за Вас это делает их суппорт. На самом деле чуть больше, но не намного. Спец.софт никто ставить и настраивать не будет, даже если он весьма стандартный и даже если Вы готовы платить по часам.
Однако есть соразмерное количество фирм занимающихся администрированием, которые готовы оказывать подобную услугу на чужих серверах. И даже с учетом стороннего админства, получается вполне бюджетненько.
Сразу почему-то в голову не пришло, а длина ВПП какая нужна?
Нефтянникам не нефть нужна как таковая, а доход. Как только будут альтернативные источники коммерчески выгодными, нефтянники явно не последними будут кто в них вложится. Топливные ячейки надо кому-то производить, а инфраструктура вокруг производства аккумуляторов и их утилизации тоже вполне даже прибыльная штука.
Что касается цены альтернативной энергии, не всё так просто. Вы знаете какая доля налогов в том же бензине? Если убрать налоги из него, то бензин тоже станет очень недорогим, возможно даже дешевле чем вышеописываемый листик солнечной батарейки.
Nocera's device uses inexpensive materials that are widely available. It can use water from any source and is highly stable. He has shown that a prototype of his leaf in the laboratory operated continuously for at least 45 hours without a drop in activity.
Устройство использует недорогие материалы и воду из любого источника.
Прототип проработал в лабораторных условиях 45 часов подряд без снижения КПД.
Однако про 510 серию thg писал, что интел заточился на скорость последовательного чтения/записи, что бы понтануться быстрыми sata интерфейсами.