Qu'est-ce qui est plus rapide, des fichiers plats ou une base de données MySQL RAM?

Question

J'ai besoin d'un moyen simple pour plusieurs scripts PHP en cours d'exécution de partager des données.

Devrais-je créer une base de données MySQL avec un moteur de stockage RAM et partager des données via celui-ci (plusieurs scripts peuvent-ils se connecter simultanément à la même base de données?)

Ou les fichiers plats avec une donnée par ligne seraient-ils meilleurs?

Answer 1

Fichiers plats? Nooooooo ...

Utilisez un bon moteur de base de données (MySQL, SQLite, etc.). Ensuite, pour optimiser les performances, utilisez memcached to cache contenu.

---

De cette manière, vous pouvez facilement et en toute fiabilité partager des données entre des processus à l’aide d’un logiciel serveur éprouvé qui gère la concurrence, etc. Mais vous bénéficiez de la vitesse de mise en cache de vos données.

Gardez à l’esprit quelques points:

1. MySQL a un cache de requêtes. Si vous lancez plusieurs fois les mêmes requêtes, vous pouvez gagner beaucoup en performances sans ajouter de couche de mise en cache.
2. MySQL est très rapide quand même. Avez-vous testé la charge pour démontrer que cela n’est pas assez rapide?

Answer 2

N'utilisez pas de fichiers plats, pour la santé des responsables.

Si vous souhaitez uniquement partager des données le plus rapidement possible et que vous puissiez tout conserver en RAM, alors memcached est la solution idéale.

Si vous souhaitez la persistance des données, utilisez un SGBD tel que MySQL.

Answer 3

En règle générale, une base de données est préférable. Toutefois, si vous partagez une petite quantité de données, essentiellement statique, il peut présenter des avantages en termes de performances (et de simplicité) par rapport aux fichiers plats.

N'importe quoi d'autre que le partage de données trivial et je choisirais un DB cependant.

Answer 4

1- Où le fichier plat peut être utile: Un fichier plat peut être plus rapide qu'une base de données, mais dans des applications très spécifiques. Ils sont plus rapides si les données sont lues du début à la fin, sans recherche ni écriture. Si les données ne tiennent pas dans la mémoire et doivent être lues intégralement pour que le travail soit effectué, cela peut être plus rapide qu'une base de données. De même, s'il y a beaucoup plus d'écriture que de lecture, le fichier plat brille également, la plupart des configurations de bases de données par défaut devront faire en sorte que les requêtes de lecture attendent la fin de l'écriture afin de conserver les index et les clés étrangères. Rendre les requêtes d'écriture généralement plus lentes que les lectures simples.

TD / LR vesion: Utilisez des fichiers plats pour le système basé sur les tâches (Aka, analyse simple des journaux), et non pour les requêtes de recherche Web.

2- Fosse de limage à plat:   Si vous utilisez un fichier plat, vous devrez synchroniser vos scripts lorsque le fichier sera modifié à l'aide du mécanisme de verrouillage personnalisé. Ce qui peut entraîner un ralentissement, une corruption allant jusqu'à un blocage total si vous avez un bogue.

3- Base de données basée sur un bélier? La plupart des bases de données ont dans la mémoire cache pour les résultats des requêtes, des index de recherche, ce qui les rend très difficiles à battre avec un fichier plat. Parce qu'ils cachent en mémoire, le faire fonctionner entièrement à partir de la mémoire est la plupart du temps inefficace et dangereux. Mieux vaut ajuster correctement la configuration de la base de données.

Si vous souhaitez optimiser les performances à l'aide de la RAM, je commencerai par exécuter vos scripts PHP, vos pages HTML et les petites images d'un lecteur RAM. Où le mécanisme de cache est plus susceptible d'être brut et de frapper systématiquement le disque dur pour ne pas modifier les données statiques.

Un meilleur résultat peut être atteint avec un équilibreur de charge, la mise en cluster avec des connexions dans le fond de panier jusqu’à la matrice SAN en RAM. Mais c’est un tout autre sujet.

5- Plusieurs scripts peuvent-ils se connecter simultanément au même DB?

Oui, son regroupement de connexions est appelé. En php (côté client), sa fonction permet d’ouvrir une connexion via son mysql-pconnect ( http://php.net/manual/en/function.mysql-pconnect.php ). Vous pouvez configurer la connexion ouverte maximale dans php.ini je pense. Un paramètre similaire côté serveur mysql définit le maximum de connexions client simultanées dans /etc/mysql/my.cnf.

Vous devez le faire pour tirer parti du traitement parallèle du processeur et éviter que le script php n'attende la fin de la requête. Il augmente considérablement les performances sous forte charge.

Il existe également un pool de connexions / threads dans la configuration Apache pour les clients Web standard. Voir httpd.conf.

Désolé pour le mur de texte, je me suis ennuyé. Louis.

Answer 5

Si vous les exécutez sur plusieurs serveurs, une approche basée sur un système de fichiers ne la coupera pas (sauf si vous avez un système de fichiers partagé cohérent, ce qui est peu probable et peut ne pas être évolutif).

Par conséquent, vous aurez quand même besoin d’une base de données sur serveur pour permettre le partage de données entre serveurs Web. Si vous êtes soucieux des performances ou de la disponibilité, votre application prendra en charge plusieurs serveurs Web.

Answer 6

Je dirais que la base de données MySql serait un meilleur choix, sauf si vous avez un mécanisme en place pour traiter les verrous sur les fichiers plats (et un moyen de contrôler l'accès). Dans ce cas, la couche de base de données (quel que soit le système de gestion de base de données utilisé) agit comme une couche indirectionnelle, ce qui vous permet de ne pas vous en inquiéter.

Etant donné que l'OP ne spécifie pas de serveur Web (et que PHP peut être exécuté à partir d'une ligne de commande), je ne suis pas sûr que les technologies de mise en cache correspondent à leurs objectifs. Le PO pourrait envisager de transformer des données volantes qui ne sont pas pilotées par un site Web. Qui sait.

Answer 7

Si votre système dispose d'un cache PHP (qui cache le code PHP compilé en mémoire, comme APC), essayez de placer vos données dans un fichier PHP, en tant que code PHP. Si vous devez écrire des données, il y a des problèmes de sécurité.

Answer 8

  

J'ai besoin d'un moyen simple pour plusieurs   exécuter des scripts PHP pour partager des données.

APC et memcached sont deux bonnes options en fonction du contexte. La mémoire partagée peut également être une option.

  

Dois-je créer une base de données MySQL avec une RAM?   moteur de stockage et partager des données via   que (plusieurs scripts peuvent se connecter à   le même DB simultanément?)

C’est aussi une option décente, mais ne sera probablement pas aussi rapide que APC ou memcached.

  

Ou les fichiers à plat avec un morceau de   les données par ligne sont-elles meilleures?

S'il s'agit de données en lecture seule, c'est une possibilité - mais peut être plus lente que l'une des options ci-dessus. Surtout si les données sont volumineuses. Plutôt que d’écrire du code d’analyse personnalisé, envisagez simplement de construire un tableau PHP et incluez () le fichier.

S'il s'agit d'un magasin de données auquel plusieurs auteurs peuvent accéder simultanément, n'utilisez PAS de fichier à plat! L'écriture dans un fichier plat à partir de plusieurs processus est susceptible d'entraîner une corruption de fichier. Vous pouvez verrouiller le fichier, mais vous risquez des problèmes de conflit de verrouillage et des temps d’attente de verrouillage longs.

Le traitement des écritures simultanées est la raison pour laquelle des applications telles que mysql et memcached existent.