Nous construisons un système qui devra servir de nombreuses petites demandes du premier jour. Par "charges", je veux dire environ 5 000 requêtes par seconde. Pour chaque requête, nous devons récupérer ~ 20 enregistrements de la base de données NOSQL. Il y aura deux lectures de lots - 3-4 enregistrements au début, puis 16-17 se lit instantanément après cela (sur la base du résultat de la première lecture). Ce serait ~ 100 000 objets à lire par seconde.
Jusqu'à présent, nous pensions à utiliser Dynamodb pour cela car il est vraiment facile de commencer.
Le stockage n'est pas quelque chose que je serais inquiet que les objets seront vraiment minuscules. Ce que je suis inquiet, c'est le coût des lectures. DynamoDB coûte 0,0113 $ par heure pour 100 ans éventuellement cohérents (qui conviennent à nous) se lit par seconde. C'est 11,3 $ par heure pour que tous les objets atteignent tous les objets de 1kb. Et ce serait 5424 $ par mois sur la base de 16 heures / jour d'utilisation moyenne.
Alors ... Je considérerais d'autres options mais je suis inquiet pour les problèmes de maintenance, les coûts, etc. Je n'ai jamais travaillé avec de telles configurations avant que votre conseil serait vraiment précieux.
Quelle serait la solution la plus rentable (mais toujours sans tracas) pour une application intensive de lecture / écriture?
3 Réponses :
par "charges", je veux dire ~ 5 000 requêtes par seconde.
ah ce n'est pas tellement, même SQL peut gérer cela. Donc, vous êtes déjà facilement dans les limites de ce que la plupart des DBS modernes peuvent gérer. Cependant, ils ne peuvent que gérer cela avec la droite:
- index
- Queries
- Matériel de serveur
- La scission de grandes données (vous pourriez avoir besoin d'une grande quantité de fragments avec des données relativement bas, dépendant ici ici, donc j'ai dit "pourrait")
Ce serait ~ 100 000 objets à lire par seconde.
Maintenant, c'est plus d'un scénario de charge élevé. Dois-tu lire ceux-ci de manière aussi fragmentée? Si oui, alors (comme je l'ai dit), vous pouvez avoir besoin d'envisager de répandre la charge sur des éclats répliqués.
Le stockage n'est pas quelque chose que je serais inquiet lorsque les objets seront vraiment minuscules.
Mongo est agressif avec l'allocation de disque de sorte que même avec de petits objets, il préalcule encore beaucoup d'espace, c'est quelque chose à nu.
SO ... 5424 $ par mois.
OH YEA Les frissons de facturation d'Amazon
: \ .Je considérerais d'autres options mais je suis inquiet pour les problèmes de maintenance, les coûts, etc. Je n'ai jamais travaillé avec de telles configurations avant que votre conseil serait vraiment précieux.
Maintenant, vous frappez tout cela. Vous pouvez configurer votre propre cluster, mais vous pourriez alors vous remettre en paie beaucoup d'argent et de temps (ou beaucoup plus) pour les serveurs, les personnes, les administrateurs et votre propre temps de contentieux. C'est une raison pour laquelle DynamoDB brille vraiment ici. Pour les grandes configurations qui cherchent à prendre la charge et la douleur et le stress de la gestion du serveur (croyez-moi, c'est vraiment douloureux, si votre device vous permet de modifier également votre titre de poste sur le serveur Admin à partir de la société. < / p>
Considérant à configurer cela vous-même, vous auriez besoin de:
- une quantité considérable d'instances de la CE (dépendant de la taille des données et de la taille de l'index, mais je dirais que peut-être peut-être 30?)
- un administrateur de serveur (peut-être 2, peut-être freelance?)
Les deux pourraient vous remettre 100 de milliers de livres par an, je parierais personnellement à l'approche gérée si cela correspond à vos besoins et à vos budgets. Lorsque vos besoins augmentent au-delà de ce qui gérait Amazon DB peut vous donner, puis passer à votre infrastructure.
Edit
Je devrais modifier que la rentabilité a été réalisée avec des trous noirs tout à fait par exemple:
- Je ne suis pas sûr de la quantité de données que vous avez
- Je suis incertain d'écrit
Ces deux contribuent à placer un scénario de:
- massive écrit (à peu près autant que votre lecture)
- Données massives (lots)
Dans votre description ci-dessus, je suppose que vos 5 000 questions par seconde sont entièrement des opérations de lecture. C'est essentiellement ce que nous appelions un cas d'utilisation de l'entrepôt de données. Quelles sont vos exigences de disponibilité? Cela doit-il être hébergé sur AWS et amis, ou pouvez-vous acheter votre propre matériel à courir en interne? À quoi ressemble vos données? À quoi ressemble la logique qui consomme ces données?
Vous pourriez avoir le sens où il n'y a pas vraiment assez d'informations ici pour répondre à la question définitivement, mais je peux au moins offrir des conseils.
Premièrement, si vos données sont relativement petites et que vos requêtes sont simples, épargnez-vous des tracas et assurez-vous que vous interrogez de la RAM au lieu du disque. Tout SGDBM moderne avec support pour la mise en cache / tables de mémoire en mémoire fera le tour. Postgres et MySQL ont les deux caractéristiques pour cela. Dans le cas des Postgres, assurez-vous d'avoir identifié les paramètres de la mémoire de manière appropriée car la configuration hors de la case est conçue pour fonctionner sur un matériel assez maigre. Si vous devez utiliser une option NOSQL, en fonction de la structure de vos données REDIS est probablement un bon choix (c'est aussi principalement en mémoire). Cependant, afin de dire quelle saveur de NOSQL pourrait être la meilleure solution que nous devrions en savoir plus sur la structure des données que vous interrogez et quelles requêtes vous utilisez.
Si les requêtes font bouillir vers J'ai découvert cela pour un projet récent, alors je suis passé à Rackspace. La performance a considérablement augmenté là-bas, mais j'ai remarqué que je payais beaucoup pour les ressources de la CPU et de la RAM quand j'ai vraiment besoin de faire des E / S rapides. Maintenant j'hôte avec l'océan Digital. Tous les stockages sont SSD. Leur performance de la CPU est une sorte de merde par rapport aux autres offres, mais je suis incroyablement I / O lié, donc je m'en fiche. Après avoir laissé tomber les postgres ' morale de l'histoire: profil, mélodie, répéter. Demandez-vous quoi-si des questions et validez constamment vos hypothèses.
Sélectionnez * à partir de la table où primaire_key = {constante} - Ne vous dérangeez pas de jouer avec NOSQL - utilisez simplement un SGBM et apprenez à régler la chose de DANS. Ceci est doublement vrai si vous pouvez l'exécuter sur votre propre matériel. Si le nombre de connexion est élevé, utilisez des esclaves de lecture pour équilibrer la charge.
aléatoire_page_cost à 2, je fredonne assez bien.
Je pensais que tout le point de Nosql est pour ce genre de choses ...?
C'est un peu plus complexe que ça, j'ai peur. Il suffit de dire que si vous avez besoin de stockage de données à usage général, vous devez utiliser une base de données SQL. NOSQL n'augment généralement que lorsque vous savez que vous ne voulez jamais interroger vos données de manière très spécifique, et lorsque vous avez un type de charge très spécifique qui est à la fois difficile à édifier un RDBM traditionnel à, et qu'une solution de NOSQL particulière est très bien adaptée à. Ce n'est pas un scénario très courant, alors j'ai tendance à vous conseiller contre NOSQL pendant les premiers stades du projet. 5k QPS n'est tout simplement pas une charge de lecture très lourde pour les SGBDM modernes.
Intéressant. Je suis juste une sorte de confusion pourquoi j'ai été égaré. J'utilise Nosql pour tout ce qui est non relationnel ...
Je ne serais pas trop raccroché dessus. La bonne solution est presque toujours celle qui résout votre problème aujourd'hui.
Voici ce que je recommande en séquence.
Identifiez votre cas d'utilisation et choisissez le dB correct. Nous testons régulièrement MySQL et MongoDB pour toutes sortes de charges de travail (OLTP, Analytics, etc.). Dans tous les cas, nous avons testé avec, MySQL surperforms Mongodb et est moins cher ($ / TP) par rapport à MongoDB. MongoDB a d'autres avantages mais c'est une autre histoire ... puisque nous parlons de performance ici.
Essayez de mettre en cache vos requêtes dans la RAM (en provisionnant une RAM adéquate).
Si vous êtes au mec de la bouteille sur la RAM, vous pouvez essayer une solution de mise en cache SSD qui profite du SSD éphémère. Cela fonctionne si votre charge de travail est cache conviviale. Vous pouvez enregistrer des charges d'argent en tant que SSD éphémère ne sont généralement pas chargés par le fournisseur de cloud.
Essayez PIOPS / RAID ou une combinaison pour créer des iops adéquats pour votre application.
Doit-il être nosql? Est-ce que c'est 100%? Je parie que vous pouvez probablement le faire avec une configuration postgroxie bien adaptée à l'aide de quelques esclaves de lecture.
Plus important encore, il doit être moins schématique. Sinon, il y aurait beaucoup de jointures SQL, de nombreuses tables de plusieurs à plusieurs, etc. Nous pourrions envisager de stocker simplement des enregistrements dans une table qui aurait des idées d'identité et de données et de stocker des objets JSON sous données, mais vous pensez vraiment que cela pourrait Soyez une solution plus rapide et plus rentable? Et nous rencontrions d'autres problèmes, par exemple. Pour mettre à jour chaque enregistrement, nous devrions d'abord la lire, puis modifier la chaîne complète, puis l'écrire. Au lieu de dire au moteur de base de données de mettre à jour le disque X avec une nouvelle valeur pour Y (mises à jour incrémentielles atomiques, Jouer Nice pour nous).
Dans mon expérience, il existe très peu de scénarios où les données doivent réellement être schémas. Il est vrai que les bases de données schématiques sont plus faciles à envelopper votre tête (moins à la conception initiale), mais si vous vous donniez des exemples plus concrets de ce que vous essayez de faire, je parie qu'il y a une structure schématique adaptée à vos données. qui peut utiliser des requêtes indexées hautement optimisées.
En d'autres termes, il est beaucoup plus efficace de demander de l'aide pour trouver une solution à votre problème réel, au lieu d'aider à la solution que vous avez arrivée à vous-même.
Maintenant que cette question a de l'âge, je serais curieux d'entendre ce que vous avez fini.
Un peu plus de deux ans plus tard, je suis toujours curieux ... :-)
Je commence à avoir un peu curieux, trop op
Salut les gars! Je suis allé avec une solution basée sur MySQL à cette époque, a fonctionné bien (@benburns - vous aviez raison), bien que nous n'ayons jamais atteint une valeur QPS qui est élevée. Le système lui-même n'est plus existant - l'entreprise a échoué :)