Лыжная трасса рядом с отелем.

Как в Швейцарии прямо. :-)

Переход между корпусами санатория. Рядом с главным входом.

Вид из окна номера со второго этажа.

Лыжная трасса рядом с отелем.

Самый большой в стране театр на центральной площади Новосибирска.

Архитектура

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

Единая лента и фотоальбом

Первое и самое заметное, что добавилось к новому сайту - фотоальбом. Кроме того, фотографии и статьи блога теперь объединены в одну общую ленту, видимую прямо с главной страницы. Это даёт возможность значительно упростить адрес страницы и показывать в ленте сразу всё, не заставляя пользователя переходить по разделам сайта туда-сюда. Во время обдумывания решения этой задачи, я прошёл через несколько вариантов организации структуры базы данных. Это было и наследование таблиц с четырьмя уровнями, и их объединение, и разделение на основе правил. Но с четвёртой попытки у меня получилось решение, которое показывает единую ленту разнородных данных без объединений таблиц в виде UNION, без наследований и даже без конструкций JOIN - одним элегантным запросом.

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

Да здравствуют веб-службы

Главное отличие этой работы от всех моих предыдущих является отказ от веб-ориентированной системы администрирования. То есть, от веб-интерфейса управления сайтом. Вся система управления сайтом реализована в виде веб-служб и внешних программ-клиентов. Что это даёт? Не считая более высокого уровня безопасности, такой подход к управлению даёт удобство привычного оконного интерфейса, скорость работы и полный отрыв от веб-технологий - веб-службы могут работать с любым программным обеспечением на любой платформе. Кроме этого, такая постановка вопроса даёт ощутимую разгрузку сервера путём переноса части операций на сторону клиента. Для управления сайтом я написал две клиентских программы: локальную для обычного компьютера на языке си с использованием библиотеки GTK+ и мобильную, для платформы Андроид, которая работает на моём смартфоне.

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

Полная смена всех платформ

Не смотря на то, что я уже давно ушел с Windows и всех привязанных к ней программ, этот сайт до сих пор работал на Windows, Active Server Pages и MS SQL Server. Но руки мои дошли и до него в итоге. Теперь все компоненты сайта, программной платформы веб-приложений, веб-сервера, СУБД и операционной системы - свободные. Это даёт непревзойденную гибкость, значительно более высокую надёжность, скорость работы и скромные требования к ресурсам сервера - он тоже не резиновый.

Микроблог

Наряду со ставшим уже привычным блогом, на сайте появился микроблог. Последняя заметка микроблога показывается в специально выделенной области на всех страницах сайта, а остальные заметки (по сути архив) на отдельной странице. Интересная особенность - программа управления сайтом, запущенная со специальным ключиком не показывает главное окно, а сразу запускает окно создания новой заметки микроблога. А прикрученная к глобальным горячим клавишам среды GNOME, программа с этим ключиком упрощает создание новой заметки до одного нажатия клавиатурной комбинации.

Полнотекстовый поиск

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

Система антиспама в комментариях

В результате многолетнего слежения за спамом, который оставляют в комментариях к статьям сайта, я выработал ряд простых и эффективных правил для борьбы с ним. На основе них я написал спам-фильтр, который успешно применяю на текущем сайте с эффективностью более 98%.

Большое количество RSS-лент

Теперь на сайте работает шесть основных RSS-лент, плюс по одной на каждую метку, плюс по одной для комментариев на каждую статью или фотографию.

Мобильная версия сайта

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

Для истории

Ну и вид старого сайта, дизайн которого был любезно создан Борисом Хершбергом около шести лет тому назад:

Во-первых, разделы. Они подобны книжным полкам, на которых стоят книги разных жанров. Вполне логичная система классификации, когда содержание документов можно чётко классифицировать. Например, электронная библиотека, где книги хорошо делятся на жанры или новостной сайт, где можно явно разделить новости на финансовые, спортивные, научные или какие-нибудь ещё. Эта система классификации имеет отображение и в реальном мире, откуда, собственно, и произошла. Облегчает поиск документов.

Во-вторых, привязки к датам. Неплохо подходит к периодическим изданиям или новостям. Другими словами, к документам, где эти даты важны. Пример - прогноз погоды. Кому интересен прогноз погоды на вчера? Разве что специалистам в соответствующих областях науки, но никак не простым обывателям. Тоже имеет отражение в реальном мире, хотя и не такой важности. Поиск документов облегчает плохо, если только ищущий не знает заранее даты.

В-третьих, метки. Или теги, как их ещё называют. Как порождение виртуального мира является самой гибкой системой классификации поскольку допускает привязку к одному документу нескольких меток одновременно. Отражение в реальном мире чисто теоретически возможно, но автору неизвестно. Поиск документов облегчает чрезвычайно. Лучше меток облегчают поиск, наверное, только непосредственный поиск по сайту.

