?

Log in

Previous Entry | Next Entry

Эта тема создана для ваших вопросов, которые обязательно должны появится после мастер-класса "Разработка крупного масштабируемого web 2.0 проекта с нуля"

Comments

( 68 comments — Leave a comment )
Page 1 of 2
<<[1] [2] >>
wasting_money
Dec. 21st, 2010 12:07 pm (UTC)
Как же все-таки правильно хранить друзей?))
spb_borodin
Dec. 21st, 2010 12:12 pm (UTC)
я это часа два объяснял на мастер-классе: в таблицах по спотам
(no subject) - wasting_money - Dec. 21st, 2010 02:47 pm (UTC) - Expand
(Anonymous)
Dec. 23rd, 2010 06:55 am (UTC)
А в записи курса нет? Продавать не планируете?
(Anonymous)
Dec. 24th, 2010 10:54 am (UTC)
Шардинг
В шардинге обычно используется какой-то критерий разбиения. Наиболее распространены следующие:
1. По диапазону первичного ключа
2. При помощи хеш-функции, учитывающей кол-во шардов.
3. При помощи центрального "словаря", в котором хранятся соответствия ключей определенному шарду.

В нашем проекте первый вариант не подходит, т.к. id пользователей (id - это id пользователей Вконтакте) сильно варьируются и распределение по диапазону будет очень неравномерным.
Второй вариант обладает недостатком при добавлении нового шарда. Каким-то образом надо перераспределять данные со старых шардов.
Трейтий вариант - центральный "словарь" - это единая точка отказа + потенциально узкое место по нагрузке.

Скажите, пожалуйста, какой из этих вариантов все же предпочтительнее и как вы решаете существующие в нем проблемы?

spb_borodin
Dec. 24th, 2010 11:04 am (UTC)
Re: Шардинг
1. Не знаю, что вы имеете ввиду под первичным ключом, но это не важно. На каждого юзера (пусть у них есть логины или что-то еще) нужно завести user_id. Это последовательно увеличивающийся сиквенс.

2. Разумеется, никакие формулы ни в каком приближении недопустимы.

3. Центральный словарь нужно использовать. Он называется "Карта спотов". Стоп - это минимальный кусочек данных, из которых и состоит весь шардинг, т.е. вся база. В одном споте хранится сразу 500-10000 юзеров (например, 1000). Спотами очень удобно манипулировать, переносить, добавлять и т.д.

4. Небольшим проектам, до 10 млн юзеров, думать про единую точку и отказы категорически не нужно. Не пытайтесь заниматься преждевременной оптимизацией. Никакой нагрузки в карте спотов вообще нет. Ее мгновенно кеширует файловая система каждой тачки в сети и ни на какой центральный сервер никто не обращается. В общем, указанных вами опасений нет и думать про них не нужно.

5. Проблем в этом методе нет. Это единственный приемлемый способ из всех, что я знаю.
Re: Шардинг - (Anonymous) - Dec. 24th, 2010 11:41 am (UTC) - Expand
Re: Шардинг - spb_borodin - Dec. 24th, 2010 12:04 pm (UTC) - Expand
Re: Шардинг - (Anonymous) - Dec. 24th, 2010 12:36 pm (UTC) - Expand
Re: Шардинг - spb_borodin - Dec. 24th, 2010 01:05 pm (UTC) - Expand
Re: Шардинг - Денис Пешехонов - Jan. 13th, 2011 01:02 am (UTC) - Expand
Re: Шардинг - spb_borodin - Jan. 19th, 2011 08:51 am (UTC) - Expand
Re: Шардинг - denis_web - Apr. 9th, 2011 08:25 am (UTC) - Expand
Re: Шардинг - spb_borodin - Apr. 10th, 2011 07:23 pm (UTC) - Expand
Re: Шардинг - Денис Кухарев - Feb. 1st, 2012 10:48 am (UTC) - Expand
Re: Шардинг - spb_borodin - Feb. 1st, 2012 07:35 pm (UTC) - Expand
Re: Шардинг - Денис Кухарев - Feb. 3rd, 2012 12:24 pm (UTC) - Expand
Re: Шардинг - spb_borodin - Feb. 5th, 2012 11:41 am (UTC) - Expand
Re: Шардинг - (Anonymous) - Feb. 6th, 2012 07:23 pm (UTC) - Expand
Re: Шардинг - spb_borodin - Feb. 7th, 2012 08:34 am (UTC) - Expand
dkozhukhar
Dec. 25th, 2010 06:13 pm (UTC)
Использование фреймворков
Дмитрий, добрый вечер! Скажите, пожалуйста, есть ли смысл в использовании различных php фреймворков в высоконагруженных системах? или лучше обходиться "своими силами"? я читал Ваши статьи, но четкого ответа, для себя, не смог найти.
spb_borodin
Dec. 25th, 2010 06:38 pm (UTC)
Re: Использование фреймворков
Здесь несколько моментов. Четкого ответа у меня нет.

