8

Sto costruendo un servizio web che sarà sottoposto a un carico ridicolo (da migliaia a decine di migliaia di query al secondo). Il mio normale stack di apache, PHP, memcache e alcuni DB sarà in grado di gestirlo con un buon bilanciamento del carico e molte macchine, ma mi chiedo se ci siano soluzioni migliori.Stack di tecnologia ad alta scalabilità

L'endpoint verrà colpito da un beacon (tramite javascript sul client), leggerò i cookie dell'utente, estrarro alcune piccole informazioni dal DB, lo memorizzerò, eseguirò qualche piccolo calcolo, invierò la risposta e se necessario, scrivere sul DB e invalidare la cache.

E buone scelte tecnologiche e/o raccomandazioni hardware?

risposta

13

Questo non è il tipo di domanda a cui è possibile rispondere qui in qualsiasi altra cosa che non sia un'ampia panoramica. Alcune indicazioni generali:

  • Hardware: le due scelte sono fondamentalmente un sacco di piccole scatole, a buon mercato o meno il numero di caselle più potenti. Le scatole più economiche sono, beh, più economiche ma in genere consumano molta più energia per la stessa CPU o memoria (a seconda di quale sia importante per voi) rispetto alle scatole più grandi. Le persone spesso dimenticano il costo talvolta significativo del consumo di energia;
  • Backend: avete un paio di scelte dalla grande fine della città (Oracle, SQL Server) alla fine commoditzed (MySQL). MySQL è ovviamente più economico e si può andare lontano su MySQL ma non c'è dubbio che Oracle (che conosco meglio di SQL Server) abbia un ottimizzatore migliore, sia più capace e sia più robusto di MySQL. Pagherai comunque per questo;
  • Budget: questo è un fattore di enorme come potrebbe essere la pena pagare per un buon software commerciale piuttosto che pagare i costi di sviluppo per utilizzare il software "libero". Lo sviluppo del software è uno dei costi più costosi di tutti;
  • Scalabilità verticale e orizzontale: la domanda alla quale stai fondamentalmente cercando di rispondere è costruire (scatole più grandi, ecc.) O costruire (ambienti raggruppati). Le soluzioni più scalabili hanno una scalabilità orizzontale quasi lineare, ma nel breve termine la scalabilità verticale può essere più economica.

Per quanto riguarda il normale stack, rimango con esso a meno che tu non abbia un requisito particolare che non hai menzionato che lo proibisce. Dopotutto PHP è una tecnologia collaudata che gestisce circa 4 dei 20 siti più importanti su Internet (Facebook, Wikipedia, Flickr e Yahoo). Se è abbastanza buono per loro, è abbastanza buono per te.

Ancora più importante, lo sai. La tecnologia impara a sapere che gli stack tecnologici di Trump non si verificano in quasi tutti i casi. Fai attenzione alla trappola "green-pasture" dell'ultimo stack tecnologico "hyped-up".

Memcache è buono. L'altra cosa che potresti voler aggiungere al mix è beanstalkd come un processore di coda di lavoro distribuito.

Una domanda importante a cui rispondere è: quanto bene puoi dividere la tua applicazione? Le applicazioni che si prestano facilmente al partizionamento sono molto più semplici da scalare. Quelli che non sono tendono ad essere modificati in qualche modo per renderli più facili da partizionare.

Un buon esempio di questo è una semplice applicazione di sharetrading.È possibile suddividere le informazioni sul mercato in base al codice di inventario (A-C su un server, D-F su un altro e così via). Per molte di queste applicazioni funzionerà bene.

5

http://highscalability.com/ c'è molto da imparare qui, si probabily trovare la risposta.

+1

Il mio obiettivo non è un grande sistema scalabile, solo un semplice stack tecnologico. Ricerca, crawler, ecc. Basta una semplice richiesta, interrogare, rispondere e archiviare Qualsiasi suggerimento per stack tecnologici per il mio scopo? –

+0

