C'est une très bonne idée de séparer vos données à différents magasins de données, chacun avec ses avantages.
Par exemple:
- vous pouvez mettre dans votre blob SGBDR (comme MySQL), mais il est préférable d'avoir un stockage Amazon S3.
- Vous pouvez placer des documents texte dans votre SGBDR et les interroger avec "... LIKE% QUERY% ...", mais il est préférable de les placer dans Elastic Search ou Amazon CloudSearch.
- Vous pouvez mettre vos données de gestion de session dans votre SGBDR, mais il est préférable d'avoir en Amazon Elastic Cache ou DynamoDB
- Vous pouvez avoir vos tables de recherche dans SGBDR, mais il est préférable d'avoir en mémoire ou de la mémoire à base NoSQL (comme Memecached ou Redis) ou DynamoDB
Et vous pouvez écrire les instructions ci-dessus différemment, en stockant tout dans MongoDB ou DynamoDB, mais en préférant les mettre ailleurs. Lorsque vous placez vos données dans différents magasins, vous pouvez obtenir un système plus simple, distribué, évolutif et généralement plus rapide en fonction de la simplicité de ce magasin de données lié au type de données et à votre utilisation de ces données. L'inconvénient est que vous devez synchroniser vos données entre les magasins de données. Une fois que vous avez ajouté un enregistrement à votre DynamoDB, vous devez télécharger le BLOB sur S3, mettre à jour le document dans CloudSearch et ajouter l'enregistrement à votre MySQL, ainsi qu'écrire les lignes pertinentes dans votre fichier journal pour une analyse ultérieure. C'est, bien sûr, le cas extrême d'avoir des données et des requêtes aussi complexes. Habituellement, vous n'avez besoin de mélanger que 2 ou 3 magasins de données.
Si vous devez avoir des transactions dans votre système, il sera beaucoup plus difficile de synchroniser vos données, et il est préférable d'avoir toutes vos données dans un magasin de données qui supporte les transactions. Mais même dans ce cas, vous pouvez limiter vos exigences de transaction à une partie de vos données et vivre avec des données redondantes dans d'autres magasins de données. Par exemple, avoir des objets S3 orphelins qui n'ont aucun enregistrement de référence dans votre SGBDR ou DynamoDB, n'est généralement pas un gros problème.
En ce qui concerne le code PHP (ou autre langage de programmation) que vous écrivez pour manipuler les données distribuées, cela dépend également. Si vous avez besoin d'une fonctionnalité complexe JOIN, GROUP_BY, FILTER supportée nativement par le magasin de données, il est préférable d'utiliser la fonctionnalité DB. Mais souvent, votre code peut être assez simple à écrire, comme interroger le bon DB (par exemple, la recherche textuelle vers CloudSearch) et assembler les données à partir de vos différents magasins de données.