1. Я много написал о существенных и не существенных вопросах. Как построить модель данных, способной оперировать 10 млн пользователей без тормозов - важный вопрос. Какой выбрать фреймворк или написать с нуля - не важно. Если вы озабочены выбором фреймворка, то вы автоматически можете забыть о хайлоде и горизонтальном масштабировании, т.к. не тем заняты. Это все равно что обсуждать - какие использовать отступы в коде: 4 пробела или табуляцию.

2. Как правило, использовать готовые фреймворки, типа Зенда, нельзя. Они ужасно тормозные. Встроив их, на некотором этапе роста вы обнаружите, что тормоза банально уперлись в оверхед из-за говнокода фреймворка и будете судорожно заниматься его оптимизацией. Можно использовать все готовое, только ждет вас описанный неприятный этап. Как только вы обнаружите, что сделать легкую страницу (0.0001 с) для легкой и часто используемой операции (что-то в очередь кинуть) невозможно в принципе из-за фреймворка.

3. Еще разок напомню - любые блага, которые дает фреймворк в мелком проекте, никакого отношения к масштабированию и хайлоду не имеют.
Иван Петропольский
Dec. 27th, 2010 06:47 pm (UTC)
Презентации
Дмитрий, спасибо за мастер-класс. Выложите, пожалуйста, обещанные презентации в неукороченном виде либо разошлите участникам на почту.
(Anonymous)
Jan. 7th, 2011 11:11 pm (UTC)
Разбиение данных на много таблиц
Здравствуйте, Дмитрий!

Вы писали о том, что кроме разбиения данных по разным физическим серверам БД, вы рекомендуете разделять данные на множество таблиц в пределах одной БД(одного сервера). Я так понимаю, что это помогает легко управлять схемой БД (например, добавлять поля в таблицу, не блокируя огромные таблицы и т.д.). Расскажите, пожалуйста, как это отражается на производительности. Ведь в данном случае фактически таблица получается фрагментированной. Разные таблицы - разные файлы. Каждый файл - смена позиции головки жесткого диска, следовательно, дополнительная нагрузка при высококонкурентном доступе. Плюс еще, как я понимаю, есть тонкости открытия/закрытия таблиц базой данных. А ведь для высоконагруженного проекта очень важен быстрый доступ к данным(и быстрая запись). Из своего опыта, скажи все же, что лучше? Плюсы, минусы одного и другого?
spb_borodin
Jan. 8th, 2011 04:22 pm (UTC)
Re: Разбиение данных на много таблиц
Спасибо за вопрос по делу.

О производительности. Здесь слишком много факторов, чтобы прогнозировать, что будет лучше.

1) Когда мы разбиваем данные на споты (разные таблицы), то мы автоматически используем другой алгоритм оперирования данными. Получается совершенно другой код. Поэтому сравнить скорость доступа к одной большой таблице (метод традиционного программирования) и оптимизированные чтения небольших кусков нельзя. Не сравнимые вещи. В общем случае, когда мы применяем шардинг (и сразу кучу полезных оптимизаций, паттернов и вообще другое программирование), результаты будут выше.

2) Если у нас одна таблица то после некоторого предела, допустим 1.000.000 записей, она будет сильно тормозить на селектах и перестроении индекса. Вернее, просто ничего не будет работать. С масштабированием - будет. Сравнение не корректно :)

3) Если данных очень мало, то лучше их хранить в одной таблице. Однако, при применении шардинга, это "мало" может легко уложиться в один спот, что выдает туже одну таблицы. В таком случае никакой разницы нет - один спот, это та же одна таблица. Если данных будет на 3-4 спота (3-4 таблицы), то наверно такой случай будет чуть медленнее (с условием - не учитывать пункт 1). Но в общем случае это не существенно.

