Newsgroup: it.lavoro.informatica
Titolo: Sistemi IT scalabili

Ciao a tutti,
    mi piacerebbe leggere qualcosa sulle soluzioni adottate da alcuni 
big presenti su INTERNET.
In passato avevo visto circolare un documento presentato dall'IT manager 
di facebook, ma anche altri esempi di siti che sono scalati a diversi 
milioni di utenti,transazioni etc etc. sarebbe interesante.
So già ad esempio che ebay si appoggia ad oracle per il db da 6.5 peta, 
ma forse è l'unico, mentre altri sviluppano in casa le soluzioni.
Qualcuno ha link interessanti da condivdere?
Grazie.

 Grazie.
che fai di bello,
bello
felice&pago
bello dentro
.

 Qualcuno ha link interessanti da condivdere?
da qui: 
http://www.facebook.com/Engineering
o da qui: 
http://www.facebook.com/notes.php?id=9445547199

 bello
Sto studiando, devo fare qualcosa entro breve sennò divento un scemo!!!
:)
ciao

 molto con quel costo!
se 16 milioni sono pochi, erano 23 pre-crisi
100.000 entry nel listener al giorno ?
monolitico
dimenticavo:
http://www.oracle.com/oramag/index.html
ti iscrivi e te lo mandano a casa, non dirgli che ti mando io,
o lo leggi online
felice&pago
monocolo
.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 o lo leggi online
Ti ringrazio, ma ho già sbattuto la testa con larry, penso che se lo 
volessi incontrare di nuovo sarebbe solo per un madornale errore....

 che pensa molto, non puoi andare da oracle, perch� ti ammazza subito.
tutti DEVONO scaricare sull'utilizzatore finale,
non e' che si fanno dare i soldi da mamma sua,
anche la AUTO scarica in-direttamente sui clienti
e' insito nell'impresa,
o anche tu vedi l'IT come un costo improduttivo ?
se sei/vuoi essere il migliore, devi andare dal migliore,
adesso i costi e' un po' che non me ne interesso piu',
ma vedendo in giro che dal 1996 ad oggi oracle e'
entrato in moltissime realta' anche piuttosto piccole,
non posso che pensare che faccia fare business anche
a chi ce l'ha
felice&pago


 a chi ce l'ha
Hanno abbassato i prezzi e le pretese, perchè stavano "pisciando" fuori 
dall'orinale, semplice.
E proprio perchè altri facevano cose molto simili alle loro, meglio.
Loro restano il top, ma ci sono mondi che vivono a prescindere di 
oracle, mssql , db2 etc etc.
Comunque non era questo il motivo del post, solo EBAY usa oracle, e mi 
interessa poco, mi interessano di pià gli altri ch eappunto NON usano 
oracle, ma hanno diversi milioni di utenti e problemi di quel tipo 
(transazioni, profilazione etc etc).
Ciao

 (transazioni, profilazione etc etc).
sicuro di sbagliare dico che FB ha qualcosa come 600 server con oracle
sopra,
poi' mi ricordo di un gioco, dove ci si ammazza on line di guerra,
quello anche aveva, ha ?, centinaia di server con oracle
mi sembra di voler vendere qualcosa :(
felice&pago
markettaro


 sopra,
IMVHO molti big avranno Oracle in tot server, magari non per i loro
servizi primari, ma per quelli accessori (non so che ERP usi Google,
ma dubito che utilizzino BigTable come backend!)
Ricordo di aver letto più volte in passato che Yahoo usava Oracle
anche come backend per i loro siti web (o che Oracle veniva usato da n
sistemi da Microsoft, almeno fino a qualche anno fa).
--
ale
http://ale.riolo.co.uk

 sistemi da Microsoft, almeno fino a qualche anno fa).
dico una scemenza l'ldap dove lo appoggiano ?
felice&pago
kerberos


 con oracle sopra,
Decisamente sbagli, usano MySQL. Pesantemente customizzato per le loro 
esigenze, tra l'altro.
Massimo
 

 sopra,
beh, si sbagli.
I server oggi viaggeranno sui 10.000 MySql, avevo letto che li usano
senza transazioni ed ovviamente fortemente customizzati :
sostanzialmente per tenere in memoria il più possibile.
Con Oracle è letteralmente impossibile creare la maggior parte delle
aziende 2.0, troppo costoso.

 sistemi da Microsoft, almeno fino a qualche anno fa).
Ovviamente, MS come tutti comprano dei software gestionali che girano
in oracle o in altro, avevo letto che usavano AS400 per la contabilità
e non ci vedo niente di strano. Adesso con navision forse avranno
cambiato.

 sistemi da Microsoft, almeno fino a qualche anno fa).
Nope, MySQL ancora.
Internet e DB relazionali vanno d'amore e d'accordo per molto poco, poi 
l'amore si trasforma nel termine "collo di bottiglia" :)
  ngw
