Partage automatique de MySQL?

Question

À l'heure actuelle, je fais face à une TON (croyez-moi) de données qui doivent être disponibles en temps réel pour les lectures rapides et les écritures aux clients. Le système de stockage backend que nous utilisons est Oracle, mais nous aimerions remplacer nos grosses machines puissantes par un système plus léger. Pour diverses raisons, nous ne pouvons pas utiliser Cassandra, et nous testons (mais j'ai peur) MongoDB (il est vraiment jeune et il lui manque des fonctionnalités critiques), alors je pensais à partager un tas de Instances MySQL.

Y a-t-il un bon système pour gérer cela, ou dois-je lancer le mien? J'ai trouvé quelques projets, mais je ne sais pas s'ils supportent l'ajout/suppression de fragments à la volée.

Answer 1

Vous pouvez très certainement implémenter la fragmentation de base de données avec MySQL très efficacement. Si votre schéma de partage est simple, il peut être fait dans votre couche d'application, mais si c'est plus complexe, vous pouvez utiliser un outil. Beaucoup d'options sont décrites sur notre site ici, ainsi que les options avancées que nous supportons.

Vous pouvez en savoir plus sur les options:

http://www.dbshards.com/articles/database-sharding-whitepapers/

Aussi il est important de considérer le cycle de vie pour un environnement fragmentées, y compris la reprise, la réplication active-active, des sauvegardes, des restaurations et réémergentes sharding comme vous l'avez mentionné ci-dessus. Nous avons des clients qui lisent et écrivent des volumes très élevés avec des milliers d'utilisateurs simultanés dans des environnements cloud (avec des E/S lentes), et encore plus rapidement dans les environnements de centre de données. Sharding peut certainement être incroyablement efficace, avec une mise à l'échelle linéaire et des lectures souvent mieux que linéaire (parce que plus de données sont mises en cache dans la base de données).

Answer 2

Bonne question! Je dois dire que je suis d'accord avec @cisaacson que lorsque votre système deviendra un peu plus complexe, vous voudrez peut-être envisager une sorte de gestion de la base de données. Vous pourriez faire du sciage par vous-même, mais si je comprends bien, vous avez affaire à un scénario compliqué. J'ai récemment fait des recherches sur ce problème pour un projet possible, et c'est ainsi que je me suis lancé dans le sharding (et j'ai trouvé votre message). Tenez compte du fait que le partitionnement peut être un peu difficile ... Ainsi, lors de la planification d'une telle migration, vous pouvez envisager de partitionner, ce qui peut parfois être une solution plus simple (voici une comparaison intéressante du partitionnement/mysql sharding idée sur Wikipedia si nécessaire). Quelques-uns des défis que je connais: comment répliquer des scripts, comment publier des objets sur tous les fragments? Qu'en est-il du versioning? Et cela ne prend même pas en compte les problèmes évidents tels que la quantité de mémoire nécessaire pour accéder aux données, la quantité d'écritures qui peuvent vraiment alourdir la machine esclave, etc. Vu que vous avez écrit ceci il y a un moment, je suis curieux à ce que vous avez décidé de faire à la fin :)

Answer 3

Sharding-JDBC est un pilote JDBC pour les bases de données de partition et les tables. peut-être que vous pouvez essayer de l'utiliser.