4) Да, есть физические особенности доступа к диску и файлам. Но я бы не стал думать о столь низкоуровневых особенностях. Представим, у нас в одном случае таблица на миллион записей, в другом - разбита на 100 таблиц по 10.000 записей. Нам надо вставить строку. В первом случае SQL сервер заставит винчестер прочитать гигантский индекс и если не повезет (в индексе не приготовлено пустого места на вставку) перезаписать весь этот файл. Во втором случае мы будем оперировать мелкими файлами, т.е. прочитаем/перезапишем в 100 раз меньше данных с диска.

> кроме разбиения данных по разным физическим серверам
> БД, вы рекомендуете разделять данные на множество
> таблиц в пределах одной БД(одного сервера)

Изначально, в любом проекте у нас 1 физический сервер. ГЛАВНОЕ: изначально любые компоненты (например, SQL таблицы) сразу сделать пригодными к разбиению на N частей, где N может менять произвольно в любой момент. Пока проект очень мелкий, все живет на 1 споте (одна часть). Потом добавляется 2й спот, на том же 1м физическом сервере. Когда проект чуток подрос, в нем стало M спотов, придет пора купить второй сервер. Вот тут то без правки кода/базы мы сможем:
а) перенести часть спотов с первого сервера на второй (балансировка нагрузки)
б) создать на втором сервере место для роста пользователей, т.е. новые пустые споты.

И т.д. по ходу роста мы сможем легко оперировать этими самыми спотами. Если рост будет. Не будет - мы ничего не проиграем.

> таблица получается фрагментированной

Да, те, кто не знаком с масштабированием, очень боятся всего нового. Это - не фрагментация таблицы. Масштабирование - это иной метод оперирования данными.

> Из своего опыта, скажи все же, что лучше? Плюсы, минусы одного и другого?

Дело в том, что *кардинально* других методов сделать большой проект, просто не существует. Все большие социальные проекты устроены так. Не с чем сравнивать.
(Anonymous)
Jan. 24th, 2011 03:10 pm (UTC)
привет, мда...я ожыдал НАМНОГО БОЛЬШЕ фоток прочитав описани)))хотя и этого хватит)
(Anonymous)
Feb. 6th, 2011 03:37 pm (UTC)
Как подключаться к множестув серверов mysql и разбивать
Спасибо за информацию. У меня шок.

1. Скажите пожалуйста как правильно подключаться к mysql серверам, если данные находятся например на 10 серверах?
2. Как правильно делить табличку если она зависит от user_id и article_id?

Владимир
spb_borodin
Feb. 6th, 2011 07:35 pm (UTC)
Re: Как подключаться к множестув серверов mysql и разбиват
1. Вы не должны хотеть подключиться к 10 серверам. Все чуток сложнее, чем просто равномерно распределить инфу по N серверам. Я уже раз 100 в блоге написал. Масштабирование - это иной подход к оперированию данными, не нужно примерять к нему опыт традиционного программирования и мыслить старыми шаблонами.

2. Что такое article_id? Ну, допустим, номер фотки или заметки. Тогда просто так и храните в таблице - две этих колонки и еще несколько (какие они известно только вам).
shakirov_rus
Mar. 12th, 2011 11:20 am (UTC)
я не самый опытный программист. прочитал ваши статьи, пытался понять. скажите, в итоге, что бы написать устойчивое высоконагруженное приложение самое главное это структура БД?
spb_borodin
Mar. 12th, 2011 11:37 am (UTC)
Вы и я под структурой БД имеем ввиду совершенно разные вещи. Поэтому, для вас - ответ НЕТ. Какие столбцы и индексы вы в табличке MySQL создадите - никакой роли не играет. Поэтому я часто повторяю - Explain вам не понадобится, проблемы по оптимизации лежат в другой плоскости.

Но вообще - да, все дело только в том, как писать и читать в разные БД информацию (паттерны оперирования данными). Программисты нашей компании, при плотной ежедневной работе в команде уже опытных программистов, осваивают это за 3-4 месяца. На мастер-классе я пытаюсь это запихнуть в короткие 8 часов, дав наиболее лучшие задачи, освоив которые, слушатели сами далее по аналогии смогут решать свои задачи.

