De steel is niet specifiek genoeg om een stevige suggestie te geven, maar de volledige lijst van wat gedaan zou kunnen worden is als volgt:
- Databasecluster :Geschikt voor situaties waarin u uw applicatielaag niet wilt wijzigen en database is alles wat u aanraakt. Er is een limiet aan hoeveel u uit een databasecluster kunt halen. Als uw verzoekvolume blijft groeien, zal deze oplossing uiteindelijk ook mislukken. Maar het goede nieuws is dat je alle functionaliteit hebt die je al had in een gewone single-instance MySQL.
- Sharden :Aangezien uw vraag is getagd met MySQL en deze op zichzelf geen sharding ondersteunt, moet u deze in uw applicatielaag implementeren als u deze oplossing wilt gebruiken. In deze oplossing strooi je je data logisch over meerdere databases (bij voorkeur in meerdere MySQL instances op aparte hardware). Het is uw verantwoordelijkheid om de juiste database te vinden die uw aangewezen gegevens bevat. Het is een van de meest effectieve oplossingen ooit, maar het is niet altijd haalbaar. De grootste fout is dat gegevens verspreid over twee of meer databases niet in een transactie kunnen worden opgenomen.
- Replicatie :Afhankelijk van uw scenario kunt u databasereplicatie opnemen en er kopieën van uw gegevens op hebben. Op deze manier kunt u er verbinding mee maken in plaats van de hoofddatabase en de belasting ervan verminderen. De standaard replicatiedefinitie is een master/slave-scenario waarin de gegevensstroom in één richting verloopt, van master naar slave. Dus wijzigingen die u op de slave aanbrengt, terwijl ze op de zalf worden toegepast, hebben geen invloed op de master. Maar er is ook een master/master-replicatieconfiguratie waarin de gegevensstroom in beide richtingen verloopt. Toch kunt u geen atomaire integriteit aannemen voor gelijktijdige gegevenswijzigingen tussen beide masters. Uiteindelijk is deze oplossing het meest effectief als u van plan bent deze in master/slave-modus te gebruiken en slaves te gebruiken voor alleen-lezen toegang.
- Caching :Misschien moet deze oplossing hier niet worden opgenomen, maar aangezien je stam het niet verwerpt, hier gaat het. Een van de manieren om de belasting van de database te verminderen, is door de gegevens in de cache op te slaan nadat ze zijn geëxtraheerd. Deze oplossing kan vooral nuttig zijn als het extraheren van gegevens duur is. Er zijn veel cacheservers, zoals memcached of redis . Op deze manier kunt u zoveel databaseverbindingen weglaten, maar alleen voor het extraheren van gegevens.
- Andere opslag-engines :U kunt altijd overstappen op krachtigere motoren als uw huidige niet biedt wat u nodig heeft. Dit is natuurlijk alleen mogelijk als uw behoeften het toelaten. Tegenwoordig zijn er NoSQL-engines, veel performanter dan RDBMS, die native sharding ondersteunen en je kunt ze lineair schalen met minimale inspanning. Er zijn ook op Lucene gebaseerde oplossingen met krachtige full-text zoekmogelijkheden die u dezelfde automatische sharding bieden. In feite is de enige reden waarom u een traditioneel RDBMS zou moeten gebruiken, het atomaire gedrag van transacties. Maar als transacties geen must zijn, zijn er veel betere oplossingen dan RDBMS.