J'ai besoin d'un moyen simple de passer des scripts PHP multiples pour partager des données.
devrais-je créer un dB mysql avec un moteur de stockage RAM et partager des données via cela (les scripts multiples peuvent se connecter à la même dB simultanément?)
ou les fichiers plats avec une seule pièce de données par ligne sont mieux?
8 Réponses :
Fichiers plats? NOOOOOOOO ...
Utilisez un bon moteur DB (mySQL, SQLite, etc.). Ensuite, pour une performance maximale, utilisez Memcached vers Cache Contenu.
Gardez à l'esprit quelques choses:
De cette manière, vous avez la facilité et la fiabilité du partage des données entre les processus utilisant un logiciel serveur éprouvé qui gère la concurrence, etc ... mais vous obtenez la vitesse de la mise en cache de données.
Veuillez ne pas utiliser de fichiers plats, pour la santé mentale des mainteneurs.
Si vous cherchez simplement à avoir des données partagées, aussi vite que possible, et que vous pouvez le tenir dans la RAM, puis MEMCACHED est la solution parfaite.
Si vous souhaitez une persistance des données, utilisez un SGBD, comme MySQL.
J'ai trouvé cette question via Google parce que je suis l'un de ces responsables devant résoudre les problèmes dans un hybride PHP & MySQL + Flatfile. C'est un cauchemar. Si Il y a eu un gain de performance à l'aide de Flatfiles, il a été plus que consommé par le coût d'avoir à réparer et à maintenir ce système de flûtiers kludgy. +1 pour penser à la gentillestiers Sanity!
Je dirais que le DB MySQL serait meilleur choix que si vous avez un mécanisme en place pour faire face aux serrures sur les fichiers plats (et un moyen de contrôler l'accès). Dans ce cas, la couche de DB (indépendamment de la SGBD spécifique) agit comme une couche indirecte, vous permettant de ne pas m'inquiéter pour cela.
Étant donné que l'OP ne spécifie pas un serveur Web (et PHP peut réellement fonctionner à partir d'une ligne de commande), je ne suis pas certain que les technologies de mise en cache sont ce qu'elles sont ensuite ici. L'OP pourrait envisager de faire une sorte de transformation de données volante qui n'est pas pilotée par le site Web. Qui sait.
Eh bien, et une couche de RAM ne vise que la RAM, les fichiers plats parlent toujours à un sous-système de disque. Sauf si vous avez toujours un lecteur de RAM (de DOS Days), ce qui serait la même chose, il suffit d'aucune sémantique de verrouillage. Owww. Ma tête fait mal maintenant.
En règle générale, une dB est meilleure, cependant, si vous partagez une petite quantité statique de données, il pourrait y avoir des avantages de performance (et une simplicité) de le faire avec des fichiers plats.
autre chose que le partage de données trivial et je choisirais un dB cependant.
Si votre système dispose d'un cache PHP (que CACHES compilait le code PHP en mémoire, comme APC), essayez de mettre vos données dans un fichier PHP, en tant que code PHP. Si vous devez écrire des données, il existe des problèmes de sécurité.
Si vous les exécutez sur plusieurs serveurs, une approche basée sur un système de fichiers ne le coupera pas (sauf si vous n'avez qu'un système de fichiers partagé cohérent, qui est peu probable et qui peut ne pas être évolutif).
Par conséquent, vous aurez besoin d'une base de données serveur de temps en temps pour permettre le partage de données entre serveurs Web. Si vous êtes sérieux sur la performance ou la disponibilité, votre application prendra en charge plusieurs serveurs Web.
J'ai besoin d'un moyen simple pour plusieurs Exécution de scripts PHP pour partager des données.
APC et memcached sont de bonnes options selon le contexte. Mémoire partagée peut également être une option.
devrais-je créer un dB mysql avec un bélier moteur de stockage et partager des données via que (les scripts multiples peuvent-ils 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 plats avec un morceau de Les données par ligne sont 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 grandes. Plutôt que d'écrire un code personnalisé, vous envisagez de construire simplement un tableau PHP et inclure () le fichier.
S'il s'agit d'un magasin de données accessible par plusieurs écrivains simultanément, par tous les moyens n'utilise 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 de verrouiller les problèmes de contention et des temps d'attente de verrouillage longs.
Gestion simultanée écrit est la raison pour laquelle des applications telles que MySQL et Memcaches existent.
1- Où le fichier plat peut être utile: Le 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 de la recherche ou de l'écriture. Si les données ne correspondent pas à la mémoire et doivent être prononcées pleinement pour obtenir le travail effectué, il "peut" être plus rapide qu'une base de données. De plus, s'il y a beaucoup plus d'écriture que de lectures de fichiers plats aussi brillez, la plupart des configurations de bases de données par défaut devront apporter les requêtes de lecture attendre que l'écriture soit terminée dans l'ordre entretenir des index et des clés étrangères. Faire des requêtes d'écriture habituellement plus lentes que de simples lectures.
TD / LR Vesion: Utilisez des fichiers plats pour le système basé sur les travaux (AKA, analyse des journaux simples), pas pour les recherches sur le Web.
Fichiers à 2 plats Falls Falls: Si vous allez avec un fichier plat, vous devrez synchroniser vos scripts lorsque le fichier change en utilisant le mécanisme de verrouillage personnalisé. Qui peut conduire à ralentissement, à la corruption jusqu'au verrouillage mort si vous avez un bogue.
base de données basée sur la RAM? La plupart des bases de données ont dans le cache de mémoire pour les résultats de la requête, les index de recherche, les rendant très difficiles à battre avec un fichier plat. Parce qu'ils cachent en mémoire, le rendant entièrement exécuté à partir de la mémoire est la plupart du temps inefficace et dangereux. Mieux vaut corriger la configuration de la base de données.
Si vous souhaitez optimiser les performances à l'aide de la RAM, je consulterais d'abord l'exécution de vos balayages PHP, de vos pages HTML et de petites images d'un lecteur de RAM. Lorsque le mécanisme de cache est plus susceptible d'être brut et de toucher systématiquement le disque dur pour des données statiques non modifiées.
Meilleur résultat peut être atteint avec un équilibreur de charge, en regroupement avec des connexions en plan d'arrière jusqu'à la matrice SAN basée sur la RAM. Mais c'est un autre sujet.
5- Les scripts multiples peuvent-ils se connecter à la même dB simultanément?
Oui, sa mise en commun de connexion appelée. Dans PHP (côté client), c'est la fonction d'ouvrir une connexion son mysql-pconnect ( http://php.net/manual/fr/function.mysql-pconnect.php ). Vous pouvez configurer la connexion ouverte maximale dans PHP.ini, je pense. Un paramètre similaire sur MySQL Server Côté Définissez le maximum de connexions client simultanées dans /etc/mysql/my.cnf.
Vous devez faire cela afin de tirer parti de la transformation parrallelle de la CPU et d'éviter le script PHP d'attendre la requête de l'autre. Il augmente considérablement la performance sous une charge importante.
Il y a aussi une piscine de connexion / piscine de filetage dans la configuration Apache pour les clients Web réguliers. Voir httpd.conf.
Désolé pour le mur de texte, s'ennuyait. Louis.