smart Oct 24 2007 at 10:01

Основы масштабирования

10 min

62K

Website development*

+66

Comments 49

snitko Oct 24 2007 at 10:51

Спасибо, доступным языком написано и для меня очень своевременно.

smart Oct 24 2007 at 10:58

Пожалуйста :)

BreeZ Oct 24 2007 at 11:04

спасибо. интересно.

UFO just landed and posted this here

edelweard Oct 24 2007 at 11:30

Я тоже заметил эту ошибку. Для автора: это раздел «Распределение данных», пункт «Вертикальное распределение», 5-е предложение.

smart Oct 24 2007 at 12:08

Исправил.

smart Oct 24 2007 at 12:07

Точно, спасибо!

latrommi Oct 24 2007 at 11:12

Полезно, спасибо.
Где бы еще низкобюджетному, но амбициозному стартапу взять столько серверов? :)

edelweard Oct 24 2007 at 11:31

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

kofman Oct 24 2007 at 12:03

попробуйте Amazon Elastic Compute Cloud и Simple Storage Service. Цены очень даже доступные для стартапов.

не техническое решение тоже есть ))) амбициозному стартапу можно поискать инвесторов для покупки серваков.

latrommi Oct 24 2007 at 12:14

спасибо, очень полезно!

smart Oct 24 2007 at 12:08

Найти инвестора, где же еще :)

zen Oct 24 2007 at 11:28

Я бы добавил ссылки на ряд сайтов, специализирующихся на этой тематике. Все-таки,
заметка является уж больно легким введением в проблему, где-то на уровне 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/

Олег

smart Oct 24 2007 at 12:38

Олег, спасибо за ссылки! Я добавлю их в пост. Действительно, эта статья исключительно вводная. А что касается профилирования - так это совершенно отдельная тема ;)

BlackBox Oct 24 2007 at 11:37

А где бы почитать подробнее о конкретных методах реализации "горизонтального распределения" данных?

wecom Oct 24 2007 at 12:10

Пример:
в БД есть таблицы с 2-3 миллионами записей. Пусть для примера это будут те же, ну скажем, фотографии. К каждой фотке, предположим планируется пара десятков комментариев. Итого имеем 40-60 млн комментариев. Никакой MySQL таких таблиц не выдержит. Тогда делаем так:
делим все фото по некоторому признаку на группы, например по ID
GROUP1: 1 < photo_id <= 100000
GROUP2: 100000 < photo_id <= 200000
и т.д.
тогда комментарии для фотографий группы 1 храним на одном сервере
для группы 2 на другом и т.д.
как показывает практика, иногда достаточно иметь несколько таблиц на одном сервере. Все же это быстрее будет работать, чем в одной большой таблице.

ripos Oct 24 2007 at 12:37

Замечу, что у меня были таблицы с текстом и ручными индексами на несколько десятков миллионов записей. Мускуль кушал на ура.
Но, да. Пришлось много читать документацию и очень хорошо понимать, как он работает.

IlVin Oct 25 2007 at 08:17

У вас встанет проект, когда возникнет необходимость почекать огромную таблицу. А в выше описанном способе таблички чекаются не все сразу (стоит часть проекта завязанная на конкретную таблицу, а может и не стоит, если маленькая табличка почекается за разумные 45 секунд). К тому же можно завести 16 табличек, взять MD5 от любого поля записи и в соответствии с первой буквой суммы поместить запись в нужную табличку.
А можно и 256 таблиц завести (2 буквы).
А можно заводить не таблицы, а БД...
И тогда при необходимости часть баз можно будет без вреда перебросить на другой сервер...

smart Oct 24 2007 at 12:23

Начать можно с документации СУБД (вот для MySQL, а вот для Postgres), затем советую обязательно обратить внимание на PL/Proxy. Можно еще вспомнить опыт LiveJournal (у них Mysql с вручную выстроенной кластеризацией), а также посмотреть в сторону "больших" (и дорогих) баз данных типа Oracle, которые умеют образовывать кластер out-of-a-box.

marazm Oct 24 2007 at 14:52

Бесполезно с MySQL. Вот постгрес, да, вещь. Много средств уже готовых.

-4

smart Oct 24 2007 at 15:05

LiveJournal работает. ВКонтакте.ру работает. Значит не бесполезно ;) Правда, и те, и те строят горизонтальную масштабируемость самостоятельно, не основываясь на средствах Mysql.

marazm Oct 24 2007 at 19:18

Согласитесь, в PG это реализуется с гораздо меньшими трудо- и нервозатратами :)

alexbig Oct 24 2007 at 20:37

вот ещё есть опыт wikipedia (pdf, 503 kb)

proxor Oct 24 2007 at 11:50

Спасибо, интересно. Еще бы реальных примеров и вообще бы шоколадно было.

nopox Oct 24 2007 at 22:46

Комментарием выше люди привели примеры.

proxor Oct 25 2007 at 05:38

если вы не заметили, то мой комментарий опубликован раньше. к тому же комментарии это комментарии, а топик это топик.

smart Oct 25 2007 at 07:57

Примеры надо будет сделать отдельной публикацией ;)

UFO just landed and posted this here

smart Oct 24 2007 at 14:15

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

А это - просто введение и именно в вопросы масштабирования, чтобы обозначить тему и может быть вызвать чей-то интерес.

UFO just landed and posted this here

smart Oct 24 2007 at 14:39

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

UFO just landed and posted this here

DarkFighter Oct 24 2007 at 19:20

Хорошая статья, спасибо. Жаль, плюс не могу поставить :(

AndrewStephanoff Oct 24 2007 at 20:17

Спасибо большое за статью.

alexbig Oct 24 2007 at 20:28

спасибо за введение. мне нужен был толчок...

smart Oct 24 2007 at 20:36

Рад, что помог ;)

W_K Oct 25 2007 at 17:56

Статья очень понравилась, спасибо. Правда, "до бесконечности" эта схема не масштабируется, но едва ли во всем мире наберется сотня проектов, для которых ее перестало хватать.

smart Oct 25 2007 at 19:13

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

W_K Oct 27 2007 at 18:48

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

lichh Oct 25 2007 at 21:22

хорошая статья

droganov Mar 15 2008 at 00:17

Отличная статья, спасибо!
Можно пару вопросов?

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

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

Спасибо.

Quessir Jun 22 2008 at 19:36

Ну и что из этого выйдет? Допустим, в одной инстанции вы делаете update, а в другой delete. Как тогда быть? Блокировки? Имхо, это не лучше использования репликации/кластеризации и т.д.