?

Log in

Next Entry

Это вступительное слово к проводимым мастер-классам, которые дадут вам практические сведения, как на самом деле можно построить крупный горизонтально масштабируемый проект web 2.0 с нуля (самостоятельно). Вы досконально понимаете, как устроен крупные и можете воспроизвести их аналог сами? А так же комментарии о многих важных недосказанных моментах к прошедшей конференции Highload++ в октябре 2010 года.

Сожалею, в этой короткой статье, не будет ответа, как построить крупный проект. Но зато будет написано, где и каким образом получить данные сведения, а так же, на что не надо тратить время. Вы наверняка внимательно читали сайты типа insight-it. И, конечно, понимаете - это всего лишь общие слова. Такие же, как описание НЛО сотнями очевидцев. Только вот проблема: как НЛО работает и как вам лично воспроизвести тоже самое - не написано. Я попробую исправить это.

Здесь и далее речь идет о неком абстрактом проекте (соц.сеть, приложние для соц.сети, веб-магазин, СМИ, блог, FLASH игра, каталог знаний и т.д.) с 10-100 млн пользователей. Не важно, какова роль сущностей в проекте, заменяйте по ходу чтения слово “пользователь” на “товар” или “ветка обсуждения”. Не важно, на каком языке и базе данных вы это делаете, каков тип и функционал вашего проекта.


Великие заблуждения о методах создания крупных проектов web 2.0.

Эта глава не связана с конференцией. Общие сведения. С них начинается мой мастер-класс, перед тем, как плавно перейти к сути построения архитектуры соц.сети на десятки млн. пользователей. О наболевшем в кратких тезисах.

[1] Единственное, что вам нужно сделать в вашем проекте - это честное горизонтальное масштабирование (сложно в 3-х словах объяснить истинный смысл этого термина). Не важно, что проект будет частично говнокодистым и не оптимизированным - на это нет времени из-за бешеного темпа разработки... Если вы заложите правильную масштабируемость - ваш проект выдержит бурный рост.

Наш проект испытывал внезапные скачки посещаемости за сутки на +300.000 новых уникальных посетителей в сутки (до 1.150.000). Естественно, не все было идеально, притормаживало, но работало. У нас много кривых мест, но работает все благодаря только одному - архитектуре, позволяющей на лету масштабироваться. Обычный проект никакого роста не выдержит - ляжет до тех пор, пока не схлынет волна пользователей, которые больше не вернутся. И ваш стартап - труп навеки.

[2] Highload - это заезжанное слово, которые все лепят там и тут. См. пункт 1. Чуть ли не домашнюю страничку Васи Пупкина называют хайлодом. Отучайтесь использовать слова типа “инновационный” и “нано”. Займитесь не оптимизацией php-кода, а как правильно хранить данные ради грамотного масштабирования.

[3] Очень опытный программист не в состоянии придумать масштабируемую архитектуру сам. И никогда команда программистов не сделает масштабируемый стартап. Не потому, что люди глупые. Они - “не в теме”. Это их единственная проблема. Я испытал это на себе и только по этому утверждаю это. Глупость начинается тогда, когда программист думает, будто у него стартап переживет рост (антипаттерн - “фигня, нарежу таблички, все дела”). Это одно из великих заблуждений. Никакими средствами и ухищрениями вы этого не сможете сделать в разумные сроки. У меня имеются веские доказательства этого пункта - две “невозможных задачки” (чуть позже), которые не решаются традиционным подходом в программировании.

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

Чтобы не тратить годы на велосипед - нужно воспользоваться готовыми платформами и решениями (не путайте это с неправильным вопросом “какой выбрать фрейморк”). Других путей нет.

[4] Немного печальной статистики о стартапщиках России. Я провожу в год несколько сотен собеседований с программистами и знаю, кто чем и в каких компаниях занимается. Около 50% программистов занимаются стартапами, клонами существующих соц.сетей или чем-то очень близким (антипаттерн - “я пишу соц.сеть, круче чем...”). У всех них замечательные идеи, как сделать лучше, только они являются страшной коммерческой тайной и потому подробностей не сообщается (тут можно смеяться). Я не обсуждаю очевидного, почему их творения не запустятся из-за самой идеи сделать клона, а только о чисто технических причинах. Занимались они своими проектами около 12-18 месяцев в среднем и все уволились. Ни один проект не запущен (либо не набрал и 10.000 пользователей).

