Answers: <p>I don't know much about Redis/ElasticSearch, but GCS is not really a database-like solution, it is closer to a file storage solution.</p>
  
  <p>If you're looking for database-like storage Google Cloud offers:</p>
  
  <ul>
  <li><a href="https://cloud.google.com/sql/" rel="nofollow noreferrer">Cloud SQL</a></li>
  <li><a href="https://cloud.google.com/bigtable/" rel="nofollow noreferrer">Cloud Bigtable</a></li>
  <li><a href="https://cloud.google.com/datastore/" rel="nofollow noreferrer">Cloud Datastore</a></li>
  <li><a href="https://cloud.google.com/spanner/" rel="nofollow noreferrer">Cloud Spanner</a></li>
  </ul>
  
  <p>If you expect a modest app traffic or alternating high/low traffic it <em>might</em> be more cost-effective (and simpler) to have a <a href="https://cloud.google.com/appengine/docs/" rel="nofollow noreferrer">Google App Engine</a> app instead of a GCE-based solution.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-09T20:35:35.373Z
Answers: 2017-12-29T08:55:22.347Z
Answers: 2017-12-29T08:55:22.347Z
Answers: Dan Cornilescu
Answers: <p>We had the similar requirement as there needs to be a set of data cached in a server for serving the application (fast processing) and also by end of the day, we would need to sync the data from the cache server to the origin server.</p>
  
  <p>In the longer run, I would suggest to go for Redis as you can have Redis as an intermediate database (caching) and it will help you in scaling.</p>
  
  <p>You can write scripts to run at an interval or at specific time of the day so that you can pull/push the data from the origin server (external application).</p>
  
  <p>Your requirement wouldn't require Elastic Search at any point of time as it will help you in speeding up search results based on caching, it is just a search engine.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-01T08:28:05.793Z
Answers: 2018-01-18T10:25:47.417Z
Answers: 2018-01-18T10:25:47.417Z
Answers: Gopi Haran
Body: <p>We're building an application that reads data from an API and displays it in a frontend. Due to API limits, we have to cache the API calls meaning that we save the result of the API calls (both user information (first name, country, email etc.) and big sets of activity log data) in a database and only request new data from the API if the stored data is older than x hours.</p>
  
  <p>This application should also work for multiple users that can log in and see their relevant data. For each user, the application connects to a different API endpoint (e.g. "user1.api.com/data/whatever" and "user2.api.com/data/whatever").</p>
  
  <p>So, in the end there will be two databases. One for caching the API calls of an external tool and another one for the application's user management. However, we are not sure what would be best to use.</p>
  
  <p>Is it generally a good idea to use cloud databases for either caching or user management? As the application will run on Google Container Engine, we could probably use Google Cloud Storage (for caching) and Firebase (for user management). Or should we rather use something like Redis / ElasticSearch (for caching) and something different for the different user data?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-01-01T09:22:40.870Z
Comments: This is the modern version of the tried and true question: "My code is simple, why cannot I just use a filesystem as a database?"
Comments: Jiri Klouda
Tags: <databases><google-cloud-platform><google-cloud-storage>
Title: Google Cloud Storage vs Redis / ElasticSearch
UserDisplayName: mrksbnch
ThreadText: # Google Cloud Storage vs Redis / ElasticSearch
  
  (Asked by: username_0 on 2017-04-09)
  
  We're building an application that reads data from an API and displays it in a frontend. Due to API limits, we have to cache the API calls meaning that we save the result of the API calls (both user information (first name, country, email etc.) and big sets of activity log data) in a database and only request new data from the API if the stored data is older than x hours.
  
  This application should also work for multiple users that can log in and see their relevant data. For each user, the application connects to a different API endpoint (e.g. "user1.api.com/data/whatever" and "user2.api.com/data/whatever").
  
  So, in the end there will be two databases. One for caching the API calls of an external tool and another one for the application's user management. However, we are not sure what would be best to use.
  
  Is it generally a good idea to use cloud databases for either caching or user management? As the application will run on Google Container Engine, we could probably use Google Cloud Storage (for caching) and Firebase (for user management). Or should we rather use something like Redis / ElasticSearch (for caching) and something different for the different user data?
  
  **Tags:** databases, google-cloud-platform, google-cloud-storage
  
  > **Comments:**
  > **username_1**: This is the modern version of the tried and true question: "My code is simple, why cannot I just use a filesystem as a database?"  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-04-09. Score: 4 | Accepted answer
  
  I don't know much about Redis/ElasticSearch, but GCS is not really a database-like solution, it is closer to a file storage solution.
  
  If you're looking for database-like storage Google Cloud offers:
  
  * [Cloud SQL](https://cloud.google.com/sql/)
  * [Cloud Bigtable](https://cloud.google.com/bigtable/)
  * [Cloud Datastore](https://cloud.google.com/datastore/)
  * [Cloud Spanner](https://cloud.google.com/spanner/)
  
  If you expect a modest app traffic or alternating high/low traffic it *might* be more cost-effective (and simpler) to have a [Google App Engine](https://cloud.google.com/appengine/docs/) app instead of a GCE-based solution.
  
  
  ---
  
  ### Answer by username_3 on 2018-01-01. Score: 2
  
  We had the similar requirement as there needs to be a set of data cached in a server for serving the application (fast processing) and also by end of the day, we would need to sync the data from the cache server to the origin server.
  
  In the longer run, I would suggest to go for Redis as you can have Redis as an intermediate database (caching) and it will help you in scaling.
  
  You can write scripts to run at an interval or at specific time of the day so that you can pull/push the data from the origin server (external application).
  
  Your requirement wouldn't require Elastic Search at any point of time as it will help you in speeding up search results based on caching, it is just a search engine.
  
  
  ---
  
  