Архитектурата на 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 секунди. Това намаля проблемите свързани с разделянето на данните.

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

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