?

Log in

No account? Create an account

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 . Видно что Дмитрий Бородин - профессионал в хайлоаде и имеет богатый опыт в использовании множества технологий для масштабирования больших проектов. Очень рад что появилась возможность прослушать этот мастер класс. Спасибо большое что приехали в Киев!
Page 1 of 2
<<[1] [2] >>
( 68 comments — Leave a comment )