Я задавал им 2-3 простых вопроса, относительно метода хранения “друзей” в их соц.сети, из которых делал вывод - их проект совершенно не масштабируемый. Ни один. Программисты об этом даже не думали. Все хранят в одной базе, в одной табличке и т.д. Это и есть ужас. Инвесторы годами платят деньги, программисты годами усердно/честно трудятся, а о самом главном не подумали - что их проект гарантированно никогда в жизни не запустится! Просто потому, что в нем нет масштабирования. Я конечно рад, что инвесторы и программисты заняты делом, просто есть совершенно банальные причины/доказательства - почему их проект заведомо мертв.

[5] Highload и архитектура крупного проекта - это особый вид решения задачи. Это вообще не программирование, в традиционном понимании. Например, забудьте, что вы эксперт по EXPLAIN. Он вам практически никогда не понадобится, т.к. в хайлоде применяются только примитивные запросы, типа SELECT по primary key. Много вещей, знанием и опытом которых вы гордитесь, как гуру программирования - не нужны! Голова - да, нужна.

Необходимо думать на этапе проектирования о важных вопросах. И не нужно - о несущественных вопросах: какой язык программирования выбрать, какую базу данных. Особо глупый вопрос - какой фреймворк выбрать, например, на PHP их десятки (доказательства - позже). Так же неважно, какую базу данных выбрать, т.к. мы будем использовать 1% ее возможностей, примитивные SELECT/UPDATE. Уважаемые авторы MySQL и PostgreSQL чуть ли не дерутся за графики мультитредовой производительности на всяких конференциях DevConf и Highload++, только забывают мелочь - в хайлоде это не интересно (т.е. не самое важное). Ну, нет у нас сложных запросов или критических нагрузок на один инстанс.

Первые шаги на правильном пути - осознать несущественность этих вопросов и спроектировать каждый из компонентов проекта горизонтально масштабируемым. Сложно объяснить, что именно делать. Зато легко показать, каким глупостям не нужно уделять внимание. Относительно выбора между MySQL и PostgreSQL: наша задача сделать так, чтобы ни на одном SQL инстансе, какой бы общей нагрузка ни была, не случился затык по производительности. Мы просто покупаем новый сервер и нагрузка сама перетекает туда. Вы достигли этого состояния? Тогда смело плюйте на графики производительности, вы - выше этого!

[6] “Разместим соц.сеть на облачном хостере” - стандартное забулуждение инвестора или программиста, желающего сэкономить на тратах за хостинг. Мелкое, но неприятное и опасное заблуждение, которое трудно аргументированно опровергнуть. Инвестору просто запудрили мозг дешевизной, а программист “не в теме”, но дает заключения (антипаттерн - “облако заменит масштабирование”). Минус - ужасающе медленные операции I/O, где-то раз в 10. Общая стоимость - не знаю, но думаю так же, минимум в 10 раз выше, по сравнению с арендой собственного железа. И нет масштабирования (в том смысле, которое нам нужно). И уж совершенно очевидно, что крупные соц.сети не живут на облаках.


О мифах относительно ВКонтакте после конференции Highload++ и круглого стола с разработчиками.

Недавно состоялась интересная конференция Highload++. Там выступали разработчики Vkontakte.ru и Facebook.com. Разумеется, за один-два часа выступления никто не передал великий секрет, как же оно устроено. Все высказали очень много интересных подробностей, но весьма поверхностно. Я попробую рассказать чуть больше, чем услышанные всеми общие слова. Мне это легко, т.к. занимаюсь тем же самым.

Прокомментирую некоторые высказывания посетителей известных ресурсов - Insight-it и Habrahabr. Большинство из них весьма типичные и от программистов, которые “не в теме”. Кстати, все ответы касаются и Facebook, никакой разницы нет.

Вопрос: Используется ли MySQL?

Ответ: Да. Это основное и главное хранилище данных. Не нужно относится к проекту, как к чему-то волшебному. Там тот же самый традиционный MySQL, с которым все мы работаем каждый день. Memcache применяется для хранения особо часто обновляемой информации, т.е. он хранит ~5% данных из основной SQL базы. За счет этого достигается скорость. Понимаю, вам не понятно, как засунуть 100 млн пользователей в MySQL (на мастер-классе расскажу). Но это так. Все одновременно и примитивно по идеи, и сложно в мелочах. В любом случае вас ждет взрыв мозга.

Точных цифр я конечно не знаю, но имеется пул MySQL серверов, где один из них хранит всю информацию о 500.000 - 1.000.000 пользователях. Таких серверов, исходя из общего числа пользователей - примерно 100-500 штук. Пользователи проявляют разную активность и серверы имеют разную мощность, поэтому споты пользователей (пачка ~1000 пользователей), могут спокойно мигрировать между серверами для достижения сбалансированной нагрузки. Возможность легкой миграции спотов - это и есть главное преимущество правильной честно горизонтально масштабируемой архитектуры проекта.

