l'accès simultané à la base de données ou au fichier de mémoire à partir de plusieurs processus, est-ce possible?

Question

Voici ma situation. J'ai une application serveur conçue pour plusieurs utilisateurs, donc il y a beaucoup de lecture/écriture en même temps. Et les réponses doivent être rapides.

Actuellement, je mettais toutes les données en mémoire pour que l'opération de lecture/écriture des données soit aussi rapide que prévu. Pour éviter que le verrou de données me cause des problèmes, j'ai utilisé la file d'attente le gestionnaire gère un par un.

Mais j'ai vite trouvé un problème. Le programme ne peut traiter qu'une seule demande à la fois. Même le compteur de référence du programme me signale qu'il a utilisé zéro ms pour le traitement, mais il y a toujours des limites pour traiter les demandes en une seconde. Maintenant, j'ai traité environ 100 fois par seconde.

Je cherche donc des méthodes plus concurrentes, comme 8 processus pour gérer les 8 requêtes en MÊME TEMPS. Ce sera tellement gentil. Mais il y a un plus gros problème avec le partage de données, je ne veux pas réinventer la roue. J'ai donc vérifié le mongodb, redis et sqlite.

voici mes devoirs, moi si je me trompais, Merci beaucoup

MongoDB et Redis sont vraiment rapides comme ils ont dit, mais ils ont utilisé le même mécanisme, ils peuvent gérer une demande une fois, ce n'est pas ce que Je cherche. Donc le sqlite est à peu près plus proche, plusieurs processus peuvent ouvrir le même fichier db en même temps et lire, la douleur est son verrou en écriture (je ne sais pas combien le nouveau verrou de sqlite3 fonctionne).

Voici ma question, y a-t-il une solution solide et bonne pour ce scénario? Si je sépare le processus d'écriture en un, cela aiderait-il?

merci pour tout commentaire

Answer 1

La solution avec MongoDB est sharding. MongoDB sharding permet essentiellement de lancer plus de processeurs sur le problème. Plus de processeurs = plus de threads d'écriture.

Chaque instance de MongoDB n'a qu'un seul thread d'écriture. Sharding donne plus d'instances et permet donc plus d'écritures.

Cependant, il y a un plus gros problème ici. Débit de disque.

J'ai vu Mongo courir plus de 1000 insertions/sec si le tout est en RAM. Mais la plupart des gens utilisent Mongo comme une base de données avec un support de fichier réel. Donc, si vous utilisez Mongo pour des écritures très lourdes, vous devez être préparé avec des disques qui peuvent accepter ce niveau de débit.

Encore une fois, le problème du débit de disque est le sharding. Construire plus de fragments et vous obtiendrez moins d'écritures/disque et essentiellement moins de verrouillage tout autour.