Compte tenu de ces attentes, quel langage ou quel système choisiriez-vous pour mettre en œuvre la solution? [fermé]

Question

Voici les estimations que le système doit gérer:

• 3000 utilisateurs finaux
• 150+ bureaux dans le monde
• Plus de 1500 utilisateurs simultanés aux heures de pointe
• 10 000+ mises à jour quotidiennes
• 4-5 commits par seconde
• 50-70 transactions par seconde (lectures / recherches / mises à jour)

Ce sera une application interne uniquement destinée aux entreprises, dédiée à la gestion des expéditions dans le monde entier pour les entreprises de transport.

Quel serait votre choix technologique, pourquoi ce choix et environ combien de temps faudrait-il pour le mettre en œuvre? Merci.

Remarque: je ne recrute pas. : -)

Answer 1

Alors, vous avez demandé comment je pourrais aborder un tel projet. Dans le monde Smalltalk, les gens semblent s'accorder pour dire que Gemstone permet aux choses de s'échelonner de manière magique.

Alors, voici ce que je ferais réellement: je commencerais par développer une image Squeak simple, en utilisant SandstoneDB . Ensuite, ce moment viendrait où une seule image commence à être trop lente.

GemStone se charge ensuite de copier vos objets publics (visibles depuis une racine donnée). ) aller-retour entre toutes les instances. Vous obtenez des sessions et des fonctionnalités de requête améliorées, ainsi qu'une machine virtuelle assez rapide.

Il partage des données avec C, Java et Ruby.

En fait, ils ont leur propre VM pour Ruby , qui vaut également le détour.

Answer 2

wikipedia gère beaucoup plus d’exigences avec MySQL

Answer 3

Vos volumes sont importants mais ne risquent pas de mettre à rude épreuve un SGBDR crédible si est programmé efficacement. Si votre équipe est bâclée (c'est-à-dire que vous placez des requêtes SQL directement dans des composants qui sont ensuite composés en composants plus volumineux), vous risquez un "multiplicateur". effet où une exigence logique (obtenir les données nécessaires pour cette page) se transforme en un grand nombre de requêtes de base de données physiques.

Ainsi, plutôt que de vous concentrer sur la capacité de votre SGBDR, vous devriez vous concentrer sur la capacité de vos programmeurs et sur la mesure dans laquelle votre langage de mise en œuvre et votre environnement facilitent le profilage et la refactorisation.

Le scénario que vous proposez est clairement un scénario 24 heures sur 24, 7 jours sur 7, 365 jours par an. Vous devez donc également prendre en compte la nécessité d’une surveillance / d’un tableau de bord.

Il n’existe aucun moyen d’estimer l’effort de développement en fonction des besoins que vous avez présentés; Il est bon que vous ayez analysé vos transactions à ce niveau de granularité, mais le principal facteur déterminant de l'effort de développement sera le domaine et les exigences de l'interface utilisateur.

Answer 4

Choisissez la technologie que vos développeurs connaissent et connaissent bien. Toutes les technologies majeures répondent aisément à ces exigences.

Answer 5

Vos numéros de mises à jour quotidiennes par rapport aux commits ne s’additionnent pas. Quatre commits par seconde = 14 400 par heure.

Vous n'avez rien dit à propos de la taille de base de données attendue.

Dans tous les cas, je concentrerais mes efforts sur le choix d’un back-end robuste tel que Oracle, Sybase, MS, etc. Ce choix fera toute la différence en termes de performances. Le front-end peut être une application de bureau ou une application WEB selon les besoins. Étant donné que cette solution sera utilisée dans de nombreux bureaux du monde entier, une application Web peut sembler la plus sensée.

Answer 6

Je choisirais MySQL ou PostgreSQL. Peu susceptible d’avoir des problèmes avec l’un ou l’autre pour vos besoins.

Answer 7

J'aime les bases de données d'objets. En termes de commits par seconde et de base de données aller-retour, aucune base de données relationnelle ne peut résister. Découvrez db4o . C'est facile à apprendre, regardez les exemples!

En ce qui concerne le langage de programmation et le cadre d’interface utilisateur: tenez compte des qualités de votre équipe. Les langues dynamiques avec moins de perte de méta-temps gagneront probablement du temps.

Answer 8

Les informations fournies ici ne sont pas suffisantes pour vous permettre de faire une recommandation appropriée. Un peu plus de diligence raisonnable est de mise.

• À quoi ressemble la culture informatique? Préfèrent-ils beaucoup de petits serveurs ou moins de gros serveurs ou de gros serveurs? Quelle est leur position sur la virtualisation?
• À quoi ressemble la culture d'entreprise? Quel est le climat politique? Les offres open source peuvent très bien gérer la charge, mais vous devrez peut-être faire appel à un fournisseur propriétaire simplement parce qu'elles sont déjà habituées à naviguer dans les vents politiques d'une grande entreprise. La perception est importante.
• Quel est le niveau de maturité de l'organisation? Ont-ils déjà une équipe Architecture d'entreprise en place? Savent-ils même ce qu'est EA?
• Vous avez décrit le côté opérationnel, mais qu'en est-il du côté analytique? Quelle technologie OLAP s’attendent-ils à utiliser ou ont-ils déjà en place?
• En ce qui concerne l'intégration, quels autres systèmes devrez-vous intégrer?