Стъблото не е достатъчно конкретно, за да даде категорично предложение, но пълният списък на това, което може да се направи, е както следва:
- Клъстер от база данни :Подходящ за ситуации, в които не искате да променяте слоя на приложението си и базата данни е всичко, което докосвате. Има ограничение за това колко можете да получите от клъстер от база данни. Ако обемът на заявките ви продължава да нараства, това решение в крайна сметка също ще се провали. Но добрата новина е, че разполагате с цялата функционалност, която вече сте имали в обикновен MySQL с един екземпляр.
- Разделяне :Тъй като вашият въпрос е маркиран с MySQL и не поддържа разделяне самостоятелно, ако искате да използвате това решение, трябва да го приложите в слоя на приложението си. В това решение ще разпръснете данните си в множество бази данни (за предпочитане в множество MySQL екземпляри на отделен хардуер) логически. Ваша отговорност е да намерите подходящата база данни, съдържаща определените от вас данни. Това е едно от най-ефективните решения, но не винаги е осъществимо. Най-големият му недостатък е, че данните, разпръснати между две или повече бази данни, не могат да бъдат включени в транзакция.
- Репликация :В зависимост от вашия сценарий може да сте в състояние да включите репликация на база данни и да имате копия на вашите данни в тях. По този начин можете да се свържете с тях вместо към главната база данни и да намалите натоварването върху нея. Дефиницията за репликация по подразбиране е сценарий главен/подчинен, при който потокът от данни е еднопосочен, от главен към подчинен. Така че промените, които може да направите на подчинения, докато ще бъдат приложени върху мехлема, те няма да засегнат главния. Но има и конфигурация главен/главен репликация, при която потокът от данни е и по двата начина. И все пак не можете да приемете атомна цялост за едновременни промени в данните между двата главни. В крайна сметка това решение е най-ефективно, ако планирате да го използвате в режим главен/подчинен и да използвате подчинени за достъп само за четене.
- Кеширане :Може би това решение не трябва да бъде включено тук, но тъй като вашето стебло не го отхвърля, ето го. Един от начините за намаляване на натоварването на базата данни е да се кешират нейните данни, след като бъдат извлечени. Това решение може да бъде от полза, особено ако извличането на данни е скъпо. Има много кеш сървъри, като memcached или redis . По този начин можете да пропуснете толкова много връзки към базата данни, но само за извличане на данни.
- Други машини за съхранение :Винаги можете да преминете към по-ефективни двигатели, ако текущият ви не ви осигурява това, от което се нуждаете. Разбира се, това е възможно само ако нуждите ви позволяват. В днешно време има NoSQL двигатели, много по-ефективни от RDBMS, които поддържат разделяне и можете да ги мащабирате линейно с минимални усилия. Съществуват и базирани на Lucene решения с мощни възможности за търсене в пълен текст, които ви осигуряват същото автоматично разделяне. Всъщност единствената причина, поради която трябва да използвате традиционна RDBMS, е атомарното поведение на транзакциите. Но ако транзакциите не са задължителни, има много по-добри решения от RDBMS.
