Come progettare un'applicazione Web ospitata?

Question

Come progetteresti un'applicazione web ospitata? Sto esaminando applicazioni come Basecamp, Campaign Monitor, Freshbooks, ecc ... in cui gli utenti possono registrarsi online e l'applicazione è ospitata per loro.

1. Utilizzeresti 1 grande database per archiviare tutti i dati dei tuoi clienti o gestiresti i dati in modo diverso? Utilizzeresti più di 1 database? Vuoi creare un database per ciascun cliente?
2. Duplicheresti la tua base di codice per ogni iscrizione / cliente o useresti 1 base di codice per gestire tutti i clienti?
3. Ci sono altri elementi di design a cui dovrei pensare?
4. Qualche sito web o libro là fuori che ne parla?

Modifica: Ho trovato un articolo MSDN che parlava dell'architettura dei dati multi-tenant: http://msdn.microsoft.com/en-us/library/ aa479086.aspx # mlttntda_topic4

Answer 1

Fai riferimento a 37 segnali - sono esperti in questo campo e hanno molti articoli in cui rispondono alle domande della comunità (molti come il tuo dovrebbero venire fuori).

High Scalability = 37signals Architecture

Chiedi a 37signals: come si fa elaborate le carte di credito?

Per quanto riguarda il numero di database, da David Heinemeier Hansson in Che cosa vuoi sapere?

  

Alcune risposte tecniche & # 8230;

     

Lancia, tutta la nostra fatturazione programmata   le operazioni sono automatizzate. Nulla   una cosa del genere ci renderebbe pazzi.   È particolarmente importante accertarsene   che è in atto la gestione di emergenza   per mancata carta di credito. Ultimo io   guardato, credo che il 5% delle nostre accuse   rimbalzato grazie alle carte di credito che   sono scaduti, oltre il limite o   chiuso. Assicurati di gestirlo   con grazia.

     

Usiamo solo Authorize.net e a   applicazione separata per carta di credito (piccola   app sviluppata in Rails e utilizzata da   altre app sulla rete interna   tramite REST) ??che mantiene i numeri   sicuro.

     

Warren, gestiamo account gratuiti ea pagamento   sullo stesso database. È quello   database per applicazione. Un database   per account è normalmente un   davvero pessima idea. Di solito i dati sono   abbastanza normalizzato, ma noi stiamo parlando di   sicuramente non religioso al riguardo. io   generalmente valuto il mio codice sorgente rispetto al mio   schema. Quindi se posso ottenere   codice sorgente migliore / più bello piegando   uno schema, generalmente lo farò. Ma   iniziare da normalizzato e denormalizzare   come struttura delle prestazioni o del codice   lo richiede.

     

Jason, usiamo l'email per gli sms. Tutti noi   i vettori hanno a   phone@carrier-gateway.com gateway.

     

Jake Good, ahh, il buon vecchio & # 8217; & # 8220; ma lo fa   ridimensiona & # 8221; domanda. Ho risposto a quello   un paio d'anni fa. Niente ha   cambiato per noi da allora. Ci riusciamo   milioni e milioni di dinamici   richieste ogni giorno senza nemmeno   ricorrere a molta cache (la maggior parte   schermi nella maggior parte delle nostre applicazioni   sono diversi per utente, quindi   i tradizionali schemi di memorizzazione nella cache sono più difficili   da applicare).

     

Esistono molti altri binari   applicazioni là fuori che gestiscono decine   di milioni di richieste giornaliere. Tutti   seguire più o meno lo stesso Condiviso   Niente si avvicina. Tutte le tecniche   per scalare alto e alto sono fuori   Là. È quasi una chiave di volta   soluzione, ma tutto ciò che promette   essere quello di solito è solo pieno di esso.

Answer 2

Se stai parlando solo di migliaia di clienti (rispetto a centinaia di migliaia o milioni), la differenza è piuttosto minima a meno che tu non sappia che hai tabelle che potrebbero avere migliaia di righe per cliente o più. Quindi il tuo design potrebbe cambiare.

L'impostazione normale per un archivio dati basato su database relazionali inserirà una chiave esterna customer_id sulla maggior parte delle tabelle. Quindi non mostrare quei dati a nessuno tranne a quel cliente (o nei casi in cui abbiano in qualche modo indicato che le autorizzazioni esplicite sono concesse a qualcun altro).

Non preoccuparti troppo dei problemi di ridimensionamento RDBMS fino a quando sembra che potresti iniziare a disporre di più milioni di righe in una tabella. Quindi potrebbe essere il momento di esaminare un archivio di chiavi / valori distribuito. Ma tieni presente che questo tipo di problema è il buon tipo di problema, perché presumibilmente significa che stai facendo un sacco di soldi.

vale a dire, attraversare il ponte di ridimensionamento quando ci si arriva. Progetta le cose al meglio delle tue attuali capacità, ma per il resto l'ottimizzazione prematura è la radice di tutti i mali.

Answer 3

Lavoro come consulente per diverse app SaaS, quindi ho visto architetture diverse. Consiglierei:

1. Un database per tutti i clienti. Assicurati di progettare bene il db in modo da avere una chiave primaria per l'utente che sia il tuo ID univoco. Ho visto alcuni pasticci in cui il design è stato efficace (non in realtà, ma potrebbe anche averlo fatto) come qualcosa come e-mail, numero di telefono, ecc. Come chiave primaria. Inoltre, non finire per gettare tutto in un tavolo utente gigante.

   1. A un certo punto vorresti iniziare a monitorare molti comportamenti di interazione dell'utente. Per questo, è possibile utilizzare un archivio nome-valore NoSQL e iniziare a lanciare eventi al suo interno per un'analisi successiva. Oppure usa qualcosa come MixPanel o KISSmetrics.

   2. Tieni traccia dei KPI giornalieri scrivendo le righe in una tabella KPI che semplifica l'interrogazione di ciò che è accaduto nel tempo. Altrimenti finirai per voler fare domande al db e scoprire che è una query gigantesca farlo.

Un vantaggio chiave di avere un singolo db SQL è che se il tuo marketing conosce l'SQL (consigliato!), può semplicemente interrogarlo direttamente. Se segui la strada NoSQL, allora è molto più difficile, e quindi il marketing inizia a fare ipotesi che di solito sono sbagliate e perdi molto tempo seguendo la strada sbagliata basata su tali ipotesi.