(#4) Тема для ваших вопросов (2015г)

[spb_borodin]

Ближайший мастер-класс #Highload в 2016 году:

- 18 июня 2016 в Москве, билеты и запись: http://devconf.ru

- 26 июня 2016 в Санкт-Петербурге, запись: php.spb.ru/ms/sign-up.html

Новые вопросы просьба отправлять сюда:
>>> http://spb-borodin.livejournal.com/2267.html <<<

Comments

[demjanich]

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

[spb_borodin]

из онлайна пока есть только жж для вопросов

[demjanich]

можете рассказать подробно, как происходит миграция sql данных на другой сервер? и какова логика хранения этих данных?

[spb_borodin]

Блокируем спот, информацию полностью о каких-то 1000 пользователей. Это 0.002% всех пользователей при 50 млн общего числа, т.е. незаметная капля в море. Ну, и переносим спокойно куда хотим.

[demjanich]

А что в это время делать этим 1000 пользователям, если они что-то обновляют в своих профайлах или добавляют что-то на ленту новостей, сохраняем в каком-то промежуточном состоянии в памяти? Каким образом?

И еще вопрос, как собирать ленту, если друзья раскинуты по разным серверам?

[spb_borodin]

Отдыхать.. им будет написано, что сайт недоступен. Вам кажется, что это проблема? Умножьте слово проблема на 0.002%. На фоне обычных багов из-за говнокода это будет незаметно.

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

[demjanich]

Я читал ранее что вы писали, что фейсбук и вконтакте выбрали сбор новостей. Я в одном небольшом проекте реализовал сбор. На простых выборках все хорошо, но когда надо собирать новости друзей друзей + отфильтрованные по типам + не показывать блокированных + те где писал комменты + другие фильтры и условия, запросы начали усложняться и в районе миллиона новостей все начало тормозить.
Но с другой стороны если автора пишет новость и у него несколько тысяч друзей и десятки тысяч друзей друзей, репликация выглядит несколько тяжеловато. Получается каждую новость надо обрабатывать кронами в фоновом режиме?

[spb_borodin]

Сожалею, готовых рецептов и ответов нет, задача сложная. Мы делали обоими способами, проекты работали.

[jon_black]

Друзья, а кому-нибудь удалось записаться на анонсированный мастер-класс?

[spb_borodin]

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

Re: Ваш мастер класс

[spb_borodin]

Видео нет, его не будет. Записать можно, 10 минут максимум. Но зато все, кому надо, могут в любое время позже без ограничений задавать вопросы по скайпу.

Фреймворки отвечают на вопрос - как писать код. Я занимаюсь темой - как хранить и оперировать данными для постороения большого проекта, на сотни серверов. Фреймворки не имеют к этому ни малейшего отношения и программировать, я надеюсь, все сами умеют .-)

Да, и по скайпу я вам тоже уже ответил.

Шардинг

[anonymous]

Обычно, в качестве параметра шардинга выбирают ID пользователя (user_id) - это позволяет делить данные по серверам равномерно и просто. Т.о. при получении личных сообщений пользователей алгоритм работы будет такой

Re: Шардинг

[spb_borodin]

> В этом случае узкое место - это большая таблица соответсвия

Как же у страха глаза велики. Не существует этой проблемы. Делаем так. Кладем табличку соответствия в файлы. Например, по 10% от таблицы на файл, всего 10 штук. Файлы просто инклюдим. Это будет кеш. В качестве альтернативы можно хранить эту информацию в локальных мемкешах или APC.

> В этом случае узкое место - это проблема добавления новых серверов -
> Вам придется делать перераспределение данных между новым количеством серверов.

Не придется. При добавлении нового сервера ничего не происходит. Вообще. Но можно:
1) Указать в карте спотов, что новых пользователей нужно завести на новом сервере.
2) Собрать 10% случайных пользователей с наиболее тормозного сервера в сети и перенести их профайлы на новый сервер. Последовательно блокируем 1000 юзеров, копируем, разблокируем. 1000 юзеров на 5 минут не будут обслуживаться. Это мелочь.

Re: Шардинг

[anonymous]

images, comments, likes т.е таких NoSQL(memcahed) таблиц соответвия получается много?
user(1:m):photos => (1:m) comments => (1:m) likes. Т.е связи один-ко-многим реализуем без JOIN-во вообще, а только с помощью NoSQL(memcached) таблиц соответствий?
Например: мы смотрим альбом(фотографии) определённого пользователя(фотографии и комменты разбросаны по разным серверам сети), photo_id(10, 100501), обращаемся к таблице соответствий key/value(NoSQL, Memcache) photos_map(photo_id, serialize(array('Servers' => array('comment1'=>array('tables_name' => array('tbl_comment1','tbl_comment20'),'m12' =>array('tables_name' => array('messages101'))). Далее по id фотографии извлекаем из карты соответствий photos_map сервера и таблицы в которых эти комменты разбросаны и извлекаем для конкретной фотки.
Т.е может быть для многих сущностей(messages, photos, comments), у нас не одна карта соответствий? Т.е я не понимаю как можно всё в одну "бедную" карту всё запихнуть...

Re: Шардинг

[spb_borodin]

Не понимаю, что вы пишите. Join по данным одного пользователя выполнять можно. Это написано 100 раз в комментах, почитайте. Вот и храните их так, чтобы можно было это делать.

Исключение: когда фоток или сообщений у одного юзера зашкаливает за 100.000 записей. Тогда надо либо ограничить, либо шардить.