Здесь тоже интересно и не всё так просто. На этот счёт есть другая книга, называется «Punished by rewards» («Наказание наградой»), переиздана под названием «Парадокс мотивации. Почему премии, оценки и похвала не работают и чем их заменить», автор — Альфи Кон.
Если совсем коротко, без отсылок к десяткам исследований, то речь вовсе не про «идею» или «благотворительность», а про научное доказательство того, что даже с коммерческой точки зрения интеллектуальная работа ради вознаграждения делается драматически менее качественно.
Автор пытается донести простую и очевидную идею: любой коллектив состоит из уникальных личностей, с характером и мышлением.
Чем больше компания, тем сложнее управляющим ей менеджерам воспринимать сотрудников, как личностей. Когда большая компания начинает заваливаться на бок, она часто приглашает консультантов, просит их предложить стандартную методологию, универсальный набор действий, который всё поправит. В результате применения предлагаемых систем люди превращаются в функцию, набор состояний.
На хостинге должна быть возможность сборки модулей. Если нет, то не поставить никак. Это штука из разряда промышленного применения, особого смысла в ней на шаред хостинге нет.
Я понимаю, что статья про memcached. Я, конечно, извиняюсь, что сбиваю тему, но я просто не удержался и прокомментировал цитату про вероятную невозможность иных решений.
Мне бы не понравилось если бы задача по выводу списка людей «онлайн», решалась так: «Аналитическое исследование показало, что реализация данной задачи приведёт к „паразитной“ нагрузке, исчисляемой 100 запросами каждую секунду, поэтому было принято решение отказаться от вывода списка, а выводить и вычислять только количество». Другое дело, если бы ответ был бы таким: «Вывод списка посетителей „онлайн“ потребует дополнительных вычислительных мощностей». Я могу представить, что такое может случиться, может быть, в случае проекта на 1 000 000 пользователей и 10 000 000 обращений в сутки, 5000 в пике (ткнул пальцем в небо).
На моей практике такого не было, скажем, даже при общей нагрузке в ~500 запросов в секунду к базе (пиковое значение) если говорить конкретно про этот способ. MySQL в умелых руках, всё же, не так плох, как его представляют.
Существует еще один вид счетчиков, который без memcached или подобного ему решения вряд ли может быть реализован
MySQL heap table + raplace. Выбор по неравенству с использованием ключа по времени. Очистка мусора, аналогичная той, которую php по-умолчанию использует для очистки старых сессий. Будет нормально работать при довольно существенной нагрузке. Счётчик числа посетителей «online» без списка самих посетителей редко когда нужен.
Мне кажется, лучше преподносить материал как один из возможных способов, а не как истину в последней инстанции.
Это отлично, что для вас она не тяжёлая, для меня, честно скажу, очень тяжёлая.
Я так на пальцаъ не могу предельно точно представить чего будет стоить периодический обсчёт примерно в 50 000 х 5 000 = 250000000 страниц (и это без учёта всех лент, просто общее количество постов, пользователей, по 10 на страницу, грубое приближение) итераций и последующее хранение результата, грубо могу сказать, что обойдётся он очень дорого, на фоне того, что есть, это будет самой дорогой вычислительной операцией, обеспечивать которую будет самый огромный набор данных (если взять среднюю длину ряда из похожей таблицы с похожим распределением, то это примерно 160 гигабайт данных без индексов против размера всей базы около гигабайта).
Можно, конечно, сказать, что не все пользователи активные, что надо считать не для всех, но веселья от этого, уверяю, будет не меньше.
Давайте на чистоту: вы часто ходите дальше двадцатой страницы?
Ну, парить, может, и парит, но от реальности не убежать.
совершенно ненапряжно заранее индекс в базе поддерживать
Представьте условие: private_blog_id IN (0, x1, x2, x3,… xn) причем набор идентификаторов для каждого пользователя свой.
Небольшой проект на 1000 записей и 500 пользователей имеет ряд своих плюсов: можно делать что хочешь и как хочешь, но вот когда растёт набор данных и число просмотров, то тут уже приходится подстраиваться под другие правила и особого выбора в этом деле нет.
Это атавизм двухлетней давности и одна из последних вещей, который нужно сделать для оптимизации производительности базы данных. После 10-20 страниц нумерация должна переходить, например, на дни, а дни считаться, например, со времени первой публикации.
сократить время блокирования проекта для бакапа до нескольких секунд
Например, задача бакапа базы перехватывает первый этап, чтобы заблокировать MySQL на время архивации файлов в /var/lib/mysql/
Процесс резервного копирования серьёзного проекта не должен блокировать его работоспособность ни на мгновение.
Резервное копирование данных интернет-проекта во многих случаях делится на три основные части:
— Исходный код. Изначально резервируется системой контроля версий
— Media-файлы. Хорошо резервируются с использованием rsync
— База, в нашем случае MySQL. Лучший способ прозрачного резервного копирования — снятие копий с клиента репликации.
Резервные копии файлов настройки можно сделать один раз самому или в случае аварии взять с аналогичных серверов.
Обратите внимание: если выполняется резеврное копирование с блокировкой базы, по вашему методу, скажем, раз в час, то в худшем случае теряется час жизни проекта, в добавок присутствуют никому ненужные замирания и ошибки, происходящие в момент блокировки.
Репликация в большинстве случаев даст вам «живую» копию, актуальность которой датирована той же секундой, когда вышел из строя основной сервер.
Здесь тоже интересно и не всё так просто. На этот счёт есть другая книга, называется «Punished by rewards» («Наказание наградой»), переиздана под названием «Парадокс мотивации. Почему премии, оценки и похвала не работают и чем их заменить», автор — Альфи Кон.
Если совсем коротко, без отсылок к десяткам исследований, то речь вовсе не про «идею» или «благотворительность», а про научное доказательство того, что даже с коммерческой точки зрения интеллектуальная работа ради вознаграждения делается драматически менее качественно.
Отличное сравнение. В контексте обсуждения вопрос будет звучать так: готов ли проявивший себя в работе робот-пылесос стать руководителем отдела?
Автор пытается донести простую и очевидную идею: любой коллектив состоит из уникальных личностей, с характером и мышлением.
Чем больше компания, тем сложнее управляющим ей менеджерам воспринимать сотрудников, как личностей. Когда большая компания начинает заваливаться на бок, она часто приглашает консультантов, просит их предложить стандартную методологию, универсальный набор действий, который всё поправит. В результате применения предлагаемых систем люди превращаются в функцию, набор состояний.
Делается это потому, что так проще.
www.mysqlperformanceblog.com/2007/10/29/hacking-to-make-alter-table-online-for-certain-changes/
Это — в частности. Особенно если попаду в такое место, где используют Perl.
Вообще, конечно, этому способствовал бы и фидбэк с пожеланиями. На perl-версию его практически нет.
Я понимаю, что статья про memcached. Я, конечно, извиняюсь, что сбиваю тему, но я просто не удержался и прокомментировал цитату про вероятную невозможность иных решений.
Мне бы не понравилось если бы задача по выводу списка людей «онлайн», решалась так: «Аналитическое исследование показало, что реализация данной задачи приведёт к „паразитной“ нагрузке, исчисляемой 100 запросами каждую секунду, поэтому было принято решение отказаться от вывода списка, а выводить и вычислять только количество». Другое дело, если бы ответ был бы таким: «Вывод списка посетителей „онлайн“ потребует дополнительных вычислительных мощностей». Я могу представить, что такое может случиться, может быть, в случае проекта на 1 000 000 пользователей и 10 000 000 обращений в сутки, 5000 в пике (ткнул пальцем в небо).
На моей практике такого не было, скажем, даже при общей нагрузке в ~500 запросов в секунду к базе (пиковое значение) если говорить конкретно про этот способ. MySQL в умелых руках, всё же, не так плох, как его представляют.
А с точки зрения проекта видеть список присутствующих людей, а не только их количество скорее приятно, чем нет.
MySQL heap table + raplace. Выбор по неравенству с использованием ключа по времени. Очистка мусора, аналогичная той, которую php по-умолчанию использует для очистки старых сессий. Будет нормально работать при довольно существенной нагрузке. Счётчик числа посетителей «online» без списка самих посетителей редко когда нужен.
Мне кажется, лучше преподносить материал как один из возможных способов, а не как истину в последней инстанции.
Я так на пальцаъ не могу предельно точно представить чего будет стоить периодический обсчёт примерно в 50 000 х 5 000 = 250000000 страниц (и это без учёта всех лент, просто общее количество постов, пользователей, по 10 на страницу, грубое приближение) итераций и последующее хранение результата, грубо могу сказать, что обойдётся он очень дорого, на фоне того, что есть, это будет самой дорогой вычислительной операцией, обеспечивать которую будет самый огромный набор данных (если взять среднюю длину ряда из похожей таблицы с похожим распределением, то это примерно 160 гигабайт данных без индексов против размера всей базы около гигабайта).
Можно, конечно, сказать, что не все пользователи активные, что надо считать не для всех, но веселья от этого, уверяю, будет не меньше.
Давайте на чистоту: вы часто ходите дальше двадцатой страницы?
Представьте условие: private_blog_id IN (0, x1, x2, x3,… xn) причем набор идентификаторов для каждого пользователя свой.
Небольшой проект на 1000 записей и 500 пользователей имеет ряд своих плюсов: можно делать что хочешь и как хочешь, но вот когда растёт набор данных и число просмотров, то тут уже приходится подстраиваться под другие правила и особого выбора в этом деле нет.
Процесс резервного копирования серьёзного проекта не должен блокировать его работоспособность ни на мгновение.
Резервное копирование данных интернет-проекта во многих случаях делится на три основные части:
— Исходный код. Изначально резервируется системой контроля версий
— Media-файлы. Хорошо резервируются с использованием rsync
— База, в нашем случае MySQL. Лучший способ прозрачного резервного копирования — снятие копий с клиента репликации.
Резервные копии файлов настройки можно сделать один раз самому или в случае аварии взять с аналогичных серверов.
Обратите внимание: если выполняется резеврное копирование с блокировкой базы, по вашему методу, скажем, раз в час, то в худшем случае теряется час жизни проекта, в добавок присутствуют никому ненужные замирания и ошибки, происходящие в момент блокировки.
Репликация в большинстве случаев даст вам «живую» копию, актуальность которой датирована той же секундой, когда вышел из строя основной сервер.