Вопрос: А там не говорилось, как они уникальные id создают?

Ответ: ID - это просто sequence (аналог поля auto_increment). Лежит он в какой-то no-sql базе, например memcache. Суть вопроса - те же опасения того, что соц.сеть очень сложно устроена. А все - элементарно, просто increment.

Вопрос: Как хранятся фото и видео на диске? Распределенные файловые системы?

Ответ: Все просто - как файл на диске обычного Linux сервера. Никаких изысков и особых распределенных сетевых файловых систем (забудьте об этом), все примитивно. При заливке фотки выбирается нужный спот и сервер (аналог шардинга профайла), php-скрипт на backend, принявший файл по upload, напрямую копирует файл на один из файловых стораджей. Естественно, используется избыточность: у данного сервера есть полный клон на другом сервере (не целиком, скорее всего - по спотам). Т.е. php-скрипт на самом деле копирует один файл сразу в 2-3 места. Но для выдачи, скорее всего, используется только один сервер (упрощает кеширование), зеркальные спорты понадобятся только, если первый сервер уничтожится физически.

Много непонятных мне споров про RAID. Совершенно не важно, используется RAID или нет. Важно то, наша система избыточного хранения данных выше всего этого. В этом смысл масштабирования - каким бы ни были скоростные характеристики дисков и их надежность, мы просто дублируем споты на разные физические устройства и заведомо обходим любые физические ограничения, которые были ранее или неожиданно возникнут в будущем.

Вопрос. Почему при удалении фотки она все равно доступна по прямому URL?

Ответ. Ох, сколько бреда пытаются додумать программисты, которые “не в теме”... Единственная причина: при удалении файла может возникнуть нарушение целостности, т.е. какая-то неизвестная страница соц.сети ссылается на этот файл, например в новостях или закладках. Если мы удалим файл, то возможно испортим какую-то свою страницу. Хранить данные о каждом файле, кто на него ссылается, и обрабатывать эти данные при удалении - очень накладно.

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

Когда я пробую этот вопрос разъяснить некоторым программистам, они с пеной у рта начинают возмущаться и доказывать: “Да что же сложного - просто удалить файл!”. Правильно, нет ничего сложного. Только нарушится целостность и наплодятся баги.

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

Цитата: “ВКонтакте использует PHP + XCache.”

Разъяснение. Разные версии PHP работают с XCache и APC по разному. Поэтому  просто будьте готовы, что со сменой PHP придется другой акселератор поставить, где багов и тормозов меньше. Ради highload не важно что ставить, только бы работало быстрее аналогов и не глючило.

Цитата: “Cервера многофункциональны и используются одновременно в нескольких ролях: Перебрасывание полуавтоматическое, Требуется перезапускать daemon'ы.”

Разъяснение. Не знаю, что хотел автор этой фразой сказать, но вот, что на самом деле происходит и о чем идет речь.

Представим, что у нас много серверов. Разобьем их на главные типы: пул MySQL, пул Backend PHP (+отдельные под Cron задачи), пул memcache, пул файловых стораджей, пул веб-балансеров (32 штуки) и т.д.

Рассмотрим особенности каждого из серверов. Memcache: занимает 70% памяти, где-то 10% CPU, 0% жесткого диска, 50% сетевого интерфейса (сеть должна быть свободной всегда для быстрого отклика). Файловый сторадж: файловый кеш 70% памяти, 0% CPU, 100% жесткого диска, скорость отклика по сети не очень важна.

Очевидна несправедливость: на сервере memcache почти полностью простаивает CPU и жесткий диск, а на файлом сторадже - CPU и сеть. Есть 2 типа сисадминов - правильные (большинство в мире) и не правильные (к ним относится ВКонтакте и я). Первый тип админов, не смотря на описанный выше очевидный простой ресурсов, стремятся разбить все сервера по типам исполняемых ими задач, потюнить ОС и т.д. Их цель - довести производительность главного назначения сервера до максимума. Второй тип админов стремится не дать простаивать ресурсам, объединяя некоторые не конфликтующие процессы на одном физическом сервере. Ну, жалко же, что на файловых стораджах куча памяти и cpu не используются! Туда столько всего полезного можно напихать, типа пассивных реплик любых других хранилищ для повышения общей производительности на отдачу контента.

Во ВКонтакте победила точка зрения второго типа, если я все правильно понял на том самом круглом столе Highload++.

Цитата: “Интерфейс доступа представляет собой расширенный протокол memcached... ключи возвращают результаты сложных запросов...”.

