Couchbase Meetup - "Introduzione a NoSQL e Couchbase"
3 likes795 views
Il documento esplora le motivazioni per l'adozione di database NoSQL, come Couchbase, in contesti di big data e applicazioni SaaS/cloud. Descrive come la crescita esponenziale dei dati eterogenei richieda modelli di archiviazione più flessibili e scalabili rispetto ai database relazionali tradizionali. Infine, evidenzia le caratteristiche distintive di Couchbase, come la scalabilità orizzontale, le alte prestazioni e l'assenza di lock, rendendolo adatto per applicazioni web ad alta interattività.
![Database
a
Documento
• Ogni
record
e’
un
documento
a
se’
stante
• Ogni
documento
ha
una
stru<ura
indipendente
• I
documenJ
possono
essere
complessi
• Richiedono
una
chiave
unica
• I
daJ
sono
immagazzinaJ
in
formato
JSON,
XML
o
simili
• Il
contenuto
puo’
essere
indicizzato
e
interrogato
• Offrono
sharding
automaJco
e
repliche
{
“UUID”:
“21f7f8de-‐8051-‐5b89-‐86
“Time”:
“2011-‐04-‐01T13:01:02.42
“Server”:
“A2223E”,
“Calling
Server”:
“A2213W”,
“Type”:
“E100”,
“Initiating
User”:
“dsallings@spy.net”,
“Details”:
{
“IP”:
“10.1.1.22”,
“API”:
“InsertDVDQueueItem”,
“Trace”:
“cleansed”,
“Tags”:
[
“SERVER”,
“US-‐West”,
“API”
]
}
}](https://image.slidesharecdn.com/introduzione-a-nosql-e-couchbase-130723103049-phpapp01/85/Couchbase-Meetup-Introduzione-a-NoSQL-e-Couchbase-25-320.jpg)
![Esempio
Blog
Diviso
su
piu’
DocumenC
{
“UUID”:
“21f7f8de-‐8051-‐5b89-‐86
“Time”:
“2011-‐04-‐01T13:01:02.42
“Server”:
“A2223E”,
“Calling
Server”:
“A2213W”,
“Type”:
“E100”,
“Initiating
User”:
“dsallings@spy.net”,
“Details”:
{
“IP”:
“10.1.1.22”,
“API”:
“InsertDVDQueueItem”,
“Trace”:
“cleansed”,
“Tags”:
[
“SERVER”,
“US-‐West”,
“API”
]
}
}
{ !
“_id”: “Coucbase_Hello_World”,!
“author”: “dborkar”, !
“type”: “post”!
“title”: “Hello World”,!
“format”: “markdown”, !
“body”: “Hello from [Couchbase](
http://couchbase.com).”, !
“html”: “<p>Hello from <a href=“http: …!
“comments”:[!
! “comment1_Couchbase_Hello_world”!
! ]!
}!
{
“UUID ”:
“2 1 f7 f8 de-‐8 0 5 1 -‐5 b89 -‐8 6
“Time”:
“2 0 1 1 -‐0 4 -‐0 1 T1 3 :0 1 :0 2.4 2
“Server”:
“A2 2 2 3 E”,
“Calling
Server”:
“A2 2 1 3 W”,
“Type”:
“E1 0 0 ”,
“Initiating
Us er”:
“ds allings @s py.net”,
“D etails ”:
{
“IP”:
“1 0 .1 .1 .2 2 ”,
“API”:
“Ins ertD VD QueueItem”,
“Trace”:
“cleans ed”,
“Tags ”:
[
“SERVER”,
“US-‐Wes t”,
“API”
]
}
}
{!
“_id”: “comment1_Couchbase_Hello_World”,!
“format”: “markdown”, !
“body”:”Awesome post!” !
}
BLOG
COMMENTI](https://image.slidesharecdn.com/introduzione-a-nosql-e-couchbase-130723103049-phpapp01/85/Couchbase-Meetup-Introduzione-a-NoSQL-e-Couchbase-29-320.jpg)
Couchbase Meetup - "Introduzione a NoSQL e Couchbase"
- 1. Introduzione a NoSQL e Couchbase Franco Caporale
- 4. Tre Nuove Tendenze Big Data SaaS/Cloud MolC UtenC
- 5. 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2000 2006 2011 Source: IDC 2011 Digital Universe Study (h<p://www.emc.com/collateral/demos/microsites/emc-‐digital-‐universe-‐2011/index.htm) Trillions of Gigabytes (Ze<abytes) Big Data • DaC molto eterogenei a crescita esponenziale DaC Non StruMuraC DaC StruMuraC Text, Log Files, Click Streams, Blogs, Tweets, Audio, Video, etc. E’ necessario un modello dei daC piu’ flessibile
- 6. MolC UtenC • UtenC da tuMo il mondo, sempre connessi UtenC Smartphone Ore passate online 35 Miliardi di ore 1Miliardo + Popolazione online 2Miliardi + h<p://www.go-‐gulf.com/blog/online-‐Jme h<p://business.Jme.com/2012/02/14/one-‐billion-‐smartphones-‐by-‐2016-‐here-‐comes-‐the-‐mobile-‐arms-‐race/ E’ necessario un database facile da scalare
- 7. SaaS/Cloud • Le nuove applicazioni uClizzano un’architeMura a 3 livelli ArchiteMura client/server Client User interface Business and data processing logic Database Server Data LAN Moderna architeMura a 3 livelli Web/App Server Tier Cloud Public/Private/Hybrid Cloud Database Server Tier INTERNET Un database che si puo’ scalare orizzontalmente si adaMa bene alle applicazioni su cloud
- 8. NoSQL + + Piu’ daC Piu’ utenC SaaS/Cloud Scalabilita’, performance e facilita’ di sviluppo
- 9. In mancanza di una soluzione gli utenC se la sono inventata Dynamo October 2007 Cassandra August 2008 Voldemort February 2009 November 2006 Bigtable Poche aziende sono in grado di costruirsi e mantenersi un database
- 10. Draw Something
- 11. Draw Something – OMGPop
- 12. Draw Something diventa virale in 3 sebmane 19 17 15 13 11 9 7 5 3 3/1 28 26 24 22 20 18 16 14 12 10 8 2/6 Daily Ac)ve Users (millions) 21 2 4 6 8 10 12 14 16
- 13. I daC crescono in modo non lineare… 19 17 15 13 11 9 7 5 3 3/1 28 26 24 22 20 18 16 14 12 10 8 2/6 Daily Ac)ve Users (millions) 21 2 4 6 8 10 12 14 16 In un mese 30,000,000 di downloads della app, oltre 5,000 disegni al secondo, oltre 2,200,000,000 disegni immagazzinaJ, oltre 105,000 operazioni al secondo, e oltre 3.3 terabytes di daJ in totale.
- 14. Invece con RDBMS…… 19 17 15 13 11 9 7 5 3 3/1 28 26 24 22 20 18 16 14 12 10 8 2/6 The Simpson’s: Tapped Out Daily Ac)ve Users (millions) 21 2 4 6 8 10 12 14 16 #2 Free app on iPad #3 Free app on iPhone
- 15. MySQL o NoSQL?
- 16. La maggioranza delle applicazioni uClizzano gli RDBMS
- 17. E a volte puo’ diventare un po’ grande….. h<p://www.seoclerks.com/imagedb/2005/BIG-‐CAT-‐FOUND-‐Spoh
- 18. ……o forse enorme! h<p://www.2pep.com/extreme-‐funny-‐stuff/
- 19. E complicato!
- 20. I principali moCvi per l’adozione del NoSQL Schema rigido e non flessibile Difficolta’ a scalare Problemi di performance CosC Tub I precedenC Altri 49% 35% 29% 16% 12% 11% Source: Couchbase Survey, December 2011, n = 1351.
- 21. Architettura moderna di un’applicazione web Application Scales Out Just add more commodity web servers Database Scales Up Get a bigger, more complex server Nota – I database relazionali sono una tecnologia eccellente ma non per questo uso.
- 22. I database NoSQL utilizzano la stessa logica dell’applicazione Application Scales Out Just add more commodity web servers Database Scales Out Just add more commodity data servers Scalando orizzontalmente si riducono I costi e aumentano le performance NoSQL Database Servers
- 23. Una StruMura dei DaC Diversa
- 24. Modello Relazionale vs. A Documento Modello “Relazionale” Modello “A documento” Collezione di documenJ complessi con formaJ arbitrari e schema variabile Tabelle con schema rigido e stru<ura dei daJ predefinita JSON JSON JSON C1 C2 C3 C4 { }
- 25. Database a Documento • Ogni record e’ un documento a se’ stante • Ogni documento ha una stru<ura indipendente • I documenJ possono essere complessi • Richiedono una chiave unica • I daJ sono immagazzinaJ in formato JSON, XML o simili • Il contenuto puo’ essere indicizzato e interrogato • Offrono sharding automaJco e repliche { “UUID”: “21f7f8de-‐8051-‐5b89-‐86 “Time”: “2011-‐04-‐01T13:01:02.42 “Server”: “A2223E”, “Calling Server”: “A2213W”, “Type”: “E100”, “Initiating User”: “dsallings@spy.net”, “Details”: { “IP”: “10.1.1.22”, “API”: “InsertDVDQueueItem”, “Trace”: “cleansed”, “Tags”: [ “SERVER”, “US-‐West”, “API” ] } }
- 26. Esempio Social Game Profilo Giocatore { "jsonType": "player", "uuid": "35767d02-‐a958-‐4b83-‐8179-‐616816692de1", "name": "Keith4540", "hitpoints": 75, "experience": 663, "level": 4, "loggedIn": false } ID Utente
- 27. Esempio Social Game OggeMo { "jsonType": "item", "name": "Katana_e5890c94-‐11c6-‐65746ce6c560", "uuid": "e5890c94-‐11c6-‐4856-‐a7a6-‐65746ce6c560", "ownerId": "Dale9887" } ID OggeMo ID Utente
- 28. Esempio Social Game Mostro { "jsonType": "monster", "name": "Bauchan9932", "uuid": "d10dfc1b-‐0412-‐4140-‐b4ec-‐affdbf2aa5ec", "hitpoints": 370, "experienceWhenKilled": 52, "itemProbability": 0.5050581341872865 } ID Mostro
- 29. Esempio Blog Diviso su piu’ DocumenC { “UUID”: “21f7f8de-‐8051-‐5b89-‐86 “Time”: “2011-‐04-‐01T13:01:02.42 “Server”: “A2223E”, “Calling Server”: “A2213W”, “Type”: “E100”, “Initiating User”: “dsallings@spy.net”, “Details”: { “IP”: “10.1.1.22”, “API”: “InsertDVDQueueItem”, “Trace”: “cleansed”, “Tags”: [ “SERVER”, “US-‐West”, “API” ] } } { ! “_id”: “Coucbase_Hello_World”,! “author”: “dborkar”, ! “type”: “post”! “title”: “Hello World”,! “format”: “markdown”, ! “body”: “Hello from [Couchbase]( http://couchbase.com).”, ! “html”: “<p>Hello from <a href=“http: …! “comments”:[! ! “comment1_Couchbase_Hello_world”! ! ]! }! { “UUID ”: “2 1 f7 f8 de-‐8 0 5 1 -‐5 b89 -‐8 6 “Time”: “2 0 1 1 -‐0 4 -‐0 1 T1 3 :0 1 :0 2.4 2 “Server”: “A2 2 2 3 E”, “Calling Server”: “A2 2 1 3 W”, “Type”: “E1 0 0 ”, “Initiating Us er”: “ds allings @s py.net”, “D etails ”: { “IP”: “1 0 .1 .1 .2 2 ”, “API”: “Ins ertD VD QueueItem”, “Trace”: “cleans ed”, “Tags ”: [ “SERVER”, “US-‐Wes t”, “API” ] } } {! “_id”: “comment1_Couchbase_Hello_World”,! “format”: “markdown”, ! “body”:”Awesome post!” ! } BLOG COMMENTI
- 30. Esempio: Profilo Utente Database Relazionale Indirizzo Utente 1 DEN 30303 CO 2 MV 94040 CA 3 CHI 60609 IL Informazioni Utente KEY First ZIP_id Last 4 NY 10010 NY 1 DipC 2 Borkar 2 Joe 2 Smith 3 Ali 2 Dodson 4 John 3 Doe ZIP_id CITY ZIP STATE 1 2 2 MV 94040 CA Per oMenere informazioni su un utente specifico, devi effeMuare un JOIN tra due tabelle
- 31. Tub I daC di un utente in un singolo documento { “ID”: 1, “FIRST”: “DipC”, “LAST”: “Borkar”, “ZIP”: “94040”, “CITY”: “MV”, “STATE”: “CA” } JSON = + Esempio: Profilo Utente Database a Documento
- 32. User ID Nome Cognome CAP 1 DipC Borkar 94040 2 Joe Smith 94040 3 Ali Dodson 94040 4 Sarah Gorin NW1 5 Bob Young 30303 6 Nancy Baker 10010 7 Ray Jones 31311 8 Lee Chen V5V3 M • • • 50000 Doug Moore 04252 50001 Mary White SW195 50002 Lisa Clark 12425 ID Paese TEL 3 001 ID Paese Nome Paese 001 USA 002 UK 003 ArgenCna 004 Australia 005 Aruba 006 Austria 007 Brazil 008 Canada 009 Chile • • • 130 Portugal 131 Romania 132 Russia 133 Spain 134 Sweden User ID Foto ID Commento 2 d043 NYC 2 b054 Bday 5 c036 Miami 7 d072 Sunset 5002 e086 Spain Tabella Foto 001 007 001 133 133 User ID Status ID Text 1 a42 At conf 4 b26 excited 5 c32 hockey 12 d83 Go A’s 5000 e34 sailing Tabella Status 134 007 008 001 005 Tabella Paese User ID Affl ID Affl Name 2 a42 Cal 4 b96 USC 7 c14 UW 8 e22 Oxford Tabella Affiliazioni ID Paese 001 001 001 002 ID Paese ID Paese 001 001 002 001 001 001 008 001 002 001 Tabella Utente . . . EffeMuare una Modifica su RDBMS
- 33. Modifiche su un database a documento { “ID”: 1, “FIRST”: “Don”, “LAST”: “Pinto”, “ZIP”: “94040”, “CITY”: “MV”, “STATE”: “CA”, “STATUS”: { “TEXT”: “At Conf” } } “GEO_LOC”: “134” }, “COUNTRY”: ”USA” Basta aggiungere le informazioni sul documento JSON , }
- 34. I Database NoSQL
- 35. Catalogo dei NoSQL Chiave-‐Valore Memcached Redis StruMura DaC Documento Colonna Grafico MongoDB Couchbase Cassandra Cache (memory only) Database (memory/disk) Neo4J
- 36. Couchbase Open Source • Il principale database NoSQL distribuito • Supporta sia le applicazioni chiave-‐valore che a documento • Tun I componenJ sono disponibili con licenza Apache 2.0 Public License • Disponibile come pacche<o sooware sia nella versione Community che in quella Enterprise Couchbase Open Source Project
- 37. ≠
- 38. Scalabilita’ Semplice Performance Elevate e CostanJ Sempre Live 24x365 Ingrandisci il tuo cluster con un click mentre l’applicazione rimane live Tempi di risposta costanJ so<o il millisecondo per operazioni di scri<ura e le<ura L’applicazione non e’ mai inanva anche in caso di aggiornamenJ, manutenzione etc. Modello DaJ Flessibile Supporto per documenJ JSON senza uno schema rigido Principi Chiave di Couchbase Server
- 39. Differenze Principali RispeMo ad Altri Database NoSQL • Perme<e un alJssimo numero di connessioni contemporanee (fondamentale per applicazioni web interanve) • Nessun locks • Cache naJva • Hash parJJoning (non range) à non si formano “hotspots” • Sharding automaJco
- 40. Dietro le Quinte di Couchbase
- 41. 3 3 2 Server Singolo-‐ Operazione ScriMura con Couchbase Managed Cache Disk Queue ReplicaJon Queue App Server Doc 1’ Doc 1 Doc 1’ Doc 1 Doc 1’ Disk To other node Couchbase Server Node
- 42. GET Doc 1 3 3 2 Server Singolo-‐ Operazione LeMura con Couchbase Disk Queue ReplicaJon Queue App Server Doc 1 Doc 1 Doc 1 Managed Cache Disk To other node Couchbase Server Node
- 43. COUCHBASE SERVER CLUSTER Operazioni di Base sul Cluster • Tub I nodi sono uguali e I documenC sono ugualmente distribuiC • Ogni server conCene sia I documenC abvi che quelli replica • La mappa del cluster ha le coordinate su dove si trovano I documenC L’applicazione non ha bisogno di saperlo User Configured Replica Count = 1 READ/WRITE/UPDATE ACTIVE Doc 5 Doc 2 Doc Doc Doc SERVER 1 ACTIVE Doc 4 Doc 7 Doc Doc Doc SERVER 2 Doc 8 ACTIVE Doc 1 Doc 3 Doc Doc Doc REPLICA Doc 4 Doc 1 Doc 8 Doc Doc Doc REPLICA Doc 6 Doc 3 Doc 2 Doc Doc Doc REPLICA Doc 7 Doc 9 Doc 5 Doc Doc Doc SERVER 3 Doc 6 APP SERVER 1 COUCHBASE Client Library CLUSTER MAP COUCHBASE Client Library CLUSTER MAP APP SERVER 2 Doc 9
- 44. Aggiungere Nodi al Cluster • Due servers aggiunC con un solo click • I documenC vengono automaCcamente ribilanciaC aMraverso il cluster Col minimo spostamento di documenJ possibile • La mappa del cluster viene aggiornata • L’applicazione ora e’ supportata da un numero maggiore di servers. REPLICA ACTIVE Doc 5 Doc 2 Doc Doc Doc 4 Doc 1 Doc Doc SERVER 1 REPLICA ACTIVE Doc 4 Doc 7 Doc Doc Doc 6 Doc 3 Doc Doc SERVER 2 REPLICA ACTIVE Doc 1 Doc 3 Doc Doc Doc 7 Doc 9 Doc Doc SERVER 3 SERVER 4 SERVER 5 REPLICA ACTIVE REPLICA ACTIVE Doc Doc 8 Doc Doc 9 Doc Doc 2 Doc Doc 8 Doc Doc 5 Doc Doc 6 READ/WRITE/UPDATE READ/WRITE/UPDATE APP SERVER 1 COUCHBASE Client Library CLUSTER MAP COUCHBASE Client Library CLUSTER MAP APP SERVER 2 COUCHBASE SERVER CLUSTER User Configured Replica Count = 1
- 45. Caduta di un Nodo REPLICA ACTIVE Doc 5 Doc 2 Doc Doc Doc 4 Doc 1 Doc Doc SERVER 1 REPLICA ACTIVE Doc 4 Doc 7 Doc Doc Doc 6 Doc 3 Doc Doc SERVER 2 REPLICA ACTIVE Doc 1 Doc 10 Doc Doc Doc 7 Doc 9 Doc Doc SERVER 3 SERVER 4 SERVER 5 REPLICA ACTIVE REPLICA ACTIVE Doc 9 Doc 8 Doc Doc 6 Doc Doc Doc 5 Doc 10 Doc 2 Doc 8 Doc Doc • I server della app accedono ai daC • Le richieste al Server 3 falliscono • Il Cluster idenCfica che un nodo e’ offline Le repliche vengono promosse ad anve e la mappa del cluster viene aggiornata • Le richieste della app ora si dirigono sul server appropriato • Il tuMo e’ seguito dal ribilanciamento dei daC Doc Doc 1 Doc 3 APP SERVER 1 COUCHBASE Client Library CLUSTER MAP COUCHBASE Client Library CLUSTER MAP APP SERVER 2 User Configured Replica Count = 1 COUCHBASE SERVER CLUSTER
- 46. Cross Data Center ReplicaCon (XDCR) COUCHBASE SERVER CLUSTER NY DATA CENTER ACTIVE Doc Doc 2 SERVER 1 Doc 9 SERVER 2 SERVER 3 RAM Doc Doc Doc ACTIVE Doc Doc Doc RAM ACTIVE Doc Doc Doc RAM DISK Doc Doc Doc DISK Doc Doc Doc DISK COUCHBASE SERVER CLUSTER SF DATA CENTER ACTIVE Doc Doc 2 SERVER 1 Doc 9 SERVER 2 SERVER 3 RAM Doc Doc Doc ACTIVE Doc Doc Doc RAM ACTIVE Doc Doc Doc RAM DISK Doc Doc Doc DISK Doc Doc Doc DISK
- 47. Couchbase Server Admin Console
- 49. Altri Usi Comuni del NoSQL
- 50. Market AdopCon – Customers Internet Companies Enterprises More than 300 customers -‐-‐ 5,000 producCon deployments worldwide
- 51. CaraMerisCche dei DaC • StruMura definita dall’utente (TwiMer feeds) • Serve supporto per crescita esponenziale (Apps virali) • StruMura dei daC non omogenea • C’e’ necessita’ di cambiare struMura frequentemente • Lunghezza dei documenC variabile • StruMura dei daC gerarchica Couchbase e’ la scelta ideale
- 52. RequisiC di Performance • Latenze estremamente basse (es. 1millisecondo) • Traffici elevaC (es. 200000 ops/sec) • Numero di utenC elevato • Domanda non prevenCvabile con crescite improvvise • C’e’ predominanza di accesso direMo ai documenC • Alto traffico in leMura e scriMura Couchbase e’ la scelta ideale
- 53. Applicazioni Comuni Social Gaming • Couchbase conJene I daJ sugli utenJ e I giochi • Esempi clienJ: Zynga, Tapjoy, Ubisoo, Tencent Apps Mobili • Couchbase conJene daJ su utenJ e contenuJ • Esempi clienJ: Kobo, PlayJka Pubblicita’ Online • Couchbase conJene info sugli utenJ per un accesso veloce • Esempi clienJ: AOL, Mediamind, Convertro Informazioni di Sessione • Couchbase come database chiave-‐valore • Esempi clienJ: Concur, Sabre Profili UtenC • Couchbase come database chiave-‐valore • Esempi clienJ: Tunewiki Cache ad Alta Disponibilita’ • Couchbase uJlizzato come livello di cache • Esempi clienJ: Orbitz Metadata e ContenuC • Couchbase insieme ad ElasJcsearch • Esempi clienJ: McGraw Hill Aggregazione DaC • Couchbase aggrega I daJ dai social media • Esempi clienJ: Sambacloud
- 54. • Informazioni sui profili utenC • Informazioni di registrazione • Nomi utenC e password Profili UtenC Esempio d’uso: Profili UtenC Accesso chiave-‐valore con le seguenC caraMerisCche: • Alta consistenza • Scalabilita’ per gesCre cenCnaia di milioni di utenC • Il sistema dev’essere sempre live 24x7x365 • Alta consistenza a livello del cluster. • Il cluster puo’ essere allargato o ristreMo per supportare la crescita esponenziale di utenC • Il cluster dev’essere disponibile 24/365. Con Couchbase tuMe le operazioni di manutenzione, aggiornamento e riparazione vengono effeMuate lasciando l’applicazione live. Grazie al cross datacenter replicaCon e’possibile collegare due centri daC diversi per ridurre I rischi di perdita daC e per una maggiore prossimita’ agli utenC Tipologia di DaC RequisiC dell’applicazione Perche’ NoSQL e Couchbase h<p://blog.couchbase.com/couchbase-‐nosql-‐tunewiki-‐billion-‐ documents-‐and-‐counJng
- 55. • Preferenze utenC e daC psicografici • Cronologia delle ricerche • Cronologia delle parole chiave acquistate dall’azienda • Cronologia delle pubblicita’ visualizzate Pubblicita’ Online Esempio d’uso: Pubblicita’ Online • Alte performance per soddisfare I tempi ristrebssimi degli utenC (soMo I 40ms in totale) • Scalabilita’ per sostenere traffici elevaC e cenCnaia di milioni di utenC • Sistema disponibile 24x7x365 per evitare perdite di guadagni • Accesso ai daC in meno di un millisecondo costante, lasciando quindi piu’ tempo per l’analisi • Facilita’ a scalare il cluster a cenCnaia di servers se necessario • Il cluster rimarra’ sempre live e disponibile, evitando quindi perdite di profib.. Tipologia di DaC RequisiC dell’Applicazione Perche’ NoSQL e Couchbase h<p://www.couchbase.com/ad_platorms
- 56. • Oggeb dell’applicazione • RisultaC delle ricerche • Informazioni di sessione • Pagine web ad alto uClizzo • Metadata Cache ad alta disponibilita’ Esempio d’uso: Cache ad Alta Disponibilita’ • Tempi di risposta brevissimi e costanC • Alta disponibilita’-‐ 24x7x365 • Facile da gesCre mantenendo l’applicazione sempre live • SosCtuisce l’intero livello di caching • Basse latenze (soMo il millisecondo) e prestazioni costanC e prevedibili • TuMe le operazioni possono essere effeMuate lasciando live l’applicazione • CompaCbile con memcached. La migrazione a Couchbase viene effeMuata lasciando intaMa l’applicazione • Alta disponibilita’ con repliche all’interno del cluster e all’esterno (XDCR) per essere garanCC anche in caso di disastri Tipologia di daC RequisiC dell’applicazione Perche’ NoSQL e Couchbase h<p://www.couchbase.com/memcached
- 57. QuesCons?
- 58. Demo
- 59. Non dimenCcate di……… Scaricare e fare praCca con Couchbase Server hMp://www.couchbase.com/download Iscrivervi sul gruppo di Couchbase Italia su LinkedIn hMp://www.linkedin.com/groups/Couchbase-‐Italia-‐4932288 Iscrivervi sul nostro Community Portal hMp://www.couchbase.com/communiCes/user/register
- 60. Grazie a Tub! franco@couchbase.com