-- 
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA  98104  US

 mi sembra di voler vendere qualcosa :(
Una volta fb usava un MySQL patchato per interagire con memcached.
Ora usano Cassandra.


 che pensa molto, non puoi andare da oracle, perchè ti ammazza subito.
Di documenti non ne ho, perchè o ho scordato dove l'ho letto o lo so 
perchè conosco qualcuno dentro, ma delle startup che conosco (e sono 
parecchie), nessuno usa Oracle.
Quasi tutte usano MySQL e PostgreSQL per i primi tempi, per poi scalare 
a livello strutturale.
Per esempio i grossi (tipo Facebook e Twitter) scalano scrivendo 
servizi e separandone le competenze, per poi farli comunicare in modi 
diversi. Twitter usa Kestrel, un queue manager scritto in Scala (ma io 
ti consiglio RabbitMQ, che usiamo noi di Zooppa e che è strepitoso, tra 
l'altro implementa il protocollo AMPQ), Facebook usa uno storage lazy e 
distribuito su un network P2P, Cassandra (veramente bel progetto, devo 
dire).
Se è ad una startup che stai lavorando, ti consiglio di partire con un 
progetto monolitico, estraendo man mano servizi quando comincia a 
diventare grosso, e magari partendo direttamente con un 
mongodb/cassandra così ti risparmi la pena denormalizzare prima -> 
sostituire dopo a cui arrivano prima o poi tutti.
Il discorso è comunque troppo generico, scalare fuori contesto non vuol 
dire niente, Twitter ha problemi diversi di Youtube o Facebook.


 aziende 2.0, troppo costoso.
Forse una volta erano 10000, adesso non piů.
Li avevano customizzati per fare l'expire delle chiavi memcached ad 
ogni write. Da quel che so non aveva funzionato granchč :p


 dire niente, Twitter ha problemi diversi di Youtube o Facebook.
Hai ragione.
In ogni caso ti ringrazio delle info.
Michele

che pensa molto, non puoi andare da oracle, perch� ti ammazza subito.
mah su questo o tantissimi dubbi, nessun servizio richiede *from the
start* dimensionamenti per milioni di utenti, quelli verranno dopo, e'
piu' importante che le applicazioni siano strutturate per gestire
questi aspetti altrimenti oltre a dover pagare le licenze Oracle corri
il rischio di doverti riscrivere l'applicativo...


A dicembre 2009 gestivano 155 petabytes su qualche migliaia di sql server... 
:-)

 il rischio di doverti riscrivere l'applicativo...
Esatto, ed io questo sto cercando di analizzare: partire in modo tale 
che, qualora servirà scalare, non si debba riscrivere tutto.
uso la logica del divide et imepra, quindi ongi componente , attualmente 
in una ottica monolitica, è comuqnue una porzione che ptorà vivere su 
"altra" macchina, o addirittura un cluster di macchine.
In punto focale pe rme , adesso, è il db poichè è il punto dove tutto 
sbattono perchè anceh a farlo bene e perfetto, se hai un, due o tre tera 
di dati, ancora ancora, ma se passi i limiti oltre a non starci più 
dentro rischi il collasso perchè di fatto NON potrai accedere alle 
licenze oracle.
Almeno con l'idea che ho in mente io....
Quindi non mi pongo il problema di oracle, ma semmai chiedo ausilio per 
analizzare come "altri" hanno affrontato la qeustione, non tanto agli 
esordi, immagino che tutti partano da situazioni monolitiche, ma quanto 
nel momento del "breakeven" , diciamo cis, quando si diventa maturi e si 
deve fare sul serio.
Ad un certo punto se il tuo utente deve costare poco perchè non trai 
guadagno da lui, allora il costo delle licenza, caro amico mio, diventa 
la differenza fra il successo e l'insuccesso....
Io penso questo, ma ho conforto anche dalle best practices che altri 
hanno usato, come confermato da Nicholas....

 utente, invec edi 10/12, la differenza � notevole....
allora avevo capito giusto ?
oddio come detto non mi intereso delle licenze
da un bel po, ma dubito che tlc acuqisti oracle
a utente :)
al massimo a processore ecco, ma ricordo che
per auto c'era una formula speciale che
costava meno che non a processore,
ma sono vecchio e dimentico in fretta
felice&pago
46


 Nope, MySQL ancora.
Per Yahoo, non affermavo che lo usavano oggi (BTW, l'ultima volta che
ho letto qualcosa al riguardo, mi sembra di aver capito che avessero
il loro maggior database su una versione personalizzata di
PostgreSQL), ma appunto _in passato_ (BTW, una decina di anni fa anche
Amazon usava Oracle come back end!).
AD ogni modo, MySql credo sia un prodotto Oracle ormai da quasi un
semestre, no? :p
--
ale
http://ale.riolo.co.uk

> allora avevo capito giusto ?
No, avevi capito sbagliato!!  :)
Io odio oracle, non lo voglio vedere manco in cartolina, no no no.
Se , pe rle cose che sto facendo, avrò bisogno di oracle, ti autorizzo a 
darmi un calcio in culo.... :)

 Hotmail usa SQL Server:
Chiaro, è di M$!!! (ora...)
prima non era cosi....

 hanno usato, come confermato da Nicholas....
Ti invito a cercare su google "sabre mysql" e vedere come hanno 
implementato un front-end di mysql replicati da dati su mainframe...
Poi ti leggi alcuni articoli su mongodb, cassandra e gli altri "nosql" 
ora attivi.. il "guaio" � che alcuni di questi ti costringono a 
impostare l'archivio in modo specifico e molto diverso da quello 
relazionale...

 permette... memcached ad esempio
il db gli sta' tutto in ram :)
felice&pago
la terza palla


 stanno per passare a costo a "core")...
:)
Chiaramente, ma poi io prendo il costo a core e lo divido per gli utenti 
attivi !!!
E se devo presentare un bilancio, oppure chiedere i soldi agli 
strozzini, loro mi chiedono, ma a te quanto costa un utente?
E io gli risponderň "signori strozzini, siete male informati, le licenze 
io le pago a core...ahhh!!!"
...a core e mammata mi diranno.... :)
Gli strozzini sono brutta gente, sono davvero senza core....:)

 il db gli sta' tutto in ram :)
