На хостинге должна быть возможность сборки модулей. Если нет, то не поставить никак. Это штука из разряда промышленного применения, особого смысла в ней на шаред хостинге нет.
Я понимаю, что статья про 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. Лучший способ прозрачного резервного копирования — снятие копий с клиента репликации.
Резервные копии файлов настройки можно сделать один раз самому или в случае аварии взять с аналогичных серверов.
Обратите внимание: если выполняется резеврное копирование с блокировкой базы, по вашему методу, скажем, раз в час, то в худшем случае теряется час жизни проекта, в добавок присутствуют никому ненужные замирания и ошибки, происходящие в момент блокировки.
Репликация в большинстве случаев даст вам «живую» копию, актуальность которой датирована той же секундой, когда вышел из строя основной сервер.
где Вы контролируете все SQL-запросы, и можете их подобрать так, чтобы на них реплика не глючила)
Контролировать нужно не запросы, а пути их следования. То есть нужно просто-напросто один раз понять, что к чему и построить такую систему, которая снаружи будет как один сервер и не будет накладывать никаких ограничений на типы запросов и их содерание.
Например, нужно понимать, что write-запросы уходят на конкретные сервера, так что соотвествующие статусные значения с таблиц надо получать от них же, а не с клиентов репликации (например mysql_insert_id()).
Конкретно-взятые случаи в рассмотрение не брались. Материал подаётся как универсальный подход. Ежу понятно, что делать репликацию ради таблицы в несколько килобайт вряд ли кто-то будет.
Баги есть везде, если их боятся, то можно совсем из дома не выходить. В MySQL очень много багов, не в репликации, а в целом.
Репликация в грубом приближении это когда два более-менее идентичных сервера один за другим выполняют запросы, в строгой последовательности изменяющие изначально идентичную базу. При любой ошибке на клиенте, репликация останавливается.
Ирония ситуации ещё и в том, что мы с вами читаем эту страницу с разных MySQL-серверов, связанных репликацией.
Было бы круто, если проект на заполонялся псевдо-научными изысканиями, в той мере, в которой это происходит. Тихий ужас, который на фоне изобилия толковой справочной информации, давно и доступно опубликованной в сети, выглядит ужасающе.
Если у вас не получается обуздать репликацию и восстановить данные из текстового дампа, разве это повод обращать других людей в вашу веру?
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. Лучший способ прозрачного резервного копирования — снятие копий с клиента репликации.
Резервные копии файлов настройки можно сделать один раз самому или в случае аварии взять с аналогичных серверов.
Обратите внимание: если выполняется резеврное копирование с блокировкой базы, по вашему методу, скажем, раз в час, то в худшем случае теряется час жизни проекта, в добавок присутствуют никому ненужные замирания и ошибки, происходящие в момент блокировки.
Репликация в большинстве случаев даст вам «живую» копию, актуальность которой датирована той же секундой, когда вышел из строя основной сервер.
Контролировать нужно не запросы, а пути их следования. То есть нужно просто-напросто один раз понять, что к чему и построить такую систему, которая снаружи будет как один сервер и не будет накладывать никаких ограничений на типы запросов и их содерание.
Например, нужно понимать, что write-запросы уходят на конкретные сервера, так что соотвествующие статусные значения с таблиц надо получать от них же, а не с клиентов репликации (например mysql_insert_id()).
Баги есть везде, если их боятся, то можно совсем из дома не выходить. В MySQL очень много багов, не в репликации, а в целом.
Репликация в грубом приближении это когда два более-менее идентичных сервера один за другим выполняют запросы, в строгой последовательности изменяющие изначально идентичную базу. При любой ошибке на клиенте, репликация останавливается.
Ирония ситуации ещё и в том, что мы с вами читаем эту страницу с разных MySQL-серверов, связанных репликацией.
Если у вас не получается обуздать репликацию и восстановить данные из текстового дампа, разве это повод обращать других людей в вашу веру?