Архитектурата на Mixi.jp

Mixi е бързо нарастваща японска социална мрежа. Предоставят услуги като дневник, общност, съобщения, фото албум. Имайки много общо с LiveJournal те са използвали сходен подход.

http://mixi.jp

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

mixi.jp - мащабиране с отворен код

Платформа

Linux

Apache

MySQL

Perl

Memcached

Squid

Shard

Вътрешна организация

Имат приблизително 4 милиона потребители, които нарастват с повече от 15 000 на ден.

На 35-то място в Alexa и 3-то в Япония.

Повече от 100MySQL сървъра

Добавят повече от 10 съвъра на месец

Използва non-persistent връзки.

Трафика в дневниците е 85% четене и 15 % запис.

Трафика от съобщения е 75% четене и 25% запис.

Имаха проблеми с производителността при репликация, които са решени чрез разделяне на базата от данни.

Избор между вертикално разделяне (по потребител) и хоризонтално разделяне(по тип на таблицата).

Крайното разделяне е по тип на таблицата и потребител. По този начин всички съобщения на група от потребители ще се намират в определена база от данни. За избор на базата от данни, в която да се запише нещо се използва ключ.

За кеширане използват memcached с 39 машини Х 2 ГБ памет.

Съхраняват повече от 8 ТБ изображения като всекидневно се добавят около 23 ГБ.

MySQL съхранява само метаданни за изображенията, но не и самите тях.

Изображенията се делят на често и рядко достъпвани.

Често достъпваните изображения са кеширани от Squid на няколко машини.

Рядко достъпваните изображения се намират само във файловата система. Няма полза да се кешират.

Поуки

При използването на динамично разделяне е трудно да се избират ключове и алгоритми за мястото на данните.

Не може да се използва join при разделени данни, така че за събирането на информация трябва да се отворят много връзки към различните бази от данни.

Добавянето на нови машини е трудно. Например ако алгоритъма за разделяне съхранява всички съобщения на потребители от 1 до N в хост 1. Когато този хост се претовари ще трябва да разделим потребителите на повече хостове. Това е много трудна задача.

Използването на разпределено кеширане води до редки обръщения към БД и средното време за зареждане на страница е около 0.02 секунди. Това намаля проблемите свързани с разделянето на данните.

Често трябва да се използват стратегии за определен тип съдържание. Например изображенията ще се обработват по различен начин от кратките текстове.

Социалните мрежи са времево ориентирани, така че има смисъл разделянето на данните да става освен по потребител и тип, така и по време.

Архитектурата на LiveJournal

Пленителен и детайлен разказ как LiveJournal се разви и мащабира системата си.LiveJournal беше от първите играчи в полето на безплатните блог услуги и срещна проблема с бързото добавяне на голям брой потребители. Публикациите в блоговете започнаха да стават все по-често, което доведе до много операции запис, които са трудно мащабируеми. Опитът на LiveJournal с проблеми при мащабирането може да помогне на вдъхновените разработчици на web услуги.

Източници на информация

LiveJournal


Google Video


Tokyo Video


2005 version

Платформи


Linux


MySql


Perl


Memcached


MogileFS


Apache

Вътрешна организация


• Мащабиране от 1, 2 и 4 хоста до клъстер.
  
• Дублиране при критичните точки.
  
• Използване само на MySQL репликация не върши работа.
  
• Ограничаването на входно/изходните операции обезмисля мащабирането
  
• Разпределяне на четенето и записа за по-голям паралелизъм .
  
• Не може да се мащабира чрез добавяне на подчинени сървъри.
  
• За максимална продуктивност да се използва подходът Shard. Заделянето се основава на ролите.
  
• Кеширане за подобряване на производителността . Кеширане на две нива заради разпределената RAM.
  
• Динамично натоварване с Perlbal .
  
• Разпределена файлова система за паралелизаъм MogileFS.
  
• Разпределяне на работата с TheSchwartz и Gearman за повече паралелна работа.
• Решаване на постоянните проблеми с връзката.

  Поуки

• Не се страхувайте сами да си пишете програмно обезпечение за решаване на проблемите си. LiveJournal положиха големи усилия и спомогнаха много за развитието на общността.
• Малките сайтове с по 1-2 машини могат да се развият до големи системи като следват желанията на потребителите .
• Ключът към мащабирането е паралелизмът. Премахнете тесните места в системата чрез кеширане , разпределяне на натоварването, sharding, клъстерни файлови системи и използването на повече дискови шпиндели.
• Репликацията си има цена .Не може просто да се добавят още и още подчинени дискове и да се очаква мащабиране.
• Проблемите на ниско ниво като избора кой механизъм за обработване на събития от ОС, файловата система и обръщенията към диска са от голямо значение при мащабиране.