Bravo Felice!!!
Ecco quel che farï¿œ.... :)

la differenza fra il successo e l'insuccesso....
ecco se parti da questa prospettiva e' meglio che non parti affatto,
tieni presente pero' che in molti ambiti (ministeri, banche e
assicurazioni, in almeno due casi je l'ho fatto io il calcolo in
un'altra vita professionale) assai di frequente non si tiene conto del
costo di licenza (che non e' mai ad utente ma a processore o potenza
calcolata su un qualche standard figlio del TPC-C tipo il CPW
dell'IBM) ma del costo a "transazione" intendendo con transazione
qualsiasi cosa sia conveniente per l'autore dell'analisi (a me
chiesero di prendere come base il "ciclo del processore") 

 Ecco quel che farò.... :)
spiritosi :-)
ci sono molti casi nei quali mantenere una cache "fresca" degli ultimi 
dati acceduti può tornare molto utile ed è una prassi molto comune... ma 
dipende dall'applicazione !
Per ora sappiamo solo che ha milioni di potenziali utenti e possibili 
terabyte di database... (che anche qui, senza avere uno straccio di 
informazione in più come si può suggerire qualcosa... ?)
Io qualche link te l'ho dato, l'hai guardati ?

 spiritosi :-)
io ero serio !
ha una macchina con 32Gb di ram e un db da 12GB +/-
felice&pago
la palla di vetro e' in manutenzione
-


> Io qualche link te l'ho dato, l'hai guardati ?
Si, tutti, grazie.
Alcuen ciose mi sono abbastanza chiare, coem il fatto che ad oggi 
cassandra ï¿œ totalmente inutile, perhcï¿œ la mia base dati deve ancroa 
plasamrsi, ed il metodo piï¿œ veloce e semplice ï¿œ sql.
Poi se le necessitï¿œ lo imporranno, chiaramente il passaggio a situazioni 
"esoteriche" sarï¿œ chiaramente facilitato dal fatto che giï¿œ sapevamo che 
l'applicazione doveva potersi collegare a diverse "fonti" da cui 
attingere dati.

 attingere dati.
la fonte puo' ancora essere una, ma e' questa ad essere
alimentata di volta in volta da altre sorgenti, quindi
i dati arrivano gia' belli e pronti
SAP !
felice&pago
:)


 Qualcuno ha link interessanti da condivdere?
Attenzione, che per es. Facebook non usa un db SQL vero e proprio, ma
una serie di software specifici per risolvere specifiche esigenze.
Quindi non è sempre possibile passare da un db SQL "classico" come
Oracle ad un gruppo di software di memorizzazione, come quelli di
Facebook.
Vedi:
http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/

 i dati arrivano gia' belli e pronti
Un classico 3 livelli:  applicazione -> "server" -> db
Io ci metteri un quarto livello:
Applicazione -> "aggregatore" -> "server" -> db
questo perché "aggregatore" potrebbe aver più "server" sotto di lui, per 
motivi di prestazione o di tipologia di dato...
Applicazione parla solo un linguaggio con "aggregatore", mentre questo 
parla verso i server con i loro protocolli.
"aggregatore" tornerà utile al momento della possibile migrazione perché 
sarà lui, in maniera totalmente trasparente all'applicazione, a cercare 
i dati da diverse fonti..

 i dati da diverse fonti..
peccato che le fonti possano nel tempo essere diverse, anche per tipologia
per questo avevo scritto sap :)
felice&pago
sappilo


 Applicazione -> "aggregatore" -> "server" -> db
Chiaro.
Io lo faccio al momento a livello tcp/ip, con i vari load balancer.
lo farò poi, vista l'applicazione, con i vari passaggi, dove avrò di 
fronte al server (che per me è un applicazione java) il primo load 
balancer, e lo faro anche davanti al db.
In questo modo avrò grappoli di sistemi che possono scalare 
indipendemente da quello che ci sta sopra.
La coerenza del dato però è il vero cruccio, poichè in un sistema (che 
ho già usato) master+n*slave (mysql) la criticità era insita nella 
metodologia di replica, assolutamente inadeguata.
Oltre al fatto che, con engine InnodB, mysql fa cacare (scusare il 
francesismo).
Il tutto anche in quel caso fu risolto mettendo un aggregatore, che poi 
era una sorta di mem-cache ante litteram, con un'applicazione che faceva 
la query per i dati da presentare al primo e secondo livello dell'albero 
della wbe application, che produceva un file di testo!
Passammo da circa 6 secondi di attesa per la popolazione dell'albero, a 
150ms o poco meno.
Oggi come oggi non ho sottomano un mysql 6 con quella struttura, ma se 
lo riutilizzerò, andrò di certo nella direzione del cluster, almeno per 
vedere se hanno fatto qualcosa di meglio.
Tu come faresti a risolvere il problema delle Scritture sul db, in un 
contesto multi master/slave ?
Io pensavo al map-reduce, l'unica soluzione secondo me, che poi è il 
motivo del successo di google...


Ottimo spunto, ed ecco che io che sono sciemo, ci metto un aggregatore 
"sempre".
Lo raggiungerò via NIO, ma poi dietro il dato sarà quel che vorrò.
O in localhsot un mysql, o un grappolo di macchine con vari mysql, o 
persino voltdb o frattazzo da silicon valley.
Tutto quanto dipenderà da altri fattori che nella questione tecnica non 
avranno limiti strutturali, ma solo di investimenti.

 avranno limiti strutturali, ma solo di investimenti.