Разъяснение. Это не касается конечно волшебной базы. Смысл в том, что придуман универсальный интерфейс взаимодействия между PHP и  некоторой абстрактной базой данных или хранилища. PHP просто делает Memcache::get(“запрос”), соединяясь с неким сервером, а тот, поддерживая интерфейс memcache, обрабатывает запрос и выдает ответ.

В некоторых проектах так используется сверхбыстрый доступ к MySQL. Метод выбран из-за простоты и повсеместного внедрения модулей memcache во все языки.

Цитата: “Волшебная база на С”.

Разъяснение. Не понимаю, чего все прицепились к этому слову... В Контакте и Фейсбуке все хранится в MySQL. Все! Никакой волшебной базы не существует, как ее рисуют.

Существует специальное хранилище и  некая сишная софтина, которая создана только для скоростного анкетного поиска. Пожалуйста, не путайте понятия “как хранить и показать профайл” с “как найти среди 100 млн человек ID нужных профайлов по нужным полям”.

Все знают, что такое Sphinx. Волшебная база - это некий аналогичный программный продукт, хранилище данных, заточенное под анкетный поиск. Удивительно, какие фантазии раздуваются и слон из мухи растет просто на глазах...

Кто не помнит, примерно 1,5 года назад анкетный поиск ВКонтакте зверски тормозил - выдавал ответ через 20-30 секунд ожидания. Потом тормоза резко пропали. Результаты налицо. Жалко, что нет ни единого намека вообще ни на что об этом продукте: базовое хранилище - это реально ОЗУ компа (собственное хранилище) или все же SQL/memcache/redis? Я не успел об этом спросить.

В общем, я не знаю, но сомневаюсь, что даже для столь узкой задачи понадобилось свое хранилище данных сочинять. Скорее всего взято одно из этих трех хранилищ и оптимизирован код поиска. Далее элементарным шардингом (все данные не помешаются в ОЗУ одного сервера) и репликацией (нагрузку от поиска делим по слейвам в пуле) решаются все проблемы.

Вполне возможно, что сишная программа - это всего лишь новый вид команды к существующему memcache или redis. Я бы действовал так.

Цитата: “И что даёт эта статья? Только свой PR поднять?” (автор этой цитаты имеет ввиду статью на insight-it про Vkontakte, за что заработал “-41” голос на Хабре).

Комментатор на Хабре задал справедливый вопрос, который я обозначил в начале статьи. Общие слова о внешнем виде НЛО ни на миллиметр не приблизят вас к повторению системы. А человека, который это заметил - заминусовали. Моя цель - раскрыть все секреты и конкретные архитектуры. Откуда я это знаю? Занимаюсь тем же самым, только чуть в меньших объемах.


О недосказанном после Highload++.

А вот об интересных вопросах, которые реально важны, никто что-то и не спрашивал... Ну, кроме одного человека. Попробую добавить несколько реально серьезных тем, что удалось узнать.

О важности тюнинга memcache. (это один из ключевых вопросов моего мастер-класса)

Memcache хранит копию профайлов (некоторые переменные) в памяти, постоянно. В memcached добавили пару строк кода, чтобы ключи не удалялись со временем. В мемкеше хранится, допустим, 5% нужной информации. Все показы профайлов и записи изменений происходят через обращения к memcache, а в фоновом режиме они копируются в основную MySQL базу.

Помните, когда Контакт падал из-за проблем с электричеством, ушло 3 часа на восстановление? Хотя электроэнергии не было минут 5, наверно. Истинная причина состоит в том, что столь большое время нужно, чтобы правильно инициализировать сотни инстансов memcache копиями профайлов из MySQL. Те должны включится, починить свои диски и таблицы после падения, прочитать и отдать всю информацию по SQL запросам скриптов инициализации в memcache. Таким образом часть пользователей получает доступ к своему профайлу быстрее, часть - медленнее.

Сколько же глупостей люди написали, пытаясь объяснить эти три часа и сопоставить с тем, что дизеля то включились через пару минут... Наш проект где-то раз в 20 меньше ВКонтакте и подобное восстановление занимает около минут 15 - перезагрузка серверов, старт ОС, загрузка десятков инстансов MySQL с длительной проверкой всех таблиц, копирование в данных в no-sql хранилище, открытие доступа к проекту после визуального осмотра.

Метод подписки / функционирование новостей.

Одна из самых сложных и увлекательных функций соц.сети - это подписка (лента / новости). К сожалению, об этом никто не спрашивал.

