3 ms·

Expanding MongoDB Atlas Availability on GCP

86 points by jaydestro 9y ago

neals 9y ago
So how do people use that? (I don't work with large databases like this) Say, a user comes to a website from New York. Does this require me to have a webserver (probably google cloud-something) in New York that connects to this region MongoDB Atlas? Is the data of this user then also available in, say, Hong Kong? Do I need to connect certain region MongoDB's to certain region servers?
- andrewbarba 9y ago
  I can only speak for MongoDB (and I use Atlas extensively), but in your example I would have two connections open to the MongoDB cluster on each web node (no matter where it's deployed). One connection would connect to the primary and handle all writes. The other connection would use the option "readPreference=nearest" which will connect to the geographically closest replica node. https://docs.mongodb.com/manual/reference/read-preference/#nearest https://docs.mongodb.com/manual/reference/read-preference/#n... Edit: Looks like you can also tag the region your nodes are in and specify those tags directly, pretty neat. https://docs.mongodb.com/manual/reference/read-preference/#query-from-geographically-distributed-members https://docs.mongodb.com/manual/reference/read-preference/#q...
- redwood 9y ago
  Users run application instances that sit between their end users (clients) and the database itself. These application instances are what a client’s browser (or mobile app, IoT device, etc) interact with. The application in turn connects to the database. Many users start simple, and run their application instances in only one region, with the database in that region as well. However, by spreading the database across three regions, the database itself can actually maintain availability (reads and writes continue) even if there is a region-wide outage due to MongoDB’s built in replication and auto-failover. Developers can run their application instances in multiple regions and serve nearby clients from them, and achieve low-latency in-region reads to MongoDB cluster replicas in those regions. In this model, writes would go to the region with the MongoDB database primary, however, meaning users in some regions would have a cross-region network hop in order to perform writes. MongoDB does have a concept called geo-zoned sharding, however, which makes it possible to have different write regions for different shards, which makes it possible to have users in different parts of the world actually achieve low latency reads and writes.
ko27 9y ago
Is there a single Amazon or Google server in East Europe?
- advisedwang 9y ago
  GCP is planning a Finland Region[1], which has direct link to PoPs in Moscow, Warsaw, Kiev and St Petersburg and indirect links to PoPs in Prague, Budapest and Sofia[2]. AWS is planning a Sweden Region[3] with edge locations in Finland, Prague and Warsaw. [1] https://cloud.google.com/about/locations/#regions-tab https://cloud.google.com/about/locations/#regions-tab [2] https://cloud.google.com/about/locations/#network-tab https://cloud.google.com/about/locations/#network-tab [3] https://aws.amazon.com/about-aws/global-infrastructure/ https://aws.amazon.com/about-aws/global-infrastructure/

86 points by jaydestro 9y ago

So how do people use that? (I don't work with large databases like this) Say, a user comes to a website from New York. Does this require me to have a webserver (probably google cloud-something) in New York that connects to this region MongoDB Atlas? Is the data of this user then also available in, say, Hong Kong? Do I need to connect certain region MongoDB's to certain region servers?

andrewbarba 9y ago
I can only speak for MongoDB (and I use Atlas extensively), but in your example I would have two connections open to the MongoDB cluster on each web node (no matter where it's deployed). One connection would connect to the primary and handle all writes. The other connection would use the option "readPreference=nearest" which will connect to the geographically closest replica node. https://docs.mongodb.com/manual/reference/read-preference/#nearest https://docs.mongodb.com/manual/reference/read-preference/#n... Edit: Looks like you can also tag the region your nodes are in and specify those tags directly, pretty neat. https://docs.mongodb.com/manual/reference/read-preference/#query-from-geographically-distributed-members https://docs.mongodb.com/manual/reference/read-preference/#q...
redwood 9y ago
Users run application instances that sit between their end users (clients) and the database itself. These application instances are what a client’s browser (or mobile app, IoT device, etc) interact with. The application in turn connects to the database. Many users start simple, and run their application instances in only one region, with the database in that region as well. However, by spreading the database across three regions, the database itself can actually maintain availability (reads and writes continue) even if there is a region-wide outage due to MongoDB’s built in replication and auto-failover. Developers can run their application instances in multiple regions and serve nearby clients from them, and achieve low-latency in-region reads to MongoDB cluster replicas in those regions. In this model, writes would go to the region with the MongoDB database primary, however, meaning users in some regions would have a cross-region network hop in order to perform writes. MongoDB does have a concept called geo-zoned sharding, however, which makes it possible to have different write regions for different shards, which makes it possible to have users in different parts of the world actually achieve low latency reads and writes.

ko27 9y ago

Is there a single Amazon or Google server in East Europe?

advisedwang 9y ago
GCP is planning a Finland Region[1], which has direct link to PoPs in Moscow, Warsaw, Kiev and St Petersburg and indirect links to PoPs in Prague, Budapest and Sofia[2]. AWS is planning a Sweden Region[3] with edge locations in Finland, Prague and Warsaw. [1] https://cloud.google.com/about/locations/#regions-tab https://cloud.google.com/about/locations/#regions-tab [2] https://cloud.google.com/about/locations/#network-tab https://cloud.google.com/about/locations/#network-tab [3] https://aws.amazon.com/about-aws/global-infrastructure/ https://aws.amazon.com/about-aws/global-infrastructure/