Библиотека сайта rus-linux.net
MediaWiki
Глава 12 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: MediaWiki
Автор: Sumana Harihareswara, Guillaume Paumier
Перевод: А.Панин
12.3. База данных и хранилище текста
Приложение MediaWiki использует реляционную базу данных с момента создания программного обеспечения с названием "Фаза II". Стандартной (и поддерживаемой лучшим образом) системой управления базами данных (database management system - DBMS) для MediaWiki является система MySQL, используемая всеми сайтами организации Wikimedia, но другие системы управления базами данных (такие, как PostgreSQL, Oracle и SQLite) поддерживаются силами сообщества. Системный администратор может выбрать систему управления базами данных в процессе установки приложения MediaWiki, при этом MediaWiki предоставляет и абстракцию для базы данных, и абстракцию уровня запросов, которая упрощает доступ к базе данных для разработчиков.
Рисунок 12.1: Схема базы данных
В данный момент база данных содержит множество таблиц. Многие таблицы относятся к функциям хранения содержимого wiki (т.е., таблицы page, revision, category и recentchanges). Другие таблицы содержат данные пользователей (таблицы user, user_groups), мультимедийных файлов (image, filearchive), кэширования (objectcache, l10n_cache, querycache) и инструментов для внутренних операций (таблица job для хранения очередей задач), а также другие данные, как показано на Рисунке 12.2. (Доступна документация с полным описанием структуры базы данных MediaWiki.) Индексы и итоговые таблицы интенсивно используются MediaWiki, так как SQL-запросы, затрагивающие большие количества строк, могут оказаться чрезвычайно ресурсоемкими, особенно в случае сайтов организации Wikimedia. Запросы без индексов обычно отклоняются.
В течение многих лет было проведено большое количество изменений схемы базы данных, при этом наиболее важным было разделение хранилища текстовых данных и данных изменений в MediaWiki версии 1.5.
Рисунок 12.2. Основные таблицы данных в MediaWiki версий 1.4 и 1.5
В модели базы данных версии 1.4 содержимое страниц хранилось в двух важных таблицах: cur (содержащей текст и метаданные последней ревизии страницы) и old (содержащей данные предыдущих ревизий); удаленные страницы хранились в таблице archive. Когда выполнялось редактирование, действующая ревизия копировалась в таблицу old, а новая ревизия сохранялась в таблицу cur. При переименовании страницы заголовок страницы обновлялся в метаданных всех устаревших ревизий из таблицы old, что было достаточно длительной операцией. При удалении страницы все ее элементы из таблиц cur и old должны были копироваться в таблицу archive перед самим удалением; эта операция подразумевала перемещение текстовых данных всех ревизий, которые могли иметь большой объем и, таким образом, выполнение операции могло занимать большой промежуток времени.
В модели базы данных версии 1.5 метаданные и текст ревизий были разделены: таблицы cur и old были заменены на таблицы page (для хранения метаданных страниц), revision (для хранения метаданных всех ревизий, устаревших или действующих) и text (для хранения текстовых данных всех ревизий, устаревших и действующих или удаленных). Теперь в случае редактирования метаданные ревизии не должны копироваться между таблицами: вполне достаточно вставки нового элемента и обновления указателя page_latest. Также, метаданные ревизии больше не включают в себя заголовка страницы, а содержат только ее идентификатор: это обстоятельство исключает необходимость переименования всех ревизий при переименовании страницы.
Таблица revision содержит метаданные для каждой ревизии, но не текст ревизий; наоборот, в составе метаданных содержится идентификатор текста, указывающий на элемент таблицы text, содержащий соответствующие текстовые данные. При удалении страницы текст всех ревизий страницы остается на том же месте и его перемещения в другую таблицу попросту не требуется. Таблица text содержит соответствующие идентификаторам текстовые данные; поле flags указывает на то, сжаты ли текстовые данные с помощью gzip (для экономии дискового пространства) или на то, являются ли данные простым указателем на внешнее хранилище текстовых данных. Сайты организации Wikimedia используют кластер для формирования внешнего хранилища данных на основе системы MySQL и хранения в нем данных множества ревизий. Первая ревизия текстовых данных хранится в полном объеме, а следующие ревизии той же страницы хранятся в форме списка различий новой и предыдущей ревизии; впоследствии данные сжимаются с помощью gzip. Так как ревизии группируются в соответствии со страницами, они схожи, поэтому списки различий относительно малы и сжатие с помощью gzip отлично работает. Степень сжатия, которая достигается при работе с сайтами организации Wikimedia, составляет около 98%.
На стороне аппаратного обеспечения приложение MediaWiki применяет встроенную систему балансировки нагрузки, добавленную в состав приложения в 2004 году во время выпуска MediaWiki версии 1.2 (когда проект Wikipedia получил в свое распоряжение второй сервер - значительное приобретение в то время). Балансировщик нагрузки (код PHP в составе приложения MediaWiki, который решает, с каким сервером соединиться) на данный момент является критической частью инфраструктуры организации Wikimedia, которая оказывает влияние на некоторые решения, реализованные в форме алгоритмов из кода. Системный администратор может установить в файле конфигурации приложения MediaWiki один ведущий сервер и любое количество ведомых серверов баз данных; значение приоритета может быть установлено для каждого из серверов. Балансировщик нагрузки будет переадресовывать все операции записи ведущему серверу и балансировать операции чтения в зависимости от приоритетов серверов. Он также следит за задержкой при копировании данных каждым из ведомых серверов. Если задержка при записи ведомым сервером превышает 30 секунд, он не будет получать каких-либо очередей чтения, что позволит завершить выполнение операции; если все ведомые серверы испытывают задержки более 30 секунд, приложение MediaWiki автоматически переведет себя в режим работы с выполнением исключительно операций чтения данных.
Система "хронологической защиты" приложения MediaWiki позволяет быть уверенным в том, что задержка при копировании данных никогда не приведет к тому, что пользователю будет показана страница с информацией, при ознакомлении с которой можно будет сделать вывод о том, что недавно выполненная операция еще не завершилась: например, если пользователь переименовывает страницу, другой пользователь может все еще видеть ее старое название, но тот, кто ее переименовал всегда будет видеть новое имя, так как он является тем, кто ее переименовал. Это поведение реализуется путем сохранения данных о ведущем сервере в рамках пользовательской сессии в том случае, если выполненный запрос привел к отправке запроса записи к базе данных. В следующий раз, когда пользователь осуществит запрос чтения, балансировщик нагрузки получит данные о расположении сервера из данных сессии и попытается выбрать ведомый сервер, на который были скопированы данные, после чего выполнить запрос. Если сервер не доступен, система будет ожидать ввода сервера в эксплуатацию. Другим пользователям может казаться, что действие еще не выполнено, но хронология остается последовательной для каждого из пользователей.
Далее: Запросы, кэширование и доставка данных