I have to create an RDBMS table on Google cloud that supports multilingual data. Do we have a service on google cloud for that? CloudSQL or CloudSpanner?
This is for storing movie titles data from different countries and do some querying on the data.
I expect that I can do queries on the data that is stored. For example: Do a DISTINCT on the movie titles and it should list all different movie titles from various countries (Ex: I have chinese movie titles, Russian movie titles).
In both Google Cloud SQL and Google Cloud Spanner you are able to store multilingual data and do queries with “DISTINCT” or something else. So, you choose the service that will serve your purpose in a better and more effective way.
Cloud SQL is a fully managed relation database service.
Cloud Spanner is a fully managed, scalable, relational database
service for regional and global application data.
You can find more information about the use cases of Cloud SQL and Cloud Spanner in Google’s documentation.
Related
I am building an app that allows people to share items with other people in the community. I wanted to use AWS as my platform.
My idea was to use react Native for the app. AWS Cognito for the authentication. AWS lambda for the server calls. Relational database for storing data about the items and user data such as geolocation. Dynamodb for real-time chat, requests for borrowing and transaction data between users. My primary focus is low cost and I was thinking of using PostgresSQL for relational database.
What do you guys think of my database choices. Of course the PostgresSQL database on rds. Is there a flaw in database plan so far? Any help would be greatly appreciated.
I would probably just use DynamoDB for everything in your application. I don't see a real need to storing some of your data in an RDS database here. However if you definitely need a relational database, I would suggest AWS Aurora Serverless so that your entire application would be using serverless AWS services. Also, normal relational database connection pools don't work that well in AWS Lambda, so I would suggest using the new Data API.
I would like to use Bluemix to create an IBM Watson search engine (i.e. similar to a Google Search Engine interface) that will query either the internet (websites I specify) or online database and provide summaries of unstructured data, identify concepts, etc.
Are there any existing apps like this available or does anyone know how this can be setup with Bluemix or another platform?
You should take a look at the Alchemy API service on Bluemix.
It allows you to do things like extract entities and keywords.
Most of the APIs allow you to feed them html, text or web-based content. Stringing a bunch of these together and tagging content in a database such as Elasticsearch should allow you to achieve what you're after.
Hard to be too specific given the fairly broad nature of your question.
I have organized, non-relational data that is in both file system and SQL database. There is application that queries both sources.
What would be some cloud solutions for storing this data, which equates to about 1TB? I'd like to be able to migrate this data into the cloud solution and alter the application to query the data in the cloud.
So far, I've looked at AWS options: SimpleDB, DynamoDB, and MongoDB on an EC2 Intance with EBS for increased storage.
I've also looked into Azure's Table Storage.
SimpleDB has a 10GB limit. DynamoDB is on SSD and might be overkill for my needs. Did I miss something? Are MongoDB on AWS or Azure Table storage suitable options?
I think the solution depends heavily on your data access patterns.
I've used Azure Table Storage and it's great for many things. I've used DynamoDB and it's also good for quite a few things. Both are good table stores, but both have restrictions around read indexes, querying, and transactions. That's sometimes a show stopper. Both will require retooling your data and all the dependent applications.
For your file storage:
(Cheapest, slowest) Migrate your files to a blob store (Azure Blob Storage or AWS S3) and leave them there. Use S3 as a drive for file access. This is slow, but cheap.
(Performant) Use an EC2 instance with EBS drives and store your files there. Access the data on the local file system. This is durable and performant.
For your relational data, leave it relational and store it in a Cloud relational database server. (RDS+MySQL, RDS+SQL Server, SQL Azure, etc).
There's no need to change your applications, and their data patterns, moving to the cloud.
I'm trying to create a back-end in which I can have many users communicate with each other amongst an iPhone app I'm creating. I've tried working with Core Data, Google App Engine, Google Cloud Storage, and Amazon Web Services (RDS & Elastic Beanstalk). Unfortunately, after weeks of trying to get any of this working, none of it will!
I've been trying to get in touch with someone who would know how startups (when they were little) like Instagram, Path, and Pinterest have managed to do this. But everyone out there seems to despise this stuff as much as I'm growing to...
I would love for someone to simply map out EXACTLY how I need to create a back-end database that I can save and query data to and from that many users can see. That means that just SQLite, Core Data, or Parse by itself isn't going to work here!
A tutorial of some kind would be incredible.
First off, technologies like CoreData and sqlite are typically local device storage. Local device storage is not going to get you shared cloud storage.
Parse.com is a fast way for devices to access cloud storage and get going fast. Especially useful for games and other mobile apps to access cloud data via an app id and app key. It's simple storage to avoid creating your own backend if it fills all your needs and requirements.
When you get to a multi-tenant cloud backend where you roll your own services and multiple devices accessing your cloud application you need to look into exposing your web API. Exposing RESTful API over http is great for devices and web clients. Exposing the data as JSON is especially conventient for the web and easily consumed by devices.
Those web service end points in the cloud access some sort of backend storage which is optimized for concurrent access by mutliple clients. This is typically a SQL backend like MySQL, SQLServer etc... or a NoSQL solution like mongodb, couchDB, etc...
Some front end web api technologies to look into:
ASP.net web api
Ruby on Rails
Node.js
etc...
Some back end storage technologies to look into:
SQL: MySQL, SQLServer/Azure SQL, Oracle
NoSQL: MongoDb, CouchDb, Amazon S3 simple storage, etc...
If the data is used by many many multi-tenant clients, the backends can scaled up (larger and larger) or get sharded. Sharding is where the data for multiple users is split into many databases or datastores with some sort of lookup algorithm for requests to find where that users data is stored. The front end web api servers abstract the backend storage.
Finally, you'll end up needing some sort of caching/fast lookup technology (if you're successful :):
Redis: fast in memory storage over sockets
memcached: facebook uses - simple key value in memory caching across many front end servers.
Your question is an open ended up broad question so start by googling many of these terms and technologies.
Each of these links will have resources and tutorials. Get a cloud VM, play with each and decide which fits your needs best. There is no one size fits all solution.
I'm starting on some architecture work for a .Net based social networking application to be hosted on Azure cloud. we are going to be using ASP.NET MVC on the front end.
i would like to consider the options for storage. considering scalability needs and due to the inter-connected nature of the application, SQL azure has been ruled out.
what would be the main considerations in choosing a graph DB such as Sones GraphDB or neo4j which have features specific for a social networking application against using windows azure table storage to achieve the needs.
i'm mostly concerned about development time, cost, ability to leverage existing skills like .NET and reliability of the graph DB platforms and ease of setup and administration.
Graph databases are designed for applications such as social networks. For ease of development, it may be best to start with something like GraphDB. A key advantage over a key-value database is powerful query and traversal capabilities. It would be easy to, for instance, find all occurrences of friends of friends using the GraphDB query syntax.
The benefit of a key-value database service like Azure Table is low cost, minimal administrative overhead and scalability. You can store 500TB of data per Azure storage account and setup accounts in multiple regions. There is no server setup or database administration overhead and the Visual Studio SDK is easy to use. The down side is that graph like query support is not built in and you must index off the Primary Key / Row Key pair. For additional Azure Table design pattern please see https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/