Pull to refresh

Comments 49

Спасибо, доступным языком написано и для меня очень своевременно.
UFO landed and left these words here
UFO landed and left these words here
Я тоже заметил эту ошибку. Для автора: это раздел «Распределение данных», пункт «Вертикальное распределение», 5-е предложение.
Полезно, спасибо.
Где бы еще низкобюджетному, но амбициозному стартапу взять столько серверов? :)
Пока нагрузка невелика, это и не нужно. Нужно лишь при разработке архитектуры системы учитывать, что в будущем её потребуется масштабировать. А когда придётся масштабировать, проект, полагаю, уже будет не столь низкобюджетен ;)
попробуйте Amazon Elastic Compute Cloud и Simple Storage Service. Цены очень даже доступные для стартапов.

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

Например:

http://www.highscalability.com/
http://www.royans.net/arch/
http://poorbuthappy.com/ease/archives/2007/04/29/3616/the-top-10-presentation-on-scaling-websites-twitter-flickr-bloglines-vox-and-more
http://www.possibility.com/epowiki/Wiki.jsp?page=Scalability


А для начала, я бы попрофилировал бы странички, много проблем будет заметно уже на этом этапе и может даже и шкалировать ничего не нужно :)
Вот нормальная тулза для этого:
http://tools.pingdom.com/fpt/

Олег
Олег, спасибо за ссылки! Я добавлю их в пост. Действительно, эта статья исключительно вводная. А что касается профилирования - так это совершенно отдельная тема ;)
А где бы почитать подробнее о конкретных методах реализации "горизонтального распределения" данных?
Пример:
в БД есть таблицы с 2-3 миллионами записей. Пусть для примера это будут те же, ну скажем, фотографии. К каждой фотке, предположим планируется пара десятков комментариев. Итого имеем 40-60 млн комментариев. Никакой MySQL таких таблиц не выдержит. Тогда делаем так:
делим все фото по некоторому признаку на группы, например по ID
GROUP1: 1 < photo_id <= 100000
GROUP2: 100000 < photo_id <= 200000
и т.д.
тогда комментарии для фотографий группы 1 храним на одном сервере
для группы 2 на другом и т.д.
как показывает практика, иногда достаточно иметь несколько таблиц на одном сервере. Все же это быстрее будет работать, чем в одной большой таблице.
Замечу, что у меня были таблицы с текстом и ручными индексами на несколько десятков миллионов записей. Мускуль кушал на ура.
Но, да. Пришлось много читать документацию и очень хорошо понимать, как он работает.
У вас встанет проект, когда возникнет необходимость почекать огромную таблицу. А в выше описанном способе таблички чекаются не все сразу (стоит часть проекта завязанная на конкретную таблицу, а может и не стоит, если маленькая табличка почекается за разумные 45 секунд). К тому же можно завести 16 табличек, взять MD5 от любого поля записи и в соответствии с первой буквой суммы поместить запись в нужную табличку.
А можно и 256 таблиц завести (2 буквы).
А можно заводить не таблицы, а БД...
И тогда при необходимости часть баз можно будет без вреда перебросить на другой сервер...
Начать можно с документации СУБД (вот для MySQL, а вот для Postgres), затем советую обязательно обратить внимание на PL/Proxy. Можно еще вспомнить опыт LiveJournal (у них Mysql с вручную выстроенной кластеризацией), а также посмотреть в сторону "больших" (и дорогих) баз данных типа Oracle, которые умеют образовывать кластер out-of-a-box.
Бесполезно с MySQL. Вот постгрес, да, вещь. Много средств уже готовых.
LiveJournal работает. ВКонтакте.ру работает. Значит не бесполезно ;) Правда, и те, и те строят горизонтальную масштабируемость самостоятельно, не основываясь на средствах Mysql.
Согласитесь, в PG это реализуется с гораздо меньшими трудо- и нервозатратами :)
Спасибо, интересно. Еще бы реальных примеров и вообще бы шоколадно было.
Комментарием выше люди привели примеры.
если вы не заметили, то мой комментарий опубликован раньше. к тому же комментарии это комментарии, а топик это топик.
Примеры надо будет сделать отдельной публикацией ;)
UFO landed and left these words here
Ну поймите, это не статья "как спасти сайт, захлебывающийся под нагрузкой". Когда я буду писать такую статью, я обязательно расскажу о том, что надо делать в первую очередь - и это будет, конечно, совсем не построение масштабируемой архитектуры ;)

А это - просто введение и именно в вопросы масштабирования, чтобы обозначить тему и может быть вызвать чей-то интерес.
UFO landed and left these words here
Ну кстати, на эту тему мы с коллегами проводили семинар (точнее, даже два), где было и о масштабируемости, и об оптимизации, и о многом другом. Если будет спрос - мы соберемся и проведем его снова. Впрочем, статья наверняка тоже будет.
UFO landed and left these words here
Статья очень понравилась, спасибо. Правда, "до бесконечности" эта схема не масштабируется, но едва ли во всем мире наберется сотня проектов, для которых ее перестало хватать.
Николай, эта статья явно не на таких специалистов, как ты, рассчитана :) Это ведь просто общие принципы - а вот их комбинирование уже позволяет достичь того, чего надо.
Куда уж из меня специалист... Я только в январе начал что-то узнавать на эту тему, а до этого вообще ничего не знал о масштабируемости веб-сайтов.
Отличная статья, спасибо!
Можно пару вопросов?

Сколько времени (в общем случае) должно уходить у backend'a не генерацию страницы? Допустим у хабра на генерацию данной страницы?

Возможно ли заставить кластер MySQL5 работать с одним и тем-же экземпляром базы без репликации. Допустим, все таблицы хранятся в starage > /var/db и подмапленый в машинах db-кластера... Если вруг где есть об этом (имеено об этом) прочитать, то можно ссылку?

Спасибо.
Ну и что из этого выйдет? Допустим, в одной инстанции вы делаете update, а в другой delete. Как тогда быть? Блокировки? Имхо, это не лучше использования репликации/кластеризации и т.д.
Пожалуйста :) Приятно, что спустя два года статья все еще полезна ;)
Only those users with full accounts are able to leave comments. Log in, please.