Я знаю о 2-х кардинально разных методах подписки:
1) репликация после генерирования события на споты (инициатор - автор события) с той целью, чтобы к моменту прихода веб-пользователя все уже было накоплено и мгновенно в 1 SQL запрос отдано;
2) централизованное аккумулирование всех событий в быстрой памяти, сбор по команде веб-пользователя (инициатор - веб-пользователь, тот, кто смотрит).

На конференции же Павел Дуров заявил, что они, как и Facebook, применяют второй тип сбора новостей. Второй метод имеет существенные баги, например, не все новости всегда доступны (иногда наблюдаю). Зато первый потребляет в разы больше места на жестких дисках. Идеального ничего нет...

Да, я тут в сети видел статью в инете, как сделать ленту обновлений на MongoDB и PHP, разумеется, это не будет работать уже при 1 млн пользователей в базе, т.к. решение не масштабируемо. Но для небольшого сайта приемлемо.

Весь пул MySQL в единственном датацентре.

Архитектура ВКонтакте еще не позволяет размножится до нескольких дата-центров. Мало кто понимает, но это очень важный показатель крупнейших проектов.  Я предполагаю, что Facebook эту стадию давно прошел (точно не проверял). А у ВКонтакте этот сложный шаг еще впереди.

Правда, если они останутся в рамках СНГ, то надобности в этом не будет. Связали два дата-центра через улицу толстым каналом и решение по прежнему SQL-неделимое, но все же в 2х зданиях.

В этом пункте я имею ввиду только SQL. Файлы и прочая информация роли не играет, переносится куда угодно элементарно.


Заключение.

В Петербурге, Киеве, Москве и Новосибирске вскоре я проведу мастер-классы, где за 8 часов постараюсь обучить слушателей азам построения крупных масштабируемых проектов: http://php.spb.ru - запись уже открыта [эта статья написана в 2010г]

Так же мне было бы интересно узнать, какими узкоспециализированным вопросами по процессу разработки архитектуры интересуются читатели.

До встречи на мастер-классе
:)

В следующей статье я отвечу на все поступившие комментарии:
продолжение в посте #2 => http://spb-borodin.livejournal.com/779.html

---------------------

http://php.spb.ru - Запись на мастер-класс по #Highload на 2013 год

Comments

( 58 comments — Leave a comment )
pliskovs
Nov. 16th, 2010 07:01 pm (UTC)
Удаление фотки кроме проблем с целостностью вроде ещё поспособствует фрагментации дисков.
Насколько понимаю, очень большая роль в хайлодах у админов, либо архитектор должен быть гуру не столько в программировании сколько в знании начинки и возможностей серверов и софта???

p.s. Минус на хабре, значит что пост стоит прочитать, хомячки жёстко обходятся с инодумцами, которых не смогли понять.
spb_borodin
Nov. 16th, 2010 07:22 pm (UTC)
Если проект имеет правильное масштабирование, то его расширять может сисадмин. В этом смысл архитектуры. К этому должны стремится программисты. У нас это так. Один программист решает как и что сбалансировать или какие инстансы поднять/перенести (на основе текущих тормозов и показателей мониторинга) - дает совет сисадмину и тот сам на продакшене все делает. Часто решения по расширению принимает сисадмин, смотря CPU и прочие показатели. Программисты и близко к продакш серверам не подходят .-)

По поводу удаления файлов. Этот же паттерн действует на многие другие объекты в SQL. Намного проще пометить объект статусом "удален", чем реально удалять из базы.
(no subject) - ice_b - Nov. 17th, 2010 05:30 pm (UTC) - Expand
(no subject) - slonik_v_domene - Nov. 17th, 2010 06:42 pm (UTC) - Expand
(no subject) - ice_b - Nov. 17th, 2010 07:01 pm (UTC) - Expand
(no subject) - slonik_v_domene - Nov. 17th, 2010 07:14 pm (UTC) - Expand
(no subject) - ice_b - Nov. 17th, 2010 07:57 pm (UTC) - Expand
(no subject) - slonik_v_domene - Nov. 17th, 2010 08:09 pm (UTC) - Expand
(no subject) - ice_b - Nov. 17th, 2010 08:17 pm (UTC) - Expand
(no subject) - slonik_v_domene - Nov. 17th, 2010 09:43 pm (UTC) - Expand
(no subject) - ice_b - Nov. 17th, 2010 10:53 pm (UTC) - Expand
(no subject) - slonik_v_domene - Nov. 17th, 2010 11:02 pm (UTC) - Expand
(no subject) - ice_b - Nov. 17th, 2010 11:38 pm (UTC) - Expand
(no subject) - ice_b - Nov. 17th, 2010 08:20 pm (UTC) - Expand
aleksandro
Nov. 17th, 2010 10:59 am (UTC)
скажите тогда как хранить связи друзей в базе?
я сейчас просто храню эту информацию в одной таблице в виде userId -> friendId.
spb_borodin
Nov. 17th, 2010 11:14 am (UTC)
Всю информацию необходимо разбивать, т.е. шардить. Связи по друзъям точно так же. Это одна из важных задач, которой я научу.
(no subject) - aleksandro - Nov. 18th, 2010 08:43 am (UTC) - Expand
(no subject) - quard - Nov. 17th, 2010 11:16 am (UTC) - Expand
(no subject) - spb_borodin - Nov. 17th, 2010 11:22 am (UTC) - Expand
(no subject) - quard - Nov. 17th, 2010 11:25 am (UTC) - Expand
(no subject) - spb_borodin - Nov. 17th, 2010 11:29 am (UTC) - Expand
(no subject) - alegenk - Dec. 13th, 2010 03:43 pm (UTC) - Expand
(no subject) - spb_borodin - Dec. 14th, 2010 09:16 pm (UTC) - Expand
(Anonymous)
Nov. 17th, 2010 04:28 pm (UTC)
Отличная статья
Дмитрий,

