Wikimedia является платформой для Wikipedia, Wiktionary и еще семи менее крупных wiki-проектов. Этот документ очень пригодится новичкам, пытающимся довести свои проекты до масштабов гигантских вебсайтов. Здесь можно найти множество интересных деталей и инновационных идей, которые уже успели доказать свою работоспособность на самых посещаемых сайтах всего Интернета.

Источники информации

Перевод статьи. Автор — Todd Hoff.

• Архитектура Wikimedia
• Серверы Wikimedia
• scale-out vs scale-up из блога «Oracle to MySQL»

Платформа

• Apache
• Linux
• MySQL
• PHP
• Squid
• LVS
• Lucene для поиска
• Memcached для распределенного кэширования объектов
• lighttpd для работы с изображениями

Статитстика

• 8 миллионов статей распределены по сотням языковых подпроектов (английские, голландские, ...)
• В десятке самых высоконагруженных проектов по данным Alexa
• Экспоненциальный рост: в терминах посетителей, трафика и серверов удвоение происходит каждые 4-6 месяцев
• 30000 HTTP запросов в секунду в периоды пиковой нагрузки
• 3 GBps трафик данных
• 3 датацентра: Тампа, Амстердам, Сеул
• 350 серверов, конфигурации варьируются от однопроцессорных Pentium 4 с 512 MB оперативной памяти до двухпроцессорных Xeon Quad-Core с 16 GB RAM.
• Управляется ~6 людьми
• Три кластера на трех разных континентах

Архитектура

• Географическая балансировка нагрузки, основываясь на IP клиента, перенаправляет их на ближайший кластер. Происходит статическое отображение множества IP адресов на множество стран, а затем и на множество кластеров.
• Кэширование с помощью Squid группируется по типу контента: текст для wiki отдельно от изображений и больших статических файлов.
• На данный момент функционирует 55 Squid серверов, плюс еще 20 подготавливается к запуску.
• 1000 HTTP запросов в секунду на каждый сервер, в периоды повышенной нагрузки эта цифра может достигать 2500.
• ~ 100-250 MBps на сервер.
• ~ 14000-32000 открытых соединений на каждом сервере.
• До 40 GB дискового кэша на каждом Squid сервере.
• До 4 дисков в каждом сервере (1U серверы).
• 8 GB оперативной памяти, половину использует Squid.
• PowerDNS предоставляет геораспределение.
• В основном и региональных датацентрах текстовые и медиа кластеры построены на LVS, CARP Squid, кэш Squid. В основном датацентре также находится хранилище медиа-данных.
• Для того, чтобы обеспечить предоставление только последних версий страниц, всем Squid-серверам отправляются инвалидационные запросы.
• Централизованно управляемая и синхронизированная установка программного обеспечения для сотен серверов.
• MediaWiki отлично масштабируется с несколькими процессорами, так что закупаются двухпроцессорный четырех ядерные серверы (8 ядер на сервер).
• Одно и то же оборудование выполняет как задачи внешнего хранения данных, так и кэширования Memcached.
• Memcached используется для кэширования метаданных изображений, данных парсера, различий между ревизиями, пользователей, сессий. Метаданные, такие как история ревизий, отношений статей (ссылки, категории и так далее), учетные записи пользователей хранятся в основных базах данных
• Сам текст находится во внешних хранилищах данных.
• Статические (загруженные пользователями) файлы, например изображения, хранятся отдельно на сервере изображений, а метаданные (размер, тип и так далее) кэшируются в основной базе данных и объектном кэше.
• Отдельная база данных для каждой вики (не отдельный сервер!).
• Один master и много реплицированных slave серверов.
• Операции чтения равномерно распределяются по slave серверам, операции записи направляются на master.
• Иногда master используется и для операция чтения, когда репликация на slave еще не завершена.
• Внешнее хранение данных:

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

  – Благодаря этому появляются дополнительные неиспользованные ресурсы на серверах приложений (порой 250-500 GB на сервер).

  – На данной момент используются реплицируемые кластеры из 3 MySQL серверов, но в будущем это может измениться, так как требуется более удобное управление ими.

Подводим итоги