Поэтому самое главное в том, чтобы научится по иному решать задачи. Физическое хранение данных важно, но не слишком. NoSQL подход легко реализуется в самом MySQL, если программист находит это выгодным в некотором компоненте проекта.
(no subject) - shakirov_rus - Mar. 12th, 2011 02:06 pm (UTC) - Expand
(Anonymous)
Mar. 15th, 2011 03:15 pm (UTC)
как насчет тегов?
тип проекта - видео хостинг
каждое видео может иметь множество тегов
Как предложите это реализовать? Или ответы только на мастер-классе? :)
spb_borodin
Mar. 15th, 2011 05:17 pm (UTC)
Re: как насчет тегов?
Вопросы такого уровня, "как что-то сделать", а не "вот я месяц решал задачу так и так, перерыл весь инет и накоц возник вопрос" - это в какой-нибудь форум.
shakirov_rus
Mar. 17th, 2011 06:09 am (UTC)
Эх, похоже не хотите обучающее видео делать.. Жалко, очень жалко(( Хотя понятно, что у все свои проблемы и на все времени не хватает.. Приезжайте в Казань, вам здесь будут рады.
bagryan
Mar. 22nd, 2011 05:31 am (UTC)
сессии
Дмитрий, вчера был на мастер-классе, очень понравилось, спасибо!

Вопрос:
Возможно я пропустил. Где вы храните сессии пользователей? Как вы их шарите между аппликэйшенами? Интересует как сам подход, так и конкретные инструменты.
spb_borodin
Mar. 22nd, 2011 12:24 pm (UTC)
Re: сессии
уже отвечал
https://profiles.google.com/alexey.khokhryakov
Mar. 23rd, 2011 07:08 am (UTC)
Вопрос с мастер-класса про то, что на стене контакта появляются превьюшки фотографий, которые недоступны в полном размере. Дело в том, что такие превьюшки появляются на события типа "Вася был отмечен на фотографии Х" (Вася сгенерировал событие, его подписчики должны его получить, но фотография не его). Т.е. контакт видимо решил не заморачиваться излишними проверками, да и вообще, видимо, решить эту проблему можно только довольно сильно усложнив предложенную вами схему. Или есть какое-то элегантное решение этой проблемы?
(Anonymous)
Mar. 23rd, 2011 01:08 pm (UTC)
Очевидно и элементарно
Здравствуйте, Дмитрий.
Пожалуйста в ответах не пишите что это элементарно и очевидно.
Для вас очевидно. Если б это было очевидно и для человека задавшего вопрос, он бы тогда не спрашивал.

С уважением, Владимир
(Anonymous)
Apr. 8th, 2011 07:57 pm (UTC)
Den
Посетил мастер-класс в Киеве. Очень доволен. Узнал много новых особенностей про highload . Видно что Дмитрий Бородин - профессионал в хайлоаде и имеет богатый опыт в использовании множества технологий для масштабирования больших проектов. Очень рад что появилась возможность прослушать этот мастер класс. Спасибо большое что приехали в Киев!
(Anonymous)
Apr. 8th, 2011 09:33 pm (UTC)
Класс для работы с базой данных
Спасибо за мастер-класс. Что бы узнать все самому пришлось бы потратить кучу времени и в гугле такой информации не найти. Жаль, что пришлось уйти раньше, что б не опоздать на поезд.

Появился вопрос в способе реализации класса для работы с базой данных MySql.
Допустим нужно вывести профиль пользователя.
Создаем два объекта для базы. Один для получения служебной информации, что хранится на главном сервере, второй для получения данных со спота.
Всего подключаемся к 2 серверам – со служебной и социальной информацией.
Запрос к социальной информации
$db->connect($user_id);
$db->query(“SELECT name, …, age FROM users_%s WHERE users_id=$user_id”,$user_id);
Или можно лучше как-то сделать?

Безкостный Владимир
spb_borodin
Apr. 10th, 2011 07:17 pm (UTC)
Re: Класс для работы с базой данных
1. На счет служебной информации. Она должна быть доступна сверх быстро, а не просто быстро. Поэтому никаких запросов на центральный сервер быть не может.

Разместите ее в shared memory всех application/cron серверов. Но чтобы не возиться, можно воспользоваться трюком: распихайте конфиг по файлам и подключайте их инклюдом как файл-массив. При 2-м и последующих обращениях данные будут мгновенно выданы из памяти акселиратора.

2. "FROM users_%s" - так делать нельзя. Да и просто user_id поменьше оперируйте.

а) Этап фреймворка. Сразу создаем объект $WebUser - кто смотрит (текущий веб-юзер). Номер берется из сессий, если юзер авторизован.

б) Этап веб-контроллера. Он получил готовый объект $WebUser. Но теперь нужно создать того, чей профайл будем смотреть. Делаем так:
$ProfileUser=new СоздатьЮзераПоId($_GET['id']);
Метод создает юзера по его номеру (+проверка всех ошибок).
Далее оперируем только объектами.