порадовал отличной статьей... Не зря съездил на Конфу.

Не все хотят раскрывать свои секреты, а многим они просто не нужны, к сожалению.

Общался с некоторыми работодателями, объяснял основные принципы HiLoad, смотрят как на дурака... Та же ситуация и на Хабре. Минусуют, когда я сказал что в Хайлоаде нельзя использовать джоинов. :)

В той же Геометрии, которая себя позиционирует как Хайлоад, долго объяснял как организовать профайлы, чтоб возможно было сделать шардинг. Да и то мои идеи посчитали не нужными.

всем советую мастер класс Дмитрия Бородина

Аlx
alexclear
Nov. 17th, 2010 04:32 pm (UTC)
Re: Отличная статья
> Минусуют, когда я сказал что в Хайлоаде нельзя использовать джоинов. :)

Так ведь за это не минусовать надо бы, а просто пороть на конюшне.
Re: Отличная статья - spb_borodin - Nov. 17th, 2010 04:38 pm (UTC) - Expand
Re: Отличная статья - alexclear - Nov. 17th, 2010 04:45 pm (UTC) - Expand
Re: Отличная статья - slonik_v_domene - Nov. 17th, 2010 06:37 pm (UTC) - Expand
(Anonymous)
Nov. 18th, 2010 12:56 pm (UTC)
У вас смешной пост. В том смысле, что в одной и той же главе идет "они используют только MySQL" (Дуров, конечно, говорил о другом, но что он, мелкий человек, знает?!), и "я не знаю, но вряд ли".

Всю статью можно переписать проще - "я так делаю", и "я так думаю". А другие, возможно, делают и думают по другому - не надо говорить "делаем только так, а не иначе" - вы не абсолют. Другие используют Explain на миллионных нагрузках, и сложные вопросы. И не считают, что жизнь проекта зависит только от масштабируемости.

Откуда я знаю? А откуда знаете вы? Проект на миллион пользователей в день - это очень круто, но тем не менее он просто один из многих, не более того.
spb_borodin
Nov. 18th, 2010 01:05 pm (UTC)
Так напиши свой, грустный пост! Мы поплачем :)

Не надо столько категорично придираться к словам о ненужности join/explain. Конечно, оно нужно. Просто в очень мизерных масштабах, по сравнению с традиционным программированием. Первое, что нужно освоить - это выкинуть данные слова из головы, как главные инструменты. Они - крайне не существенны, но изредка применяются.

Я не знаю. Наш проект при росте с 1 ляма до 4-5 претерпит значительные изменения. Но архитектура (шардинг) останется неизменной. Появится куча проблем при росте, которые мы будем решать.

