Прочетох МНОГО за наличните опции. Освен това се сдобих с High Performance MySQL 2nd edition, което силно препоръчвам.
Ето какво успях да сглобя:
Групиране
Групирането в общия смисъл е разпределяне на натоварването между много сървъри, които изглеждат на външно приложение като един сървър.
MySQL NDB клъстер
MySQL NDB Cluster е разпределен двигател за съхранение в паметта, споделено нищо със синхронна репликация и автоматично разделяне на данни (извинете ме, че заимствам буквално от книгата за висока производителност, но те го поставят много добре там). Това може да бъде високопроизводително решение за някои приложения, но уеб приложенията обикновено не работят добре върху него.
Основният проблем е, че освен много прости заявки (които докосват само една таблица), клъстерът обикновено ще трябва да търси данни на няколко възли, което позволява латентността на мрежата да се промъкне и значително да забавя времето за завършване на заявките. Тъй като приложението третира клъстера като един компютър, то не може да му каже от кой възел да извлече данните.
Освен това изискването в паметта не е приложимо за много големи бази данни.
Продължителна секвоя
Това е друго клъстерно решение за MySQL, което действа като междинен софтуер върху MySQL сървъра. Той предлага синхронна репликация, балансиране на натоварването и отказ. Той също така гарантира, че заявките винаги получават данните от последното копие, като автоматично избират възел, който има новите данни.
Прочетох някои добри неща върху него и като цяло звучи доста обещаващо.
Федерация
Федерирането е подобно на клъстерирането, така че го дръпнах и тук. MySQL предлага обединение чрез обединения двигател за съхранение. Подобно на клъстерното решение на NDB, то работи добре само с прости заявки - но още по-лошо е клъстерът за сложни (тъй като латентността на мрежата е много по-голяма).
Репликация и балансиране на натоварването
MySQL има вграден капацитет за създаване на репликации на база данни на различни сървъри. Това може да се използва за много неща – разделяне на натоварването между сървъри, горещо архивиране, създаване на тестови сървъри и отказ.
Основната настройка на репликацията включва един главен сървър, обработващ предимно запис, и един или повече подчинени, обработващи само четене. По-разширен вариант е този на master-master конфигурация, която позволява да се мащабират записите, като има няколко сървъра, които пишат едновременно.
Всяка конфигурация има своите плюсове и минуси, но един проблем, който всички споделят, е забавянето на репликацията - тъй като MySQL репликацията е асинхронна, не всички възли имат най-новите данни по всяко време. Това изисква приложението да е наясно с репликацията и да включва заявки, наясно с репликация, за да работи според очакванията. За някои приложения това може да не е проблем, но ако винаги имате нужда от най-актуалните данни, нещата стават малко сложни.
Репликацията изисква известно балансиране на натоварването, за да се раздели натоварването между възлите. Това може да бъде толкова просто, колкото някои модификации на кода на приложението или използване на специален софтуер и хардуерни решения.
Разделяне и разделяне
Разделянето е често използван подход за мащабиране на решения за бази данни. Разделяте данните на по-малки фрагменти и ги разпространявате около различни сървърни възли. Това изисква приложението да е наясно с модификацията на съхранението на данни, за да работи ефективно, тъй като трябва да знае къде да намери необходимата информация.
Има налични рамки за абстракция, които да помогнат за справянето с разделянето на данни, като например Хибернация на парчета , разширение към Hibernate ORM (което за съжаление е в Java. Използвам PHP). HiveDB е друго такова решение, което също поддържа балансиране на парчета.
Други
Сфинкс
Сфинкс е пълнотекстова търсачка, която може да се използва за много повече от тестови търсения. За много заявки той е много по-бърз от MySQL (особено за групиране и сортиране) и може да запитва паралелно отдалечени системи и да обобщава резултатите - което го прави много полезен при използване с разделяне.
Като цяло sphinx трябва да се използва с други решения за мащабиране, за да получите повече от наличния хардуер и инфраструктура. Недостатъкът е, че отново се нуждаете от кода на приложението, за да сте наясно със sphinx, за да го използвате разумно.
Резюме
Решенията за мащабиране се различават в зависимост от нуждите на приложението, което се нуждае от него. За нас и за повечето уеб приложения вярвам, че репликацията (вероятно мулти-главна) е начинът да се направи с балансьор на натоварване, разпределящ натоварването. Разделянето на конкретни проблемни области (огромни таблици) също е задължително, за да можете да мащабирате хоризонтално.
Също така ще пробвам Continuent Sequoia и ще видя дали наистина може да направи това, което обещава, тъй като ще включва най-малко промени в кода на приложението.
