Date queste aspettative, quale lingua o sistema sceglieresti di implementare la soluzione? [chiuso]

Question

Ecco le stime che il sistema dovrebbe gestire:

• 3000+ utenti finali
• 150+ uffici in tutto il mondo
• 1500+ utenti simultanei nelle ore di punta
• 10.000+ aggiornamenti giornalieri
• 4-5 commit al secondo
• 50-70 transazioni al secondo (letture / ricerche / aggiornamenti)

Questa sarà solo un'applicazione aziendale interna, dedicata ad aiutare la compagnia di spedizioni nella gestione delle spedizioni in tutto il mondo.

Quale sarebbe la tua scelta tecnologica, perché quella scelta e all'incirca quanto tempo ci vorrebbe per implementarla? Grazie.

Nota: non sto reclutando. : -)

Answer 1

Quindi, mi hai chiesto come avrei affrontato un simile progetto. Nel mondo Smalltalk, le persone sembrano concordare sul fatto che la pietra preziosa riduca le cose in qualche modo magicamente.

Quindi, quello che farei davvero è questo: inizierei a sviluppare in una semplice immagine Squeak, usando SandstoneDB . Quindi, arriverebbe questo momento in cui una singola immagine inizia a essere troppo lenta.

GemStone si occupa quindi di copiare i tuoi oggetti pubblici (quelli visibili da una determinata radice ) avanti e indietro tra tutti i casi. Ottieni sessioni e funzionalità di query avanzate, oltre a una VM abbastanza veloce.

Condivide i dati con C, Java e Ruby.

In realtà, hanno la loro VM for ruby ??, che vale anche la pena dare un'occhiata.

Answer 2

wikipedia gestisce requisiti molto più impegnativi con MySQL

Answer 3

I tuoi volumi sono significativi ma non rischiano di mettere a dura prova RDBMS se programmati in modo efficiente. Se il tuo team è sciatto (cioè, casualmente inserendo query SQL direttamente in componenti che sono poi composti in componenti più grandi), affronti la probabilità di un "moltiplicatore"; effetto in cui un requisito logico (ottenere i dati necessari per questa pagina) si trasforma in un numero elevato di query fisiche sul database.

Quindi, piuttosto che concentrarti sulla capacità del tuo RDBMS, dovresti concentrarti sulla capacità dei tuoi programmatori e sul grado in cui il linguaggio e l'ambiente di implementazione facilitano la profilazione e il refactoring.

Anche lo scenario che proponi è chiaramente 24x7x365, quindi dovresti anche considerare la necessità di requisiti di monitoraggio / dashboard.

Non c'è modo di stimare lo sforzo di sviluppo in base alle esigenze che hai presentato; è fantastico che tu abbia analizzato le tue transazioni a questo livello di granularità, ma il principale fattore determinante dello sforzo di sviluppo saranno i requisiti del dominio e dell'interfaccia utente.

Answer 4

Scegli la tecnologia che i tuoi sviluppatori conoscono e hanno familiarità. Tutte le principali tecnologie disponibili gestiranno tali requisiti con facilità.

Answer 5

I tuoi numeri di aggiornamento giornaliero vs commit non si sommano. Quattro commit al secondo = 14.400 all'ora.

Non hai menzionato nulla sulla dimensione del database prevista.

In ogni caso, concentrerei i miei sforzi sulla scelta di un back-end robusto come Oracle, Sybase, MS ecc. Questa scelta farà la differenza in termini di prestazioni. Il front-end può essere un'app desktop o un'app WEB a seconda delle esigenze. Poiché questo verrà utilizzato in molti uffici in tutto il mondo, un'app WEB potrebbe avere più senso.

Answer 6

Andrei con MySQL o PostgreSQL. È probabile che non si verifichino problemi con nessuno dei due per le tue esigenze.

Answer 7

Adoro database di oggetti. In termini di commit al secondo e andata e ritorno del database, nessun database relazionale può reggere. Dai un'occhiata a db4o . È facile da imparare, guarda gli esempi!

Per quanto riguarda il linguaggio di programmazione e il framework dell'interfaccia utente: bene, prendi ciò in cui il tuo team è bravo. Le lingue dinamiche con meno sprechi di meta-tempo probabilmente faranno risparmiare tempo.

Answer 8

Non ci sono abbastanza informazioni fornite qui per dare una raccomandazione adeguata. È necessario un po 'più di diligenza.

• Com'è la cultura IT? Preferiscono un sacco di piccoli server o meno server più grandi o ferro grosso? Qual è la loro posizione sulla virtualizzazione?
• Com'è la cultura aziendale? Com'è il clima politico? Le offerte open source potrebbero benissimo gestire il carico, ma potrebbe essere necessario rivolgersi a un fornitore proprietario solo perché sono già abituati a navigare nei venti politici di una grande azienda. La percezione è importante.
• Qual è il livello di maturità dell'organizzazione? Hanno già un Enterprise Architecture team a posto? Sanno addirittura cos'è EA?
• Hai descritto il lato operativo ma per quanto riguarda il lato analitico? Quale tecnologia OLAP si aspettano di utilizzare o sono già in atto?
• A proposito di integrazione, con quali altri sistemi dovrai integrarti?