Fai del 2014 l'anno in cui imparare qualcosa di nuovo. Unisciti alla nostra serie di webinar in 8 parti e scopri quanto è facile sviluppare applicazioni con MongoDB. Le sessioni, tenute dai nostri Solutions Architects, vi insegneranno le basi dalla A alla Z, condivideranno le best practice e i trucchi per partire con confidenza. Le sessioni saranno completamente in italiano.
A questo punto avremo fatto l’applicazione. Ora dobbiamo metterla in produzione. Illustreremo le varie architetture per l’alta affidabilità e per la scalabilità orizzontale.
La serie comprende le seguenti sessioni:
10 Giugno 2014 Serie Operazioni per la vostra applicazione - Sessione 7 - Backup e Disaster Recovery:
Questo webinar parlerà delle varie opzioni di backup e di restore. Impara cosa dovresti fare in caso di un guasto e come effettuare le operazioni di backup e recovery dai dati nelle vostre applicazioni.
17 Giugno 2014: Serie Operazioni per la vostra applicazione - Sessione 8 - Monitoraggio e Performance Tuning:
L’ultimo webinar della serie discuterà quali metriche sono importanti e come gestire e monitorare la vostra applicazione per migliorare le performance.
Massimo Brignoli: About the speaker
Massimo ha 44 anni e vive a Milano. Ha lavorato nell’IT per 23 anni per aziende di trasporti, società web e database company. Nel 1998 è entrato una una piccola startup come sviluppatore aiutandola a diventare il più importante portale web italiano, venduto 3 anni più tardi per 700 milioni di dollari. E’ entrato a lavorare in MySQL come pre-vendita viaggiando in tutto il mondo e aiutando le società telecom ad adottare MySQL Cluster. Nel 2012 è entrato in SkySQL come product manager, seguendo l’integrazione con MariaDB e successivamente ha deciso di entrare in MongoDB per seguire nuove sfide professionali. Attualmente e’ Senior Solutions Architect.
2. Agenda
• Replica Sets Lifecycle
• Developing with Replica Sets
• Scaling your database
3. Q&A
• Virtual Genius Bar
– Use chat to post questions
– EMEASolution
Architecture / Support
Team are on hand
– Make use of them during
the sessions!!!
4. Recap
• Introduction to MongoDB
• Schema design
• Interacting with the database
• Indexing
• Analytics
– Map Reduce
– Aggregation Framework
7. Why Replication?
• How many have faced node failures?
• How many have been woken up from sleep to do a
fail-over(s)?
• How many have experienced issues due to network
latency?
• Different uses for data
– Normal processing
– Simple analytics
23. Tagging
• Control where data is written to, and read from
• Each member can have one or more tags
– tags: {dc: "ny"}
– tags: {dc: "ny", subnet: "192.168", rack:
"row3rk7"}
• Replica set defines rules for write concerns
• Rules can change without changing app code
26. Read Preference Modes
• 5 modes
– primary (only) - Default
– primaryPreferred
– secondary
– secondaryPreferred
– Nearest
When more than one node is possible, closest node is used
for reads (all modes but primary)
27. Tagged Read Preference
• Custom read preferences
• Control where you read from by (node) tags
– E.g. { "disk": "ssd", "use": "reporting" }
• Use in conjunction with standard read
preferences
– Except primary
28. • SAFE writes acceptable for our use case
• Potential to use secondary reads for
comments, but probably not needed
• Use tagged reads for analytics
Our application
60. Shard Key
• Shard key is immutable
• Shard key values are immutable
• Shard key must be indexed
• Shard key limited to 512 bytes in size
• Shard key used to route queries
– Choose a field commonly used in queries
• Only shard key can be unique across shards
– `_id` field is only unique within individual shard
61. A suitable shard key for our app…
• Occurs in most queries
• Routes to each shard
• Is granular enough to not exceed 64MB chunks
• Any candidates?
– Author?
– Date?
– _id?
– Title?
– Author & Date?
Initialize -> Election
Primary + data replication from primary to secondary
Primary down/network failure
Automatic election of new primary if majority exists
New primary elected
Replication established from new primary
Down node comes up
Rejoins sets
Recovery and then secondary
Consistency
Write preferences
Read preferences
Not really fire and forget.
This return arrow is to confirm that the network successfully transferred the packet(s) of data.
This confirms that the TCP ACK response was received.
The mongos does not have to load the whole set into memory since each shard sorts locally. The mongos can just getMore from the shards as needed and incrementally return the results to the client.
_id could be unique across shards if used as shard key.
we could only guarantee uniqueness of (any) attributes if the keys are used as shard keys with unique attribute equals true