La tige n'est pas assez spécifique pour donner une suggestion ferme, mais la liste complète de ce qui pourrait être fait est la suivante :
- Cluster de bases de données :Convient aux situations où vous ne souhaitez pas modifier votre couche d'application et la base de données est tout ce que vous touchez. Il y a une limite à ce que vous pouvez obtenir d'un cluster de bases de données. Si votre volume de demandes ne cesse de croître, cette solution finira également par échouer. Mais la bonne nouvelle est que vous disposez de toutes les fonctionnalités que vous aviez déjà dans un MySQL à instance unique ordinaire.
- Partage :Étant donné que votre question est étiquetée avec MySQL et qu'elle ne prend pas en charge le partitionnement, si vous souhaitez utiliser cette solution, vous devez l'implémenter dans votre couche d'application. Dans cette solution, vous répartirez logiquement vos données sur plusieurs bases de données (de préférence dans plusieurs instances MySQL sur du matériel distinct). Il vous incombera de trouver la base de données appropriée contenant vos données désignées. C'est l'une des solutions les plus efficaces qui soient, mais ce n'est pas toujours faisable. Son plus gros défaut est que les données dispersées entre deux ou plusieurs bases de données ne peuvent pas être incluses dans une transaction.
- Réplication :Selon votre scénario, vous pourrez peut-être intégrer la réplication de la base de données et disposer de copies de vos données dessus. De cette façon, vous pouvez vous y connecter au lieu de la base de données principale et réduire la charge sur celle-ci. La définition de réplication par défaut est un scénario maître/esclave dans lequel le flux de données est unidirectionnel, du maître vers l'esclave. Ainsi, les modifications que vous pourriez apporter à l'esclave alors qu'elles seront appliquées à la pommade, elles n'affecteront pas le maître. Mais il existe également une configuration de réplication maître/maître dans laquelle le flux de données se fait dans les deux sens. Pourtant, vous ne pouvez pas supposer l'intégrité atomique des modifications de données simultanées entre les deux maîtres. Au final cette solution est plus efficace si vous envisagez de l'utiliser en mode maître/esclave et d'utiliser des esclaves pour un accès en lecture seule.
- Mise en cache :Peut-être que cette solution ne devrait pas être incluse ici mais puisque votre tige ne la rejette pas, la voici. L'un des moyens de réduire la charge de la base de données consiste à mettre en cache ses données une fois extraites. Cette solution peut être particulièrement intéressante si l'extraction de données est coûteuse. Il existe de nombreux serveurs de cache, comme memcached ou redis . De cette façon, vous pouvez omettre un grand nombre de connexions à la base de données, mais uniquement pour l'extraction de données.
- Autres moteurs de stockage :Vous pouvez toujours passer à des moteurs plus performants si votre moteur actuel ne vous fournit pas ce dont vous avez besoin. Bien sûr, cela n'est possible que si vos besoins vous le permettent. De nos jours, il existe des moteurs NoSQL, beaucoup plus performants que RDBMS, qui prennent en charge le sharding de manière native et vous pouvez les faire évoluer de manière linéaire avec un minimum d'effort. Il existe également des solutions basées sur Lucene avec de puissantes capacités de recherche en texte intégral vous offrant le même partage automatique. En fait, la seule raison pour laquelle vous devriez utiliser un SGBDR traditionnel est le comportement atomique des transactions. Mais si les transactions ne sont pas indispensables, il existe de bien meilleures solutions que le SGBDR.