hai un superdome ?
la san come e' raggiungibile, rame o fibra ?
alte cose che mi sfuggono, per
esempio ho visto unzonare benino il balancing di oracle,
gli altri tutti che danno dei problemi, tu come lo faresti ?
ps:
miche' minghia come sei divnetato skillato :)
felice&pago
schifato


 miche' minghia come sei divnetato skillato :)
Ti sembrerà assurdo, ma io sono skillato :)
Tutte le grane che ho gestito nel posto ch efrequentavo prima, erano 
problemi similari a questo..pensa un poco....e dire che adesso farà si e 
no, 1000 pages view al mese....
Purtroppo sono un tipo introverso e parlo poco di me stesso e del mio 
lavoro, ma dopo essermi iscritto a facebook 8solo per lavoro), ho capito 
che il centro del mondo sei "tu stesso"...:)

 si ma il quarto livello va dietro al db :)
Può essere... io avevo in mente questo scenario:
l'applicazione necessita di un "oggetto", visto come un insieme di 
attributi/dati, metti ad esempio, nome, cognome, indirizzo, numero di 
conto bancario, gli ultimi 10 movimenti del conto, foto, foto della firma.
Mentre i dati anagrafici sono su db relazionale, i movimenti su 
mainframe, le foto sono su file-system e le foto della firma sono in un 
db stile mongo-db (key-value, per semplificare) con livello di accesso 
più alto.
chiedo quindi all'aggregatore di fornirmi l'oggetto felice_pago e ci 
penserà lui a smazzarsi il dove e il come andare a reperire le varie 
componenti...
Se poi decido di spostare i dati anagrafici delle persone con cognome 
che inizia con A-L da oracle a mysql, inserirò la regola 
sull'aggregatore e creerò un "server" che si connette al db.
o forse non ho capito quello che volevi  dire...



nn ho testa :)
sto' facendo le valigie
scusami
felice&pago
.

 contesto multi master/slave ?
Mi piacerebbe riponderti perché è un argomento che mi interessa ma non 
lo so... facebook modificò le query mysql per invalidare le cache... è 
una strada...
Oppure con questi nuovi db che partizionano e distribuiscono in 
automatico... e dato che le query NON possono essere così generiche come 
in sql puoi forse ottenere qualcosa...
Mi piacerebbe alla fine sapere come hai risolto....

 Io odio oracle, non lo voglio vedere manco in cartolina, no no no.
Allora tieni i soldi sotto il materasso... :DDDD
-- 
Ciao!
Luca

 Michele
Interessantissimo quello che ha scritto nqw :-)
comuqnue sia Postgres che Mysql hanno soluzioni scalabili. Quelle di
Postgres mi pare pero' che siano piu' o meno tutte a pagamento mentre solo
mysql trovi tutto free ( mi sono interessato circa 18 mesi fa, non so oggi
le ultimissime news)
Concordo con tutti quelli che dicono che Oracle non e' cosi' costoso di come
sembra in prima battuta, anche se calcoli a consuntivo le spese finali
totali ( personale che lavora al cluster compreso ) e le compari anche con
quelle dei free.
Personalmente io sono per postgres sempre e comuqnue, ma davvero non ho
nulla ne' contro mysql ne' contro oracle, ho qualche dubbio solo su Sql
Server, che pur essendo ottimo ti blinda al SO , il che spesso e' un
problema
ciao Nicola


 aziende 2.0, troppo costoso.
Troppo costoso od impossibile tecnicamente? Decisamente  la prima.
D'altra parte Oracle, come altri, è un db general purpose. Gli altri
sono fortemente caratterizzati per un uso ben specifico.
Non è che uno prende il db opensource non-SQL di Facebook e lo
sostituisce pari pari ad Oracle in qualunque applicazione,
dall'archivio delle ricette di mammà alla gestione delle transazioni
bancarie.
Sennò Oracle avrebbe già chiuso.

 l'amore si trasforma nel termine "collo di bottiglia" :)
Ah, infatti MySql non è relazionale, ecco perchè lo usano....



Vacca boia, ce l'avevi quasi fatta a non dire una cazzata, ma poi non 
hai resistito.
  ngw
-- 
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA  98104  US

 l'amore si trasforma nel termine "collo di bottiglia" :)
Si va beh.. collo molto molto largo però. I relazionali non vanno bene
per i sitarelli di forum da 2 lire o per servizi  grandissimi iper
specializzati, vedo che banche ed assicurazioni per adesso vanno
bene..

 bene..
Non si stava parlando ne di sitarelli ne di banche, si stava parlando 
di startup.
Ad un certo punto, se *devi* scalare, *devi* denormalizzare. E mica me 
l'invento, lo sanno anche i sassi che Twitter si č denormalizzato 
l'anima, e che appena finito ha avuto problemi di request bloccanti e 
scalava di merda.
Da Digg, a Twitter, a Facebook, tutti sono andati verso soluzioni 
diverse. Forse i confronti con le banche sono un pochino fuori luogo.


>l'amore si trasforma nel termine "collo di bottiglia" :)
Parlavamo di internet e DB relazionali, ok, forse la banche lo sono,
ma quel che volevo dire è che non tutte le start-up puntano o devono
puntare a milioni di utenti contemporanei. In altre parole, quello del
destrutturato-no transazioni-tutto in memoria è una internet, un
modello di applicazioni che scalano a basso o bassissimo costo, ma una
scelta del genere la fai consapevolmente se quello è il tuo modello.
Il mio punto è che internet e relazionali vanno d'accordo, dipende dal
contesto.

 contesto.
