I have a GAE application in US Central (say Project A) and another GAE application in US East1 (say Project B). I want one Stackdriver dashboard to monitor these two together. Hence I merged Project B onto Project A's workspace which is in Central. Now I have a merged dashboard.
Question - Assume a scenario when US central region went down and my project A workspace is not available. Will this make my merged dashboard completely unavailable (including east region monitoring too)?
Stackdriver Monitoring is a global service and is designed to survive outages in a given region or zone. While an outage in a given region or zone could impact ingesting time-series data in that region/zone, your workspace configuration (including dashboards, alerting policies, etc.) should be available even with such an outage. Alerting policies that do not perform a cross-series aggregation across different locations should continue working and firing alerts when there is a regional outage (policies that aggregate time-series across locations may, however, malfunction in such situations). It should be noted that the underlying time-series database and alert delivery infrastructure that underlies Stackdriver Monitoring is also used for Google's own internal monitoring and is relied on by Google SRE teams to be notified of outages in Google's own systems, including outages caused by zones or regions being taken offline by fiber cuts, disasters, and other issues.
Related
when I create a project in firebase, I am offered to choose analytics location
When you click on the question mark, they write: "This represents the country/region of your organization. This does not affect where Google may process and store Customer Data for Firebase."
Question: If I want to upload an application to the appstore for different countries, for example, America, Russia and European countries, then I will have to connect several firebase projects for different countries at once? How can I connect one firebase for all countries?
Not sure but it seems you are mixing up things.
When setting up services on your Google Cloud Project, you may choose their location, this means that the service you are activating will be hosted on a specific place, and thus people from other countries may have bigger latency accessing your services. Example, if you host a service in North America, the latency for users from Asia will be higher.
That will not geographically restrict or limit users to access your service, web app, or API services.
If you want to restrict users from specific countries from downloading your app, on the app store you have settings that will do that for you.
The short answer: no, you don't need multiple projects for multiple countries.
I have a Dockerized API service destined to run using Cloud Run. The service is backed by Firestore. It's a startup project aimed at English speaking customers most likely US and UK.
In the follow article (https://cloud.google.com/solutions/best-practices-compute-engine-region-selection) it says "For a global user base, deploy in a region in the US".
Hosting the API Service and Firestore in the same region seems to make sense. In the article it says "Estimate 1 ms of round-trip latency for every 100 km traveled". Based on that, I would pick the East side of the US because that's nearer on the map to the UK. I assume the undersea cables terminate at the coast. However, maybe the UK is linked directly to another part of the US. What particular region within the US that would be most suitable and how do you arrive at this? (does it even matter?)
If I use HERE's Android SDK and preload map data to the device storage,
do I need to reload these data every n days?
We are operating a demand responsive transport system in an area with poor cellular coverage. Having to relocate the cars periodically to some designated wifi access point would be inconvenient and integrating our vehicle dispatcher algorithm with off-the-shelve SatNavs is just not possible.
No, offline data is not expiring, nor needs to be refreshed.
If you are using also online services (and don't operate fully offline) it might happen that some online services (e.g. online routing, traffic, online search) respond with no or bad results with older mapdata (mostly something older than a year). So, if you also have online usecases, please consider a mapupdate every half a year.
Also keep in mind, that outdated mapdata might cause a bad user experience with newly build roads or changed road networks.
I know scalability is not an issue in Firebase and supports up to 100k Simultaneous connections(in general).
Based on pricing documentation:
You can create multiple database instances to go beyond the 100K
concurrent limit. See Pricing FAQ for more information.
Question 1: What if there is more than 200k users using simultaneously on the same database? The other half of the users could not query, connect or the request will be placed in queue?
(As a Firebase plan subscriber, I would like to know how Firebase deals with the problem to ensure the quality of the services provided to our customers are always in top-notch)
Since, App globalisation is common nowadays and many companies' practices are to have servers across multiple regions to provide better and stable performance. Online game for example which required low latency.
As for now, the firebase user is required to set the default location when creating the project which is non-editable afterward. Some issues even rises where the users realised they deployed their app to the wrong regions and do not have clues on how to change the regions.
This represents the country/region of your organisation/company. Your
selection also sets the appropriate currency for your revenue
reporting. The selected country does not determine the location of
your data for Firebase features. Google may process and store Customer
Data anywhere Google or its agents maintain facilities.
Question 2: Will or does Firebase provide a solution / tailor-made to such practice which having our database in multiple regions while having a headquartered region and multiple other regions sharing all the databases, functions and auth across the regions?
(For now to have multiple servers location, we have to create different projects and the user and data syncing will be a problem)
Hope the language does not offend, cheers!
It seems like your question (or at least your assumptions) is based on the Firebase Realtime Database, so I'll answer for that below.
Q1) You can create more than 2 databases in a single project, each of which allows 100K connections. So it can scale beyond 200K connections. All of these are hosted in the same region though, so you can't use each database for a separate region.
Q2) For a database solution that handles multiple regions, I'd recommend looking at Cloud Firestore. Also see: Cloud Firestore - selecting region to store data?
I've been putting together a mechanism to sync activity data collected by the MS Band with our backend via the cloud API and getting all the boilerplate setup for the OAuth flows... The intent being to periodically run this data through our backend processes to categorise periods of meaningful walk based activity.
I've been experimenting with the data available and as far as I can tell we cannot get access to the raw step data (or at a fine grained level )? We have successfully been able to request summary info by hour/day, however this is not fit for our purpose.
What I'd like is to access step data in the form [startTimeStamp,endTimeStamp,stepsTaken,...] where each record represents a continuous period of movement by the wearer.
We would also be able to work with data summarised by minute as this would give enough context to our use case.
Is this possible via the cloud API? or are there any plans to implement the Period "Minute" on the summary API endpoint?
https://api.microsofthealth.net/v1/me/Summaries/Minute?startTime=2015-12-09T14%3A00%3A00.369Z
If this isn't possible perhaps there is another way to make this data available? (via HealthKit on iOS or Fit on Android?)
As a complete alternate perhaps it might be possible to get the accumulated step data detail from the band via bluetooth in a similar fashion to the native MS Health App?
We already use the SDK to stream realtime Heart Rate data during user cardio sessions, but there appears to be no way to extract the historical step info from the band directly.
Thanks!
the Band itself monitors and logs the steps over time. When sync'ing, that log is transferred to the Cloud via the Microsoft Health app. The app then pulls the "steps for the day" from the Health service.
These logs are not exposed to apps via the SDK. The only way to calculate steps per custom short period yourself is to have your app sample the counter in the background on a frequent enough basis in order to do the calculation.