Da quello che ho visto, è possibile costruire un sistema scalabile con qualsiasi stack tecnologico. "Da migliaia a dieci- migliaia di query al secondo "è davvero alto, quindi per me è un" grande sistema scalabile ". Ogni stack di tecnologia ha la sua storia di successo. Se vuoi sostenere questo addebito, devi leggere questo sito Web. archivio chiavi/valori come CouchDB invece di un database relazionale) –

0

PHP, memcached + DB in generale si adatta bene ma ci possono essere modi per farlo a costi inferiori, ovvero uno stack in grado di gestire più richieste simultanee per macchina.

Dato il vostro commento qui ...

Il mio obiettivo non è un grande sistema scalabile, è sufficiente un semplice stack tecnologico. Non sto crescendo DB, Ricerca, crawler, ecc. Basta una semplice richiesta, query, risposta e archiviazione. Qualche raccomandazione per stack tecnologici per il mio scopo?

.. suona come la parte DB potrebbe essere risolvibile da S3 di Amazon ([cosa?!?] [1]), assumendo che solo bisogno di individuare gli elementi a chiave. Questo ti darebbe anche Cloudfront per le letture, se non ti dispiace il eventual consistency.

Nel frattempo qualcosa sul lato server che utilizza async IO per gestire le richieste dovrebbe aumentare significativamente il numero di richieste simultanee che ciascuna macchina può gestire. Come un altro poster ha già detto tornado (bret.appspot.com/entry/tornado-web-server) varrebbe la pena dare un'occhiata qui - non ho visto un'API per l'IO asincrono che è più amichevole.

si sarebbe probabilmente ancora bisogno Memcached per mantenere legge veloce, ma si vuole guardare là fuori che il cliente memcached non sta per finire per bloccare il processo del server durante il tentativo di fare richieste simultanee - PHP non avrebbe normalmente questo problema dato che ogni processo PHP (o Apache) ha la propria connessione memcached e fa sempre e solo una cosa alla volta. This python client - dovrebbe supportare l'I/O asincrona: il libmemcached sottostante ha il supporto per le richieste asincrone.

Lo stesso vale per le richieste HTTP dal server a S3 - come gestite le richieste simultanee lì? boto sembra utilizzare un pool di connessioni per questo, ogni connessione con un socket diverso aperto. Uso della memoria?

Disclaimer: Sono un architetto di poltrona qui - non l'ho fatto e il consiglio più intelligente potrebbe finire il progetto in tempo con lo stack che conosci bene e con cui non fallirai.

Mi dispiace per i link

[1] - http://www.nektoon.com/t/1Z99Daaa

1

Si può anche considerare l'utilizzo di BigPipe per incrementare le prestazioni. Anche Facebook lo sta usando in modo massiccio ed ecco cosa dicono al riguardo: "Per sfruttare il parallelismo tra web server e browser, BigPipe rompe le pagine web in più blocchi chiamati pagelets, proprio come un microprocessore che pipeline divide il ciclo di vita di un'istruzione in più fasi (come "istruzione recupero", "istruzione decodifica", "esecuzione", "registrazione scrittura indietro" ecc.), BigPipe interrompe il processo di generazione della pagina in più fasi:

Analisi richiesta: analisi e analisi del server Web Richiesta HTTP Recupero dati: server Web recupera dati dal livello di storage Generazione markup: il server Web genera markup HTML per la risposta. Trasporto di rete: la risposta viene trasferita dal server Web al browser. Download CSS: download del browser CSS richiesto dalla pagina. Costruzione dell'albero DOM e stile CSS: il browser costruisce l'albero DOM del documento e quindi applica le regole CSS su di esso. Download JavaScript: il browser scarica le risorse JavaScript a cui fa riferimento la pagina. Esecuzione JavaScript: il browser esegue il codice JavaScript della pagina.

Le prime tre fasi vengono eseguite dal server Web e le ultime quattro fasi vengono eseguite dal browser. Ogni pagelet deve attraversare tutte queste fasi in sequenza, ma BigPipe consente di eseguire più pagelets simultaneamente in fasi diverse. "