• Сфокусируйтесь на архитектуре, а не на операциях или чем-то другом.
• Иногда кэширование обходится дороже, чем повторные вычисление или поиск данных в исходном источнике.
• Старайтесь избегать сложных алгоритмов, запросов к базе данных и тому подобного.
• Кэшируйте каждый результат, который дорого вам обошелся и является относительно локальным.
• Сфокусируйтесь на «горячих точках» в коде.
• Масштабируйтесь разделением:

  – операций чтения и записи (master/slave);

  – сложных операций и более частых и простых (группы запросов);

  – больших, популярных вики и более мелких.

• Улучшайте кэширование: временная и пространственная локализация данных, а также уменьшение набора данных на каждом сервере.
• Выполняйте компрессию текстовых данных, храните только изменения в статьях.
• Казалось бы простые вызовы библиотечных функций порой на практике могут занимать слишком много времени.
• Скорость поиска данных на диске ограничена, так что чем больше дисков — тем лучше!
• Масштабирование с использованием обычного оборудование не означает использование самых дешевых вещей, которые удастся найти. Серверы баз данных Wikipedia сегодня представляют собой 16GB RAM, двух- или четырех-ядерные серверы с 6 15000 rpm SCSI дисками, организованными в RAID 0. Возможно они бы и использовали более дешевые системы, но 16 GB как раз хватает для размещения основного объема данных, а остальное берут на себя жесткие диски, это вполне соответствует потребностям системы, которую они построили. Примерно по таким же причинам их веб-сервера имеют 8 ядер, так как это позволяет достичь неплохой производительности PHP при достаточно простой организации балансировки нагрузки.
• Для масштабирования требуется выполнение массы работы, но если заранее этого не предусмотреть — понадобится сделать еще больше. MediaWiki изначально была написана для одного master сервера баз данных. Затем добавилась поддержка slave. Затем добавилось распределение по языкам и проектам. Дизайн системы с тех пор прекрасно выдерживает все нагрузки, но без очистки от новых узких мест системы не обошлось.
• Каждый, кто хочет разработать свою базу данных таким образом, чтобы она позволила недорого масштабироваться с уровня одного сервера до уровня десятки лучших сайтов Интернета, должен начать с обработки слегка устаревших данных на реплицированных slave серверах, при этом не забывать балансировать нагрузку операций чтения между slave серверами. Если это возможно — блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще «маленькие». Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.

.

Добавить в социальные закладки

• Blink
• del.ici.ous
• Digg
• Furl
• Google
• Simpy
• Spurl
• Y! MyWeb
• БобрДобр
• Мистер Вонг
• Яндекс.Закладки
• Текст 2.0
• News2
• AddScoop
• RuSpace
• RUmarkz
• Memori
• Закладки Google
• Писали
• СМИ 2
• Моё Место
• Сто Закладок
• Ваау!
• Technorati
• RuCity
• LinkStore
• NewsLand
• Lopas
• Закладки - I.UA
• Connotea
• Bibsonomy
• Trucking Bookmarks
• Communizm
• UCA

[quote comment="442"]>Экспонентациальный рост: ...

Какой-какой? (:[/quote]

От слова экспонента...

[quote post="59"]От слова экспонента…[/quote]

Спасибо, что такое экспонента я знаю.

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

Добрый день.

Подскажите, пжлст, что это за технология LVS?

Среди посетителей этого сайта, есть люди, которые участвовали в проектировании архитектуры, веб. проектов типа youtube?

Масштаб рунета, подходит.

Youtube, я указал, чтобы не вдаваться в подробности.

Мне интересны люди, которые имеют представление и реальный опыт проектирования, систем такого уровня.

Надо разработать архитектуру для проекта с потоковым видео и я хотел проконсультироваться у специалистов.

Вы можете посоветовать?

[quote comment="459"]Надо разработать архитектуру для проекта с потоковым видео и я хотел проконсультироваться у специалистов.

Вы можете посоветовать?[/quote]

Посоветовать что именно?

Какого-то конкретного человека или организацию на роль «специалиста» — врядли, у меня банально нет контактов моих читателей, кроме иногда почтовых адресов, а сам я хоть и обладаю приличным количеством информации в этой области, но практика у меня минимальна.

Если же есть какие-то конкретные вопросы и/или предложения мне или читателям — я дал Вам права на написание постов здесь (на условиях постмодерации с моей стороны) — можете попробовать написать, возможно Вам это поможет в развитии проекта.