Применение

Оценим же нужность этих систем на примере блога.

Даты нужны. Хотя бы для того, чтобы можно было определить возраст документа. Но выставлять эти даты напоказ с приоритетом, а ещё и делать что-то вроде архива, на них основанного, на мой взгляд, излишне. Во всяком случае, я бы никогда не стал искать статью по дате, особенно если в блоге их много.

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

Метки дают и гибкость, и удобство поиска, и наглядность. Поэтому метки нужны и полезны.

Итоги

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

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

• Изменение архитектуры программного кода веб-приложения
• Оптимизация структуры базы данных
• Исключение программного кода как такового, где это возможно.

Первое, что мы должны сделать — это уменьшить количество ненужных обработок данных, особенно повторяющихся.

Отказ от динамического форматирования текста

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

Выделение афиши в отдельное поле

Страницы сайта, отображающие списки статей, кроме заголовка, обычно показывают и небольшой фрагмент текста каждой статьи. Если текст хранится одним куском, то во время чтения текста из базы данных из него выкусывается фрагмент и только потом показывается. Делается это с помощью какого-нибудь программного когда, при чём, многократно по количеству статей на странице. Такое выкусывание является расточительной и бессмысленно повторяющейся операцией. Исключить это безобразие можно если хранить уже выкусанный предварительно форматированный фрагмент (афишу) отдельно и считывать целиком.

Одна страница — один запрос

Поскольку самое узкое место веб-приложения в большинстве случаев — обработка запросов к базе данных, необходимо уменьшить количество запросов. В идеале до одного запроса на страницу. Каким образом? Кешированием и некоторой перестройкой базы данных.

Кеширование редко изменяемых данных

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

Отказ от сложных запросов

Очевидно, что для ускорения обработки запросов к базе данных необходимо отказаться от сложных запросов, например, от конструкций типа UNION и JOIN. Как это сделать? Например, список статей блога на этом сайте показывает так же и список меток для каждой статьи. А ведь в базе данных для этого задействованы три таблицы: одна для хранения меток, другая для хранения собственно статей и третья для связи предыдущих двух. Запрос, отображающий список статей со списком меток для каждой получается неприлично запутанным и ресурсоёмким для простого чтения списка. Как же этого избежать?

Кеширование сложных связей в базе данных

Для разрешения создавшейся ситуации мы добавляем в таблицу, хранящую статьи, поле, содержащее в себе массив из пользовательского типа, хранящего имя метки и её идентификатор. Таким образом, наш заумный запрос с несколькими JOIN-ами превращается в простой SELECT к одной таблице, хранящей непосредственно статьи. А заполнением этого поля пусть займутся триггеры, срабатывающие на все три типа операций изменения данных. Мы получаем простой запрос на чтение, экономящий ресурсы и более сложную обработку данных при администрировании сайта.

Перенос ресурсоёмких операций на сторону клиента

При управлении сайтом с помощью веб-служб (а этот сайт управляется именно так) или при явном разделении сайта с программой администрирования есть смысл по возможности перенести все ресурсоёмкие операции на сторону клиента, разгрузив тем самым сервер. Такими операциями могут быть, например, программная обработка фотографий или форматирование текстов.

Отказ от динамических RSS-лент

Поскольку список статей в блоге меняется только при изменении самих статей, отображение каналов RSS методом программной обработки данных из базы — совершенно бессмысленное занятие. Правильнее будет создавать статический XML-файл непосредственно после изменения статей. Это избавит сервер от очень большого количества ненужной работы, особенно, учитывая, что блоги чаще читают с помощью RSS, чем непосредственно на сайте.

Минимизация файлов стилей и отказ от SSI

Так же нужно сказать, что чем меньше количество файлов стилей на сайте, тем лучше. Не смотря на то, что они кешируются браузером, первая загрузка будет дольше да и обработка тоже. То же самое касается и включаемых на стороне сервера файлов SSI — эти действия совершенно лишние. Исполняемый файл должен быть предварительно скомпилированным и монолитным, что ускоряет его выполнение и исключает дополнительные считывания файлов на сервере. Зачем грузить сервер многократными лишними чтениями диска?

Итоги

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

Вид с колеса обозрения. Внизу слева видна группа пиндосов в белых кепках.

© Фото Елены Маркиной

© Фото Дмитрия Башмакова

© Фото Самуила Бабаясина

© Фото Сергея Демидова

© Фото Сергея Демидова

© Фото Сергея Демидова

© Фото Сергея Волкова

© Фото Натальи Ваулиной

© Фото Сергея Волкова