Mentre stiamo sviluppando un'applicazione avida di monitoraggio in tempo reale su Meteor, abbiamo raggiunto il limite della nostra singola istanza MongoDB.Come configurare Meteor Oplog Tailing su un DB Mongo Sharded
Abbiamo migrato il DB in un cluster con 2 shard per ora, ma potremmo espandere fino a 6 frammenti. (Ho 2 chassis BladeE con 28 server)
Come configurare Meteor Oplog Tailing su un cluster mongo db con sharding abilitato?
Grazie,
Sembra Meteor non supporta ancora messe a punto MongoDB sharded con> 1 frammento: https://forums.meteor.com/t/mongodb-sharding-and-livequery/3712
ora c'è una buona notizia :) È possibile utilizzare il database MongoDB sharded con Meteor facilmente con un un po 'di tweaking
Sebbene il team di sviluppo di base di Meteor non abbia ancora aggiunto il supporto di Oplog Tailing per la condivisione a their RoadMap, la soluzione è così semplice. Devi solo aggiungere questi 2 pacchetti di Meteor: cultofcoders:redis-oplog e disable-oplog, aggiungere un altro server Redis, modificare leggermente il tuo codice e sei a posto.
Il motivo per cui Oplog Tailing non funziona con il database MongoDB non è solo perché il team di sviluppo principale non ha ancora pianificato di supportarlo. In effetti, ora è possibile aggiungere supporto per database più grandi. Se si aggiungono nuovi record e si leggono gli Oplog con cursori di tutti i frammenti, si noterà che il bilanciamento MognoDB sposta i dati, diciamo, da shard01 a shard02 dove ID record 0001 è stato rimosso da shard01 e aggiunto a shard02. Questa situazione sembra essere fonte di confusione per Meteor in quanto non sa se i record vengono effettivamente rimossi/aggiunti dagli utenti o dal sistema di bilanciamento di MongoDB. Tuttavia c'è un modo per sapere se gli utenti o il bilanciatore MongoDB hanno rimosso/aggiunto i dati perché possiamo distinguere per il flag fromMigrate - leggi di più al riguardo allo MongoDB official site blog - quindi quello che possiamo fare per ora è aspettare l'aggiornamento dal team di sviluppo principale o lavorare in giro con pochi trucchi.
E il trucco più promettente che ho trovato finora è il pacchetto Meteor chiamato cultofcoders:redis-oplog. È opensource e disponibile su Github (Si prega di controllare il loro repository per la documentazione completa. È molto facile da usare). L'idea alla base di questo pacchetto è quella di utilizzare un altro server e sub per il server Redis: non memorizza alcun dato. è solo per pub e sub - invece di Meteor che fanno molto affidamento su Oplog. In questo modo, non ci dobbiamo preoccupare di Oplog per il database sharded che Meteor non ha ancora supportato. Redis è maturo ed è stato utilizzato nella produzione da molte grandi aziende. È completamente compatibile con Meteor e non devi cambiare il modo in cui usi Meteor. Tuttavia, è necessario modificare leggermente il codice durante l'aggiornamento dei dati della raccolta per pubblicare le modifiche su Redis, quindi il pacchetto cultofcoders:redis-oplog gestirà il resto.
In realtà ho provato questo. Ho aggiunto un DB su MongoDB Atlas e ho usato 'redis-oplog'. 'redis-oplog' ha funzionato davvero e le cose sono rimaste scattanti e reattive, MA non ho misurato un aumento delle prestazioni di Mongo. Quindi non penso che Meteor stia lavorando correttamente con i frammenti. Ho aggiunto il 7 shard URL a Meteor (che sembra un normale URL Mongo con 7 URL invece di 3). La mia app era un collo di bottiglia a livello di Mongo (visibile in Meteor APM (Kadira)) ei risultati erano ancora gli stessi dopo il sharding. Quindi non sono sicuro che funzioni correttamente. – evolross
@evolross Non penso che tu debba aggiungere 7 URL di shard MongoDB all'app Meteor.Hai provato ad aggiungere l'URL di 'mongos' a' env' invece di uno shards? Il sito ufficiale di MongoDB ha affermato che dovremmo connetterci a 'mongos' per interagire con il database sharded ed evitare di interagire direttamente con i shard. Per quanto riguarda il collo di bottiglia a livello di MongoDB, non penso che sia un problema con Meteor. È molto probabile che tu abbia dimenticato di aggiungere gli indici necessari o di aver dimenticato di passare 'chiave shard' nelle query che inducono MongoDB a interrogare ogni singolo documento su tutti i frammenti ... e qui arriva un problema di prestazioni. –
C'è qualcosa nei documenti di Meteor su 'shard key' o' mongos'? L'hai presa a lavoro personalmente e puoi provare che i frammenti funzionavano? E ho tutti i miei indici e ho scritto molti argomenti nei forum di Meteor sull'ottimizzazione. È il modo in cui funziona la mia app e la quantità di utenti che ho contemporaneamente. – evolross