juks juks

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

Можно не всё, можно только самое необходимое!

Перед этим неплохо засейвиться

Свежак это такое ироническое выражение для тех, кто знает

Перетаскиваете потихоньку сюда свежак из блога Пети Зайцева? :-)

www.mysqlperformanceblog.com/2007/10/29/hacking-to-make-alter-table-online-for-certain-changes/

Ты хоть иногда в скайп выходи чтоли, а то ведь вообще никакой связи

Я очень много чего собираюсь развивать.

Это — в частности. Особенно если попаду в такое место, где используют Perl.

Вообще, конечно, этому способствовал бы и фидбэк с пожеланиями. На perl-версию его практически нет.

Не стоит верить буквально всему :-)

А BSD не обязывает, как GPL исходный код публиковать?

Рад, что мы друг друга поняли

100 раз в секунду — как раз плюнуть.

Я понимаю, что статья про 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-серверов, связанных репликацией.

Было бы круто, если проект на заполонялся псевдо-научными изысканиями, в той мере, в которой это происходит. Тихий ужас, который на фоне изобилия толковой справочной информации, давно и доступно опубликованной в сети, выглядит ужасающе.

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

Лучший способ резервирования базы данных — это репликация, с которой делаются дискретные копии.

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

P.S. пишите в личку темы статей про MySQL, которые вы хотели бы прочитать.

Разрешения спросить? :-)

Не уберегли!

В нашей компании многие имеют свои проекты.

Jevix — один из плодов

А вот пример куража :-)

Я не хотел это сам говорить :-)

Бинго! Прямо в цель!

Максим, ты мажор :-)

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

Но образ человека рисуется очень чётко: безликий прямолинейный исполнитель чужих идей неизвестного содержания. Человек, у которого по лицу видно, что он программист.

В самом деле, мог бы ты дополнить свой несомненно интересный рассказ чем-то из жизни? Фотографиями, рассказами про интересных людей, с которыми соискатель был бы рад работать, чем-то, чего нет ни у кого?

Это же не набор в вооружённые силы! Решил задачку, закончил институт, есть время — иди к нам работать. А как же внутренний мир, как же кураж? Как же личные проекты? Неужели это действительно никому не нужно?

Зачем так сгущать краски? Стоит оглянуться вокруг, чтобы понять где же работают все эти люди, которых так тебе не хватает. Это элементарно.

Люди разные, бесспорно.

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

Вероятно, чаще прочего практикуется такой подход:

— Отпуск через месяц? Читай КЗоТ!
— Выходное пособие? Хочешь, чтобы тебя по статье уволили?

Свинство в общем. Правда, у меня приятеля сокращали из вымпелкома, с должности близкой к рядовой — 6 окладов исправно заплатили.

Выходное пособие, интересно, начислили?

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

Как вариант: <br class=«cut»>

Вообще я за прозрачную параноидальную безопасность. Это интересно. Надо будет заняться

Занятно.

Но если бы я был Васей, я поставил бы кейлоггер.

Никаких волнений не возникает.

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

Денис был несогласен с некоторыми решениями, которые мы приняли в рамках наших проектов, поэтому решил сделать «Своё казино», с которым он мог бы поступать как угодно, в том числе использовать публично.

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

То, что мы сидим за одним столом всем окружающим идёт только на пользу.

ur001 <ur001@futurico.ru> — старый адрес Дениса, а Open Social Networks Constructor — его личный проект

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

Лучше не используйте

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

А вот, владея интернет-технологиями, после C писать на, например, php — это как здрасти, только иногда заглядываешь в справочник.

По крайней мере мне так кажется.

Перенесли только всё самое дорогое сердцу