Тезисы и цели мастер-класса
Несколько тезисов, идей и целей мастер-класса и всей предлагаемой идеологии построения
крупных масштабируемых проектов (это можно назвать - честное горизонтальное
масштабирование).
Основная и общая цель - поделиться полноценным и воспроизводимым способом
создания крупного проекта. Реальная архитектура и принципы, которые вы, как тимлид вашего проекта,
все равно будете вынуждены придумывать, чтобы выдержать нагрузку.
№1. Для большинства проектов подойдет одна архитектура.
Большой сюрприз заключается в том, что для почти всех веб-проектов, связанных с общением
или торговлей, прекрасно подходит одна универсальная архитектура проекта.
Нет никакой разницы, что вы задумали написать - соц.сеть, онлайн игру, веб-магазин, блог-хостинг,
СМИ и т.д., вы просто под термином “сущность USER” подразумеваете разные объекты: профайл
в соц.сети, профайл игрока или игрового объекта в игре, товар в магазине, ветка в блоге и т.д.
Разницы нет! Архитектура не подойдет лишь для бизнес задач (бухгалтерия 1С) или где сущности
иного плана - твиттер или чат (слишком мелкие сущности, а профайлы пользователей играют
второстепенную роль).
Все программисты, еще с древних ламповых ЭВМ, стремились писать функции и библиотеки,
чтобы их трудом могли пользоваться другие люди (либо они же, но в другой раз). Данная идея,
что для почти любого проекта можно использоваться одни и те же подходы построения
архитектуры, замечательно вписывается в стремления любого программиста к универсальности.
№2. Для каких языков программирования подойдет эта архитектура и мастер-класс?
Для любых. Мы изучаем идеи по оперированию данными. И нет ни слово о том, на каком языке это
нужно делать. Язык программирования - это всего лишь средство перегнать данные из браузера в
базу данных и обратно. Да хоть на Бейсике программируйте, архитектура не изменится.
Java, Ruby, Python, C/C++, C#, PHP, Perl и др. программисты - добро пожаловать! На мастер-
классе нет ни строчки кода на PHP, вернее, немногочисленный псевдокод на слайдах в примерах
абсолютно одинаков для всех языков.
№3. Зачем мастер-класс? В инете же полно информации.
Конечно, это одно из самых больших заблуждений. Вам, как тимлиду вашего проекта, предстоит
решить много проблем. Если вы не работали в компании, где уже имелся успешный и крупный
проект, то шансы придумать свой велосипед - практически равен нулю. Умножьте это на
проблему вирусной раскрутки проекта с большим числом новых пользователей, что вызывает
резкий подъем посещаемости и нагрузки на железо.
Чтобы повысить шансы необходимо, либо взять готовую проверенную архитектуру, либо
добиться, чтобы рост нагрузки был очень плавным, например, при регистрации 10-ти новых
пользователей в день. Не больше. В таком случае, несомненно, как бы ни был плох велосипед, вы
будете успевать его обновлять вслед растущей нагрузке. Просто рост будет долгим.
Я очень часто называю другие подходы “не традиционными”. Но это не значит, что все, кто их не
знает или не понимает, т.е. работает традиционно - глупы или не способны на что-то великое.
“Традиционность” заключается в том, что, к сожалению, не у всех был шанс поработать в
действующих крупных проектах.
Лет 5 назад я многого не знал из того, что нужно было бы. И сейчас я понимаю, насколько мои
шансы на успешный проект были близки к нулю, если бы я разрабатывал его традиционными
путями, без заимствования лучших идей уже у существующих крупных проектов, такие, как
топовые соц.сети. Собственно, это цель мастер-класса, поделиться жизненно важной
информацией, которой нигде нет.
№4. К чему мы стремимся? В чем профит?
Здесь описаны наши “хотелки”, которых мы достигаем по итогам обучения.
- Мы хотим писать код и делать структуру базы так, чтобы проект смог удержать нагрузку при
выстреле посещаемости без необходимости переписывать весь код с нуля и менять структуру
базы.
- Мы хотим один раз заложить архитектуру и потом не задумываться, как внедрять каждый день
новый функционал или новые методы хранения данных в базе. Намного проще новые данные
загнать в старый объект, который создан с нуля, с учетом будущих расширений.
- Мы не знаем, где и какая нагрузка у нас будет. Проект должен быть способен в течении суток
уметь мгновенно приспособится к 10-кратно возросшей нагрузке. Причем этого нужно добиться
лишь администрированием и докупкой железа, а не изменением кода или базы данных. Заранее
предсказать будущие нагрузки и узкие места невозможно (и это не нужно). Проект должен уметь
работать на любом слабом железе. Метод вертикального масштабирования путем апгрейда железа
не резиновый. А надеяться на чужие технологии масштабирования, типа SQL кластера - весьма наивно
и работает только для небольшого числа SQL серверов.
- Мы не хотим тратить много лишнего времени. Но одновременно понимаем, что все данные
проекта не влезут в одну таблицу и ее все равно придется рано или поздно “порезать”. Так лучше
сразу потратить это “неизбежное” время на внедрение правильной архитектуры, чтобы не
допустить остановки проекта. Все предложенные идеи не заставляют вас писать все с нуля и
идеально. Достаточно следовать принципу готовности к выстрелу проекта, для чего критически
важно начать хотя бы данные хранить правильно в sql и nosql хранилищах. Это план минимум,
позволяющий экономить время, как и во время традиционной разработки проектов.
- Нам не важно, как изменится ТЗ на проект и что завтра придет в голову инвестору/менеджеру
(уж извините за правду). Это никак не повлияет на элементарные методы чтения, записи и
оперирования сущностями, т.е. на большую часть реализации архитектуры проекта. При
изменении ТЗ не поменяется почти ничего в серверной части кода. Но, разумеется, клиентская
часть изменится: веб-контроллеры с логикой, шаблонами, окошками, кода на javascript и т.д. В
общем, мы хотим быть защищены от каждодневных хотелок менеджеров.
- Мы хотим легко вводить в проект принятых на работу новичков. Т.е. нужно максимально скрыть
от них всю архитектуру, чтобы не тратить время на обучение (пусть программируют, как привыкли)
и чтобы не было необходимо им лезть в низкоуровневые классы и драйверы, отвечающие за
масштабирование данных в проектах. Если очень грубо, то инструкция для новичка сводиться к
одному указанию: JOIN на данных разных пользователей использовать нельзя (join возможен
только с данными одного пользователя). Согласен, когда нельзя сделать JOIN по данным 2х юзеров
это ограничение в гибкости программирования. В небольшом числе задач это важно.
Но, тут уж вам придется самим думать, что выгоднее - мириться с ограничениями
(их можно обойти, потратив доп. время) или работать традиционно.
№5. Вы - DBA или сис.админ? Думаете, секрет highload в волшебных настройках?
Конечно, никаких волшебных настроек базы данных или серверов не существует (есть просто
оптимальные). Если программисты не предоставили админу или DBA возможность разделения
данных проекта на любое число изолированных кусков (шардов), то никакими ухищрениями вы не
сможете масштабировать проект, когда тот не влезает даже в предельно проапгрейженный
сервер.
Любой веб-проект может работать на любом слабом железе и с откровенным лапшекодом (по
быстрому написали и на прод - это реалии жизни). Но имея масштабируемую архитектуру вы
имеете инструмент почти без участия программистов (без переписывания кода или архитектуры
БД) докупить железа и перенести часть нагрузки туда. Все, это профит, проект спасен. Далее
программисты имеют достаточно времени на исправление лапшекода. Наш проект в первый день
своей работы выдержал 500.000 DAU, хотя был написан очень быстро, без тестирования вообще,
но с нормальной архитектурой.
Поэтому в крупных проектах сам термин highload не играет практически никакой роли во время
разработки и возможности приспособиться к нагрузкам. Когда проект большой, там сотни
серверов, разумеется, оптимизации важны, чтобы не транжирить деньги на железе. Но считать, что
некий мифический highload позволит реализовать проект - заблуждение.
Мастер-класс вполне подходит для системных администраторов и особенно для DBA, общий
смысл для которых будет в рецепте - как в принципе больше никогда не делать сложных SQL
запросов и не думать о гигантских индексах.
Другие вопросы
Какой фреймворк выбрать?
При выборе нового проекта, команда разработчиков очень тщательно пытается определить, какой
фреймворк им подойдет лучше всего. Не забывайте, что фреймворки отвечают на вопрос - как
коллективно писать код, как делать меньше багов, как добиться гибкости и т.д. Фреймворки
решают любые проблемы, кроме главной - как хранить данные. Вот и догадайтесь сами, на каких
действительно важных вопросах лучше сосредоточиться.
Зачем вообще осваивать nosql?
Это повтор тезиса №4, но тем не менее... Таблицы - не резиновые и загнуться на некотором росте
данных в них. Следовательно, чтобы избежать смерти, вы заранее придумаете велосипед по
разрезке таблиц. Т.е. потратите некоторое дополнительное время на велосипед. Ну, так потратьте
то же самое время с пользой - на полноценный nosql подход.
Что быстрее - SQL (традиционно) или nosql?
Если данных крайне мало (форум на 5 сообщений). Разницы нет. На среднем числе данных, уже от
10 000 сообщений начинает ощущаться выгода от nosql. Секрет в том, что при nosql подходе вы
начинаете хранить данные кардинально другим методом, не требующим тормозных индексов в
таблицах и выигрываете на скорости чисто из-за этого.
На большом объеме данных (форум с 1,000,000 сообщений) - ваш MySQL просто умрет из-за
невозможности в адекватное время параллельно и новые сообщения писать (перестраивать
индексы) и выдавать информацию в режиме чтения. Так что сравнивать почти и нечего.
Напоминаю, в nosql подходе вы в 50% случаях храните данные в том же MySQL/PostgreSQL,
просто с иными принципами (не традиционными). При этом база данных перестает умирать, не
имеет пределов роста проекта, легко балансируются внезапные перекосы нагрузки от написанного
вами нового функционала. Но, разумеется, nosql не волшебная палочка, этот подход накладывает
существенные ограничения в гибкости непредусмотренных заранее вычислений (хотя, все можно
решить).
Большой сюрприз от nosql подхода - он почти линейно выполняет любые операции даже при
росте всех данных проекта в 2 раза. Чего про SQL не скажешь.