в) Веб-контроллер захотел что-то из профайла $ProfileUser почитать.
$Data=$PforileUser->LoadProfile()
Метод реально пойдет и подгрузит данные с MySQL. Но по сути сработает код, который создат объект Профайл в классе модели данных UserProfile. Т.е. все обращения к хранилищам идут не из веб-контроллера, а из модели данных (иначе будет говнокод).

$DB=new УправлениеСоединениями($ProfileUser);
Этот класс сам возьмет из объекта user_id, посмотрит в карту спотов и определит, с каким хост:порт следует работать.

г) Модель данных Профайл имеет $DB, соединение. Теперь программист составляет запрос типа
$DB->query("
SELECT ... FROM {{ TABLE('users') }}
WHERE user_id={{ INT('user_id') }}
", array('user_id'=> ... , ...));

д) Класс работы с базой (он уже создан с $ProfileUser) возьмет шаблон запроса. Хелпер "TABLE" он заменит на нужное имя таблицы. Хелпер INT вставит приведенное к типу значение аргументов. Далее исполнит запрос и вернет результат.


korzhs
Apr. 12th, 2011 10:22 am (UTC)
Презентация
Побывал на вашем мастер-классе в Киеве 7 апреля.
Есть ли возможноть получить презентацию, которую вы там демонстрировали? Некоторые темы хочется просмотреть еще раз.
(Anonymous)
Apr. 15th, 2011 12:57 pm (UTC)
Когда и где следующие мастерклассы?
Планируете ли Вы провести мастеркласс в Новосибирске в ближайшие месяцы?
spb_borodin
Apr. 15th, 2011 01:14 pm (UTC)
Re: Когда и где следующие мастерклассы?
В любом городе, где соберется группа желающих, будет проведен мастер-класс.
Re: Когда и где следующие мастерклассы? - (Anonymous) - Apr. 17th, 2011 10:06 am (UTC) - Expand
korzhs
Apr. 18th, 2011 08:21 am (UTC)
Электронная копия доклада с мастер класса
Дмитрий, мой вопрос про возможность получить электронную копию доклада/презентации так и остался неотвеченным.
(Anonymous)
Apr. 22nd, 2011 08:43 am (UTC)
Re: Электронная копия доклада с мастер класса
Присоединяюсь к вопросу

Безкостный Владимир
(Anonymous)
Apr. 21st, 2011 12:52 pm (UTC)
Nginx-memcache
вопрос:

Есть веб сервер nginx который может кешировать ответы от бекенда в зависимости от их хедеров в определенные места.
Так вот вопрос куда будет их рациональнее ложить на жесткий диск на этом же сервере где сам nginx работает или в мемкеш который поднят на том же сервере?
есть две точки зрения: не ложить на диск из-за известной его проблемы или не ложить в мемкеш дабы не задействовать tcp/ip.
Хотелось бы услышать Вашу точку зрения, спасибо.
spb_borodin
Dec. 20th, 2012 10:42 am (UTC)
Re: Nginx-memcache
Странный вопрос. Кто сказал, что нужно кешировать данные на жесткий диск? Кто там какие-то мифические ограничения в tcp/ip, да еще локально, нашел?

1. Жесткий диск обрабатывает, условно, 100 операций в секунду. Больше выжать физически невозможно. Один memcache со старта выдаст 10 000 в секунду. Как это можно сравнивать? Другой вопрос, что в каких-то задачах имеет смысл делать большой кеш на медленный диск, чем небольшой кеш в мгновенной памяти.