http://qix.it/2010/05/yes-i-am-a-data-geek-2/#comment_104131
Il punto mio invece č: relazionali vanno bene per il 95% dei casi.
Esiste un 5%, dove non vanno bene, ed oggi ti devi arrangiare per 
sistemare le cose, pena il fallimento generale e improcrastinabile del 
progetto.
Quale che sia...

 scelta del genere la fai consapevolmente se quello è il tuo modello.
Non fa impressione parlare di "utenti contemporanei" e sostenere che 
fondare il proprio sistema su operazioni bloccanti sia una buona scelta 
nella stessa frase ? :-)


 dell'IBM) ma del costo a "transazione" intendendo con transazione
....no, non mi serve ed è costoso ai livelli che penso io, che sono poi 
questi...
http://news.cnet.com/8301-1001_3-10209580-92.html
In particolare: "Mainstream servers with x86 processors were the only 
option, he added. "Ten years ago...it was clear the only way to make 
(search) work as free product was to run on relatively cheap hardware. 
You can't run it on a mainframe. The margins just don't work out," he said."
Il paradigma facile vuole che un certo hw che scali, con certo sw che si 
possa comprare a prezzi "ragionevoli", sia la soluzione.
No, non è quello che penso io, e già dieci anni fa io stesso prendevo 
macchine assai a basso costo però ne ho prese 10 per fare qualcosa.
Allora non funzionò perchè il SW non era completo ed il db era 
"standard"....

 said."
http://hardware.slashdot.org/story/09/06/26/028218/Facebook-VP-Slams-Intels-AMDs-Chip-Performance-Claims
:)
http://tech.slashdot.org/story/10/06/28/1425242/Facebook-Usage-Hits-16-Billion-Minutes-a-Day

 nella stessa frase ? :-)
Beh, mettiamola così : se i record rappresentano le stelline dei voti
degli utenti anche io potrei usare un destrutturato.

 degli utenti anche io potrei usare un destrutturato.
...certo... 
http://www.youtube.com/watch?gl=IT&v=T-Xr_PJdNmQ

 ...certo... 
http://www.youtube.com/watch?gl=IT&v=T-Xr_PJdNmQ
Anche perchč a me francamente di quello che fa "equinozio" fotte una 
sontuosa sega, ho semplicemente detto cosa fanno gli altri e cosa viene 
suggerito per scalare.
Se poi la risposta č "uso un 'destrutturato' (cos'č ?) per le 
stelline", l'unica cosa che posso dire č "Auguri e speriamo che resti 
piccolo. Molto.".


 piccolo. Molto.".
Mah, fino alla dimensione di SAP la strada è battuta, oltre magari ti
chiamo...

 chiamo...
no aspetta, forse ho sbagliato risposta, ti riferivi alla singola
applicazione non alla società, allora mi fermo quando faccio
un'applicazione tipo il NASDAQ che non è neppure Oracle (!)
I repeat : quella dei DB destrutturati è una internet, non la sola
soluzione.



Scusa, ma di che cosa si sta parlando ?
Cosa c'entra il NASDAQ ? Che società ? Ma che casino c'hai in testa ? :D


 Cosa c'entra il NASDAQ ? Che societ ? Ma che casino c'hai in testa ? :D
E allora amnco io ho capito il tuo sfottò  "Auguri e speriamo che
resti piccolo. Molto.".
Che deve rimanere piccolo ? La società, l'applicazione, il cervello il
DB o altro ?

 DB o altro ?
L'applicazione.


> L'applicazione.
Appunto, un'applicazione può diventare molto grande, essere molto
diffusa ed avere molto successo senza necessariamente avere un DB
condiviso.
Può anche diventare molto grane e veloce (borse mondiali o
telecomunicazioni) pur mantenendo un relazionale ed una 'assoluta
precisione nelle transazioni.
La moda necessità della tabella piatta nasce solo in alcuni
particolarissimi casi e fare una scelta del genere senza averne i
numeri è come preoccuparsi dei paracaduti di arresto per anadare in
bicicletta.

 bicicletta.
Ma che roba è una "tabella piatta" ? Dai vecchio, per favore, 
risparmiami il punto in cui tenti di pescare la carta giusta dal mazzo 
e devo beccarmi tutti e 200 i tentativi, non ci sono "tabelle piatte". 
Almeno aprire l'homepage di uno dei progetti sopracitati potevi farla.
E ti prego, evitiamo di bollare come moda tutto quello che non si 
conosce, che è un po' stancante come cosa.


 risparmiami il punto in cui tenti di pescare la carta giusta dal mazzo
Giovine, vai tanquillo con i tuoi DB moderni.
Te lo dico e te lo ripeto, sono seghe mentali nel 99% dei casi. Fa
figo usare un'imitazione dell'infrastruttura di facebook o google, ma
è fuffa, marketing, aria fritta. I tuoi sistemi starebbero su
benissimo con un Oracle o con un SqlServer, forse perfino con access.

 benissimo con un Oracle o con un SqlServer, forse perfino con access.