Да, наш проект один из многих и ничего особенно в нем нет. Так именно это я и хочу сказать - смотрите, как у нас все просто. Кто хочет обучится этим же примитивным способам сделать тоже самое - подходите.
(no subject) - spb_borodin - Nov. 18th, 2010 01:09 pm (UTC) - Expand
klaupaucius
Nov. 19th, 2010 01:30 pm (UTC)
А что думаете насчет MySQL Cluster? Данная технология позволяет создавать одну таблицу и она будет располагаться на нескольких серверах с помощью MySQL.
spb_borodin
Nov. 19th, 2010 01:46 pm (UTC)
К сожалению, любая технология масштабирования, которую спроектировал написал не лично программист - тупиковая, после некоторого объема информации. Кластер - из их числа. В том числе многие nosql хранилища предлагают решения по шардингу и репликации. Возможно, некая nosql база для какого-то проекта подойдет полностью и решит задачу масштабирования. Но очевидно, если функционал проекта как-то изменится мы не сможем никак изменить поведение базы. Короче черными ящиками управлять невозможно. Подходят - используйте. Мы - не используем и не рекомендуем.
alegenk
Dec. 13th, 2010 03:59 pm (UTC)
Кстати, на badoo.com тоже используется некая сишная разработка для поиска по анкетам. Как-то об этом Алексей Рыбак упоминал на своем мастер-классе, но конкретно он не уточнял детали, т.к. разработкой ее не он занимался.
spb_borodin
Dec. 14th, 2010 09:15 pm (UTC)
Алексей Рыбак доступен для общения и сможет ответить на этот вопрос.
Kyle Butler
Dec. 24th, 2010 05:39 pm (UTC)
Да, я тут в сети видел статью в инете, как сделать ленту обновлений на MongoDB и PHP, разумеется, это не будет работать уже при 1 млн пользователей в базе, т.к. решение не масштабируемо. Но для небольшого сайта приемлемо.


Вы, видимо, не знакомы с MongoDB на должном уровне (использование на production). Функционал масштабируемости в этой БД ничем не уступает популярным СУБД.
spb_borodin
Dec. 24th, 2010 09:38 pm (UTC)
Дело в не этом. Пытаться переложить ответственность за архитектуру честного горизонтального масштабирования на дядю - глупая и безответственная затея. Любые решение, созданные не лично программистом, не будут работать. Иначе бы программисты были не нужны.
dgstudio
Dec. 25th, 2010 03:16 pm (UTC)
Дмитрий, за фразу "забудьте что вы эксперт по explain и используйте только select/update" Вам надо памятник поставить. Золотые слова. Когда смотришь на архитектуру, где для авторизации юзера поднимаются 100 классов php и выполняются 200 джойнов mysql - хочется плакать, нет, просто рыдать.

Спасибо за статью. Записался на будущий мастеркласс.
(Anonymous)
Jan. 11th, 2011 08:20 am (UTC)
О чем нужно знать перед мастер-классом
Спасибо за топик. Хочется попасть на мастер-класс в Киеве. Что нужно знать перед мастер-классом, что бы 100% можно было понять о чем Вы будете рассказывать?

Bezkostniy Vladimir
spb_borodin
Jan. 19th, 2011 08:59 am (UTC)
Re: О чем нужно знать перед мастер-классом
Моя программа построена так, что мы начинаем с азов и простейших примеров, постепенно переходим к более сложным. Всех их используем, чтобы в конце применить к настоящей соц.сети. Поэтому к чему готовиться - я не знаю, вряд ли это возможно.

Было бы полезно применить до мастер класса (на практике, а не на уровне "читал доку") в SQL select for update и в memcache add(), cas().
boooomm
Mar. 29th, 2011 10:43 am (UTC)
Масштабируемость
Я начинающий программист и наиредчайший идиотина, но прочёл обе статьи ради интереса...