2. Судя по вопросу, вы пытаетесь кешировать готовый абстрактный проект. Это зря. Кешировать данные должен php (в мемкеше), а не веб-сервер.
(Anonymous)
Apr. 21st, 2011 01:58 pm (UTC)
Автоинкрементные поля в MySQL
Добрый день! Вы говорили, что нельзя использовать автоинкрементные поля из-за проблем с репликацией. А как надо поступать?
С уважением, Игорь.
Unison Technologies Co. Ltd
(Anonymous)
May. 25th, 2011 08:18 pm (UTC)
Когда следующая конференция
ООочень интересен сабж =)) Оставил заявку на http://sonetica.ru/highload.html, но информации мало, когда и где... (Заявку оставил под именем Александр Афонин)
Денис Кухарев
Jan. 30th, 2012 06:35 am (UTC)
Добрый день, Дмитрий. Ознакомился с Вашими вводными статьями в ЖЖ по теме масштабирования. Есть желание посетить семинар. Будет ли что-то в ближайшее время в Питере, Москве?
После прочитанного есть насущный вопрос, который нужно решить оперативно: почему просто не взять Mongo? Тут вам и шардинг, и перетекаемая нагрузка, и легкость масштабирования с произвольной избыточностью в каждом подкластере... Где у нее проблемы начинаются в применении к тем нагрузкам о которых Вы говорите? Большого опыта работы с ней нет. Есть достаточно большой опыт с MySQL. Но: близится проект, которому понадобятся возможности о которых Вы пишете и нужно решать: "городить" свое вокруг MySQL или взять готовую Mongo?
spb_borodin
Jan. 30th, 2012 08:56 am (UTC)
1. никаких готовых систем масштабирования не существует, иначе бы не были нужны программисты-артихетекторы
2. монго - сам по себе очень хреновый продукт (как и все nosql базы, чем сложнее - тем хуже/глючнее), полагаться на нее безумие.. Восторженные статьи в инете на этот счет - бред. Полагаться на более примитивный и не лишенный кривизны redis/memcache можно в силу изученности проблем.
3. любые готовые системы масштабирования имеют свой предел, у nosql он хуже, у sql лучше
4. их масштабирование - это неуправляемый черный ящик
5. а вообще, оно в принципе не нужно, легко сделать самому
6. вам нужно горизонтальное масштабирование, а оно не делается за счет РЕПЛИКАЦИИ, это очень серьезное теоретическое заблуждение (если грубо: репликация - это синоним вертикального расширения, которое хоть и мощное, но ограниченно неким пределом)
7. nosql подход не означает выкинуть sql. Совсем нет. Можно и нужно использовать MySQL/PgSQL, только по другому. Конечно, совместно с key-value хранилищами.
8. использование масштабирования из коробки полезно, если известно, что проект никогда не вырастет далее 3-4х серверов... хотя ничто не мешает потратить те же ресурсы программиста на внедрение более правильной схемы (все равно велосипед писать придется, так лучше более правильный использовать)
(Anonymous)
Aug. 7th, 2012 02:07 pm (UTC)
Авторайзер
Здравствуйте, Дмитрий!

В вашей презентации на Highload++ для решения задачи получения данных, например, 100 друзей, упоминался так называемый "авторайзер", построенные на базе memcache/memcachedb. Не могли бы вы подробнее рассказать, про архитектуру работы с ними. Основной вопрос следующий: при получении данных мы обращаемся к нескольким авторайзерам или данные распределяются так, что мы всегда используем только 1 авторайзер, т.е. создаем одно соединение? (я так понял, что это осуществляется за счет избыточности). Если данные берутся с нескольких авторайзеров, то в чем тогда выигрыш? Нам ведь все равно надо делать создавать несколько подключений. С таким же успехом можно читать напрямую из SQL базы.

С уважением,
Сергей.
spb_borodin
Aug. 20th, 2012 09:01 am (UTC)
Re: Авторайзер
Несколько соединений, данные с нескольких инстансов.

Выигрыш, вернее проигрыш SQL в том, что он будет вечно недоступен из-за неотвечающих жестких дисков. Поэтому никакого "с таким же успехом", а только провал.
Re: Авторайзер - (Anonymous) - Aug. 20th, 2012 10:53 am (UTC) - Expand
Re: Авторайзер - spb_borodin - Aug. 20th, 2012 10:55 am (UTC) - Expand
Re: Авторайзер - (Anonymous) - Aug. 21st, 2012 12:35 pm (UTC) - Expand
Re: Авторайзер - spb_borodin - Aug. 22nd, 2012 10:50 am (UTC) - Expand
cancelliere
Oct. 30th, 2012 08:30 pm (UTC)
мастер-класс
Дмитрий, приветствую.
Нигде не смог найти информацию о том, проводите ли вы сейчас мастер-классы? И есть ли какие-то планы на этот счет?
Интересует Санкт-Петербург.
Page 1 of 2
<<[1] [2] >>
( 68 comments — Leave a comment )

Profile

spb_borodin
Дмитрий Бородин
Website

Latest Month

June 2016
S M T W T F S
   1234
567891011
12131415161718
19202122232425
2627282930  
Powered by LiveJournal.com
Designed by Lilia Ahner