Praticamente mi stai dicendo che svolgo il mio lavoro seguendo delle 
mode, senza nemmeno sapere che problemi ho o tento di risolvere, ma con 
una occhiata al software. Molto professionale :)
Non solo sei cronicamente impreparato sullo scibile umano per quanto 
riguarda l'informatica, con valutazioni da medioman che risultano 
imbarazzanti e suggeriscono che hai davvero sbagliato gruppo (ndr: 
it.hobby.*), ma trai conclusioni su cose che ho detto che col cazzo 
contesti entrando nel merito, ma con il solito piagnisteo sul 
"marketing" e sulle "mode" (che ormai evidentemente nasconde le 
impreparazioni più svariate) e con qualche calunnietta :)
Come presumibilmente qualunque imbecille ha capito, il problema non è 
"tenere i dati" (si dice "lo storage", imparalo che poi fai brutta 
figura al prossimo stage), ma il realtime e i sistemi push che hanno 
praticamente tutti i social network di questo pianeta, per permettere 
il processing del dato in background e la successiva pubblicazione su 
diversi frontend (rss, html, json, xml).
Prendiamo la più normale delle feature, la timeline resa famosa da Facebook.
Con un database, hai la tua bella tabellona "activities", "events" e 
cazzi vari che contiene n referenze ad "attori", "oggetti", "soggetti", 
usando principalmente due approcci: relazioni polimorfiche, in cui una 
relazione puo' riferirsi ad un oggetto di qualunque tipo, o avendo una 
relazione normalizzata (quindi un campo per tipo di evento, user_id, 
comment_id, salcazzo_id, tipicamente sono un pacco e mezzo).
Come si implementa questa cosa ? Avrai degli "amici", dei "follow", 
quindi una bella tabellona, spesso grossina, con due belle referenze.
Piglia tutti gli amichetti santi (incachabile, non esiste che l'utente 
debba aspettare per vedere cosa fanno gli amichetti, it's web 2.0 
baby), e poi usando quel dato fai una bella select sulla tabella 
eventi, select che per forza di cose è una quadrupla join carpiata con 
doppio scappellamento a destra, che molto semplicemente tira su di 
ogni, visto che del singolo evento dovrai pur far vedere qualcosa. 
Incachabile ovviamente, vorrai mica far vedere quello che è successo 10 
minuti fa e non quello che succede ora.
Due problemini, mi porti la soluzione domani nel doposcuola.
La tabella eventi è tutta un indice, le scritture sono lentine, e 
tante. Tipicamente, ad esempio nella tua amata borsa mondiale, le 
scritture sono un tantinello meno delle letture, qui la differenza 
invece è poca. Le scritture avvengono per praticamente qualunque 
cazzata succede nel software, ovviamente tutte bloccanti. Scrivi un bel 
commentone ? Scrittura per il commento e scrittura per l'evento, poi 
ritorno dall'utente perchè mica posso accettargli un commento non 
valido e non dirglielo.
L'esperienza comincia a diventare "sloppy", aspettare 3 secondi per 
ogni cosa lo è.
Come faccio a velocizzare le write ?
Secondo problemino: la mia bella timeline è oggettivamente lenta. La 
query cambia ad ogni request (ovviamente) per un numero infinito di 
combinazioni. La SELECT sulla brava tabella eventi in questo momento 
equivale al *72%* del totale di tempo speso sul database, la pagina con 
la nostra amata timeline prende il *32%* del totale di tempo speso sul 
sito. E' la più trafficata ? Col cazzo, numero 4, 50k visite scarse al 
giorno. Per un sito che gira su 12 istanze su 4 macchine + 1 bella 
pompata per il DB.
Ho sbagliato lo schema ? Il signor Tyler Poland 
(
http://tinyurl.com/28fxjyv
) dice di no, gli indici sono apposto, le 
query anche. E' che è una operazione "pesante" (ma dai ! chi l'avrebbe 
mai detto, io ci ho un tizio che fa tutto con Access !), le scritture 
sono continue sul master (600k write / giorno di eventi) quindi lo è la 
replicazione, quindi lo è la lettura sugli slave. Essendo lentina che 
fanno gli utenti ? Refresh.
Vogliamo cachare il singolo evento in vista ? Se vuoi ti faccio un 
video con le stat di memcached, tanto per vedere in quanti minuti 
riempie il pool di memcached, perchè ovviamente lo storage avviene per 
singolo utente, a volte *tu* hai vinto un premio, a volte *un tuo 
amico* ha vinto un premio, a volte *un tuo amico* ha lasciato un 
commento sul profilo di chi ha vinto un premio.
Aspetto speranzoso, del resto tu lo fai stare su Access nonostante sia 
una interfaccia per dei motori e non un database, e tra l'altro sei 
libero da questo "marketing" che questi autori di "DB nuovi" (rofl, ma 
si puo' dopo anni venire a conoscenza che sul mercato ci sono n 
tipologie di DB differenti ? :D) fanno durante diverse conferenze 
tecniche, e per dei prodotti opensource e gratuiti. Oracle al marketing 
non ci arriverà mai, purtroppo, e io risaputamente seguo solo il 
marketing.
Vediamo in che modo riesci a fare il fugone questa volta, ci giochiamo 
ancora la carta "mamma quello li mi insulta" magari attribuendomi frasi 
inventate da te ?


 al posto di ngw nell'azienda in cui lavora...
Non credo proprio che mi prenderebbero, sono troppo 2.0, io sono
rimasto indietro, come le palle del cane.

 query cambia ad ogni request (ovviamente) per un numero infinito di
Che detto in parole poverissime hai una query che viene interrogata
4,
50k volte al giorno per mostrare degli eventi ? E' questo il
problema ?

 problema ?
