PHP Highload Стратегии за мащабиране на MySQL
Продължавайки темата за балансиране на натоварването, нека да разгледаме стратегиите за мащабиране на база данни, а именно разделяне, шардинг и репликация. Както винаги с практически примери, нека да измислим няколко проблема и да се опитаме да ги разрешим.
В предишната публикация усетихме на собствената си кожа, че няма нищо трудно в мащабирането на уеб приложения. Но когато тясното място не е изпълнимият код, а SQL заявките, други методи и стратегии влизат в действие. Има някои нюанси в мащабирането на базата данни поради трудността да се поддържат актуални данните на много сървъри и следователно стратегията зависи от структурата на данните, архитектурата и, разбира се, вида на проблема.
репликация
В допълнение, репликацията се използва за географско разпределение на сървърите (например един сървър в Америка, друг в Европа).
Как работи репликацията
Когато извършва модификации, главният сървър записва всички направени промени в дневника, подчинените сървъри периодично проверяват дневника за нови данни и, ако има такива, извършват подобни действия с техните данни.
Репликационни схеми
1 владее много роби
Схемата обикновено се използва в приложения с доминиращи заявки за четене - всички заявки за промяна на базата данни се изпращат към главния сървър, докато заявките за четене се разпределят между подчинените.
Обикновено приложението посочва списък от сървъри (пул), предназначени за четене, от които mysql клиентът по някакъв начин (на случаен принцип или по зададен алгоритъм) избира сървъра за изпълнение на заявката, като по този начин балансира натоварването между всички сървъри.
Недостатъкът на схемата е очевиден - ако главният сървър откаже, всички заявки за модификация и добавяне на данни няма да бъдат изпълнени.
Веригаглавен сървър
Много полезно за географско разпределение на данни. Например, ние настройваме сървъри в Европа, Азия и Америка, настройваме ги във верига и учим приложението да избира сървър в зависимост от региона. Така печелим, като намаляваме пътя на заявката до сървъра.
Когато натоварването на един от регионалните сървъри се увеличи, към него лесно могат да се добавят няколко подчинени устройства.
Недостатъкът на схемата е подобен на предишния - ако един от главните сървъри се повреди, веригата ще бъде прекъсната, но останалите регионални сървъри ще работят независимо, което вече е по-добре.
2 господари, много роби
Схемата представлява верига от два главни сървъра. И двата главни изпълняват заявки за промяна на данни и имат равен брой подчинени. По този начин, ако единият главен се повреди, приложението ще продължи да работи с втория и неговите подчинени.
Разгледайте примера за настройка на репликация между главен и подчинен.
Всеки сървър в схемата за репликация трябва да има уникален номер (цяло число), който трябва да бъде въведен в my.cnf в секцията [mysqld].
Например за майстор:
Освен това трябва да активирате регистрационния файл на главния, за който въвеждаме там:
Рестартираме и двата сървъра, след което главният вече е готов за работа, а робът трябва да посочи кой е неговият господар, за това:
Това е всичко, репликацията между сървърите е конфигурирана, сега след изпълнение на заявката за модификация на главния, данните ще бъдат актуализирани на подчинения. Прост и сърдит.
Ако репликацията трябва да бъде конфигурирана за вече съществуваща база данни, и двата сървъра трябва да имат едни и същи данни, преди да стартират.
Преграждане
Понякога има таблици с някакво логическо групиране на данни, като списък за пазаруване на потребител илирегистърът на активността може да бъде групиран по дата. И когато повечето заявки работят с групи (например, интересуват се само статистически данни за една година), тогава има смисъл да съхранявате данни, разделени на групи, директно в базата данни. Процесът на разделяне на данни и съхраняването им в някои групи се нарича разделяне.
Разгледайте примера на таблицата:
4 вида разделяне:
1. По диапазон
Всеки дял съдържа данни, принадлежащи към посочения диапазон от стойности на колони.
Дял p0 ще съдържа всички редове, в които store_id
Например, дялът pNorth ще включва всички редове, в които store_ >
Таблицата е разделена по хеш стойността на някаква колона.
4. По ключ
Подобно на предишния метод, но по ключ.
Последните два метода не дават възможност да се посочи в кой от дяловете ще попадне низът, а само броя на дяловете, механизмът за разпределение на MySQL поема.
Дяловете могат да бъдат разделени на подраздели, които могат да бъдат допълнително разделени и т.н.
В същото време, когато съставяте заявка, не е нужно да мислите къде и в каква форма се съхраняват данните, просто напишете заявка към таблицата на служителите и MySQL ще определи за кои дялове трябва да бъде изпълнена.
В реалния живот дяловете не се използват често, тъй като в повечето случаи е достатъчен индекс, но все пак трябва да запомните за тяхното съществуване.
Шардинг - развитието на разделяне - разделяне на данни в групи и съхраняване на всяка група на отделен сървър (шард). В този случай групата не включва непременно една таблица, тя може да бъде няколко таблици, съдържащи едно цяло. Например, имайки много регистрирани потребители, чиито данни са в няколко таблици (данни за регистрация, история на покупките, регистър на действията), всеки шард ще имацялата инфраструктура (всички таблици) се съхранява, но с данни само за потребителите на текущия шард (например един шард - потребители с фамилни имена от A до D, вторият D-K и т.н.).
MySQL не поддържа автоматично шардинг, така че трябва да го направите на ниво приложение, като изберете правилния сървър в зависимост от заявката. Обикновено се създава параметризиран пул от сървъри (в примера по-горе първата буква от фамилията ще бъде такъв параметър) и при изпълнение на всяка заявка желаният сървър се избира чрез този параметър.
Шардингът е последната мярка за мащабиране (когато репликацията вече не записва), не само поради сложността на изпълнението, но и поради сложността на работата с данни. Тъй като работата с шардове се извършва на ниво приложение, ние автоматично отказваме тригери, съхранени процедури и други екстри, вградени в базата данни, които трябва да работят с всички данни, тъй като на ниво база данни на всеки шард има само неговия набор от данни и той не знае нищо за другите.
Ето защо, преди да приложите MySQL шардинг, трябва да помислите много внимателно и да сте сигурни, че няма друг начин.
Ако публикацията ви е харесала - кликнете върху +1 - ще се радвам.