Позвольте резюме, правильно ли я понял:
Вместо создания таблицы с полями 1,2,3,4,5,6,n
можно создать несколько "ассоциативных" 1,2 одна из которых общая и расширяемая до бесконечности?
spb_borodin
Mar. 29th, 2011 10:51 am (UTC)
Re: Масштабируемость
Смысл вопроса не ясен, но пример с колонками смахивает на вертикальное масштабирование. Так вот, вертикальное масштабирование - это очень простой паттерн, который вынуждает программиста переписать код и изменить структуру и заведомо имеет осязаемые пределы роста, но позволяет немного масштабироваться. Возможно, если проект не очень крупный, этого хватит. Но, вообще, лучше потратить усилия (те же затраты на изменения кода и базы) на внедрение горизонтального масштабирования.
(Anonymous)
May. 4th, 2011 08:37 am (UTC)
seomaestro
Шикарный пост! Очень понравился)
(Anonymous)
May. 11th, 2011 08:52 pm (UTC)
seoblya
Однозначно подпишусь на ваш сайт
dagdbog
Oct. 8th, 2011 02:00 pm (UTC)
Можно поинтересоваться, когда будет следующий МК в Киеве?
(Anonymous)
Jul. 19th, 2012 08:11 am (UTC)
Верно ли я понял, что в NO-Sql хранилище профайлов вы содержите данные "в каком шарде" можно взять данные, во избежании шардинга в коде ?
spb_borodin
Jul. 19th, 2012 09:35 am (UTC)
Верно или нет - хз, сам вопрос не читабельный. Данные о шардах должны хранится в каком-то конфиге. Он сам может хранится где угодно: в пхп файлах, в структуре sql/nosql. Не существенно, где его хранить, просто важно, чтобы он был мгновенно доступен/кеширован, как и сам исходный код.
(no subject) - (Anonymous) - Jul. 19th, 2012 10:05 am (UTC) - Expand
(no subject) - spb_borodin - Jul. 19th, 2012 10:18 am (UTC) - Expand
(no subject) - (Anonymous) - Jul. 19th, 2012 10:29 am (UTC) - Expand
(no subject) - spb_borodin - Jul. 19th, 2012 12:24 pm (UTC) - Expand
(no subject) - (Anonymous) - Nov. 3rd, 2012 05:03 am (UTC) - Expand
(no subject) - spb_borodin - Nov. 6th, 2012 12:35 am (UTC) - Expand
(Anonymous)
Feb. 20th, 2013 09:34 pm (UTC)
почему столько внимания memcached, а не redis
Собственно вопрос, почему основное внимание в KV уделяется memcached, а не редис, на сколько я понял из преамбулы. Из плюсов memcached - скорость, которая должна быть чуть выше, чем у редис, за счет отсутствия свопинга,дампа на диск и отсутствия репликации, ну и понятно проигрыш редиса при чтении своп данных, как и у tmpfs впрочем. Но для хранения статистики все равно придется использовать memcachedDB, а там беркли и соответственно сброс на диск (опять таки, аналогичные механизмы есть в редис).Остальное пожалуй минусы:
осутствие репликации мастер-слейв, плохо - одна точка отказа, при учете, что кетама не используется и все делается через стратегии шардинга на клиенте, соответственно вся группа ключей выпадет => нагрузка на БД => возможна лавина.Конечно может прийти на помощь zookeeper для таких данных, но в этом случае мемкэш как основной инструмент опять не побеждает редис. На каждую вставку записи + 8 байт на 64 битный токен, для поддержки cas операций. Так как нет свопинга, мемкэш использует lru, а для этого хеш-мап c относительным таймом ведь еще и хранить надо, для О(1).
Полная сериализация списков в мемкэш (что и понятно, иначе пришлось бы еще и перечисленные выше метаданные хранить), понятно не плюс...
Блокировки в мемкэш - много кода, если конечно делать с минимизацией оверхеда, то есть не создавать отдельный ключ блокировки. CAS конечно хорошо, но чем не устраивает lua с редисом, атомарность внутри секции, минимум оверхеда на захват блокировки.
Выпадение ключей по LRU, понятно что это нужно убивать для генераторов ключей, можно использовать ветку мемкэша от фейсбука или самим править(лишняя работа, расхождение с репозиторием, если пульнут авторы в гит новый memcached.c;
Как то так, буду рад услышать ответы.
spb_borodin
Feb. 28th, 2013 10:04 pm (UTC)
Re: почему столько внимания memcached, а не redis
Даже не знаю, что вам ответить, если вы и так отлично во всем разбираетесь и собственно ни одного вопроса не задали :)

MemcacheDB использовать не нужно из-за известной проблемы с диском. Т.е. фактически храним в нем только сессии и кеш от sql запросов. Ну, изредка еще что-то, если данные не нуждаются в сохранении на диск. Для всех остальных данных - Redis. CAS в редисе и мемкеше ничем не отличаются. Только в редисе его нужно оформить как транзакцию. Но вы правы, с помощью LUA в редисе написать более оптимальным код для блокировок, избавляясь от кода на пхп. У нас блокировки за три года сильно эволюционировали, я же рассказываю о самых простых решениях, понятных тем, кто не знаком с редисом.

И отдельно важная идея - если вы способы реализовать некий функционал на простом, как дрова, мемкеше - вы справитесь с задачей на любом другом более сложном хранилище.
(Anonymous)
Feb. 28th, 2013 12:20 pm (UTC)
Test, just a test
Камрад следит за сайтом
spb_borodin
Feb. 28th, 2013 09:20 pm (UTC)
Re: Test, just a test
очень тронут вниманием .-)
Paul Goosev
Nov. 7th, 2014 09:26 am (UTC)
Классная статья, соглашусь со многим, но выделю главную мысль - управлять черным ящиком занятие неблагодарное, лучшее решение это простое решение! Решение, которое создано своими руками (и мыслями о дальнейшей масштабировании)
Спасибо за статью
( 58 comments — Leave a comment )