50k *unici*. Che refreshano come dannati perchč č lenta.
Poi ti dico come si risolve, ma vediamo che segone mi tiri fuori, 
perchč sono curioso.
Scordati Oracle eh, costoso e non supportato dal nostro hosting. Anche 
suggerimenti per scalare verticalmente non vanno bene, significa che il 
problema si ripresenta dopo poco, quando aumenta il traffico.


 problema si ripresenta dopo poco, quando aumenta il traffico.
Prima soluzione : monto Oracle o SqlServer, troppo costoso è relativo
al tempo che gente pagata profumatamente impiega per sopperire al
problema di prestazioni. La prima soluzione è compro software e
Hardware.
Seconda Soluzione :  (stavolta invento tanto per giocare)  la faccio
diventare push con ritardo. Ovvero faccio inserire gli eventi su una
tabella consolidata e su una di cache : se ci sono solo 600k eventi in
un giorno si parla di 600 minuto : molto pochi. Dopo di che scorro la
tabella di cache con una stored ogni 10 secondi, significa elaborare
l'effetto di 100 messaggi. Dopo di che aggiorno tutte le timeline
attuali degli utenti connessi e i 50k possono premere F5 quanto
vogliono, tanto leggono sempre una tabella piatta, aggiornata push. E
se qualcuno va indietro nel tempo nella timeline faccio come
facebook.. sono leeeento e vado di query sulle consolidate.
Ti piace ? Se raddoppi i numeri per 10 credo reggerebbe comunque.
E comunque i numeri restano piccoli, si parla di 60.000 utenti, il
problema sono i limiti di budget o tecnologici che voi stessi vi
imponete, un Oracle numeri così se li mangia a colazione e cazzeggia
il resto del giorno.

 il resto del giorno.
Oh bella, hai dedotto il numero dei miei utenti dagli unici di una 
singola pagina. E io che pensavo che il massimo della skill me l'avessi 
data con Access, la divinazione non me l'aspettavo.
Guarda, è molto evidente, non hai budget e parli di pageviews. Tu sei 
nel 2000, appena prima della bolla, fai esattamente gli stessi discorsi.
Ora risali sulla DeLorean e di a tutti che succederà un casino, 
cadranno dei grattaceli e se non si riprendono e la piantano di 
spendere a cazzo saranno tutti in mezzo alla strada, sbrigati !


You can't run it on a mainframe. The margins just don't work out," he said."
Mentre sono d'accorod che si tratta di "relatively cheap hardware",
non sono affatto convinto che si tratti di "mainstream server", anzi
gia la storia della batteria aggiunta senza ups li pone, credo fuori
dall'ambito "mainstream".
P.S.
Io non ho mai parlato di acquisire mainframe.
P.S.2
In bocca al lupo per il tuo progetto se gia ti stai ponendo 'sto tipo
di problemi... 

 giorno ed una insert ti impiega 3 secondi ?????
Lascia perdere, è ovvio che non vuole andare da Oracle od IBM e farsi
personalizzare il db per soddisfare queste esigenze del tutto
specifiche.
Cosa che per la famigerata "startup" non mi sorprende, è altrettanto
ovvio che risparmiano pure sulla carta igienica. Un pò più
sorprendente è che realtà grandi come Facebook non l'abbiano fatto. Si
vede che pure loro sono senza carta igienica... :-)))

 una bella "tabella di cache", parti con valutazioni del tutto prive di senso sul traffico
Ma grazie ! In assenza di dati ho preso il numero totale e l'ho diviso
per 15 o 16 ipotizzando una media delle ore di punta e quindi
mantenendomi largo sulla media. I picchi contano ma poco, la soluzione
con cache rallenta solo l'aggiornamento ma non crolla. Rimane il fatto
che la mia proposta era solo per giocare, non entro nel merito
specifico.

 specifiche.
600.000 righe al giorno sono pochissime, non c'è bisogno di
personalizzare proprio niente !

 personalizzare proprio niente !
E dai, non uscire fuori tema, già il "giovine" ti ha rimproverato.
Parliamo sempre di "startup", mica vorrai che parte con un hardware
più grosso del pc di casa? :-)))

 Io non ho mai parlato di acquisire mainframe.
A proposito di mainframe, stavo guardando una presentazione di
Cassandra:
http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/
Per chi conosce i mainframe IBM, sembra praticamente un clone del
VSAM.
Tra l'altro, con relativa impossibilità di eseguire facilmente query
che si discostino dalla struttura iniziale congelata nei "job" XML di
definizione.
Invece di andare avanti, andiamo indietro? :-)

 più grosso del pc di casa? :-)))
So troppo vecchio, è una realtà :-(

Invece di andare avanti, andiamo indietro? :-)
La prima volta che ho letto un articolo su questi prodotti (db
schemaless et similia) la mente mi e' corsa alle applicazioni che mio
padre scriveva nei primi anni 80 del secolo scorso in ambito mainframe
e system 3x della IBM. Concettualmente lui (e is suoi colleghi e soci)
realizzava le stesse soluzioni (db-denormalizzati and so on) ben prima
che la necessita' per affrontarle venisse da Internet, laddove il
problema dell'epoca erano la scarsa potenza delle risorse hw, il
grosso investimento economico necessario per incrementarle, la sempre
maggiore richiesta di funzionalita' degli utenti (a ben vedere ci sono
pero' molte similitudini con la situazione odierna).
Non credo che si vada indietro invece che avanti, credo semplicemente
che certe soluzioni "concettuali" siano sempre valide, cambia solo la
scala di riferimento (per mio padre negli eighties le relativamente
poche migliaia di utenti di una banca, per facebook oggi i 400 et plus
milioni di utenti raggiunti tramite il web).



Certo che devi essere veramente un grande proffessionista se quando hai 
un problema l'unica soluzione è andare da $grosso_nome a farti 
"personalizzare il db".
E ti stupisci perchè Facebook non lo fa, è quello il bello.
Cominciamo dalle cose semplici, metti apposto il tuo computer che sono 
mesi che mandi messaggi doppi, poi vediamo per il resto.


 specifico.
In effetti sei molto bravo ad insultare e a rifiutarti di entrare nello 
specifico, e come vedi è già arrivato un'altro grande informatico, 
quello che tipicamente mi lascia i commentini rabbiosi pieni di faccine 
dietro e che posta messaggi doppi da mesi perchè evidentemente è così 
bravo che non riesce a mettere apposto il suo stesso computer, a 
sostenere la politica del "se non sei capace pompa soldi in Oracle che 
almeno la colpa è loro".
Perdiamoci di vista, ok ?


 Perdiamoci di vista, ok ?
Ma neache per sogno caro, non ti lascio scrivere quel che ti pare
facendo il saputello 2.0 :
Cito :
"Internet e DB relazionali vanno d'amore e d'accordo per molto poco,
poi l'amore si trasforma nel termine "collo di bottiglia" :)"
Dimenticando che internet <> da solcial network e che pure nei social
network l'affermazione è falsa, anzi uno dei più grossi socialnetwork
usa proprio SqlServer.
E' che io sbaglio, invece di dirti subito che una gran cazzata come
diresti tu mi perdo a metterla giù piano, tu plonkami se vuoi,
tranquillo, non me la prendo, attaccami sulle parole, sulle mie
imprecisioni nei termini ma non sperare che io stia zitto perchè non
ci penso proprio.

 ci penso proprio.
Dimostra che è una cazzata. Ovviamente la conclusione della 
dimostrazione dovrebbe essere diversa da un sad trombone. Per ora hai 
fallito in tutti i sensi, hai tralasciato buona parte delle domande che 
ti sono state poste con il solito dirty quoting che ormai è una 
costante, e ai vari annunci non hai fatto seguire un beneamato cazzo, 
con il solito livello tecnico imbarazzante che ti contraddistingue.
Si, hai scoperto a forza di Google che un social network usa SQLServer. 
Stranamente non hai scoperto che stanno perdendo utenti (milioni di) ma 
continuano ad aggiungere server, aggravando il bilancio che è già in 
perdita. Tutto qui ? Wow. Just Wow.


 Temo sia difficilotto modificare SQLServer sai.
E ti sbaglia anche qui, non solo sparli sparli su Myspace che fa lo
storage da solo, ma non sai neppure niente di come lavorano le big.
Conosco almeno un caso in cui MS ha fatto una patch non pubblica su
Sql appositamente per un cliente.
No ma dico, su Myspace l'hai proprio sparata vero ? Hai cercato su
Google, hai trovato l'articolo, hai letto le prime pagine e l'hai
postato senza finirlo vero ?
Ma fai così con tutto ? LOL!  Non è che tocca verificarle le cose che
scrivi ? Spari nomi fighi di tecnologie e persone ma non è che le
leggi 5 minuti prima su internet vero ? Spettacolo, se è così sei il
mio mito !
Per il resto ovviamente non ti rispondo, sono solo pretesti, come
quando cerchi di dire che si myspace usa un relazionale ma lui non
vale per quello o quell'altro motivo...  triste.

 vale per quello o quell'altro motivo...  triste.
Sai che c'è di triste, che anche su questo gruppo è pieno di 
coglionazzi come te, che non fanno una valutazione tecnologica nemmeno 
se supplicati: è tutto un $grosso usa $robo quindi $robo è buono perchè 
lo usa $grosso. Siete sostituibili con Punto Informatico e 10 cinesi, 
meraviglioso :D
Non sei nemmeno in grado di renderti conto che un database relazionale 
va bene per MySpace, perchè sono dei cazzo di profili con dell'html 
messo dentro a cazzo dai suoi utenti.
Mai parlato di validità, ho semplicemente fatto notare che i guadagni 
di MySpace stanno calando e i costi salendo, ed è l'unico esempio che 
sei riuscito a trovare e su cui continui a martellare i coglioni per 
avere ragione. Peccato che io di esempi te ne ho forniti una decina, 
quelli che hai bollato come "mode".
Passo e chiudo, di parlare con dei bimbiminkia non ho tempo.
Puoi calmarti e togliere il ditino dal canc.


 Puoi calmarti e togliere il ditino dal canc.
O bella.. te ne esci scrivendo che MySpace si è scritto il suo
storage.. cosa palesemente falsa, ed alla fine ti arrabbi e te ne vai
dandomi del bimbominkia  ?  E mo con lo shuttle che ci faccio ?

 mezo tra il bad old italian workin' style e Mr. Knowitall...
Pensa io invece mi chiedo come mai ti vuoi infilare nel mezzo gratis.
Pensa, non ci fossi io a discutere con ngw tu che potresti leggere su
ili ?

 dire).
http://java.dzone.com/articles/twitter-passes-cassandra-based
http://highscalability.com/blog/2010/7/11/so-why-is-twitter-really-not-using-cassandra-to-store-tweets.html
http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html
....