I write an application using cocos2d-x. Now I want to store some data in the Windows Azure Storage and get the data sometime, how can I do that?
As written, it's difficult to answer such a broad question. Having said that: I'll do my best to give you an objective answer describing Azure's storage options from a service perspective.
Azure Mobile Services. This lets you have a CRUD interface to storage, and is build to provide a REST-based API, which fronts storage. It defaults to SQL Database, but you can easily override this by creating your own custom API and using server-side JavaScript / Node.js to read/write to any storage system.
Azure blobs/tables/queues. This is the collective set of Azure large-scale storage, with up to 200TB per account namespace. You can access storage directly from your game, or through your own service tier - that's up to you. You need to worry about security, as you don't want to have your blobs exposed as public unless you want to. Fortunately you may use something called a Shared Access Signature to grant access to your app, while keeping these resources private to the rest of the world.
SQL Database. Azure provides database-as-a-service, largely compatible with SQL Server. As long as you have a proper connection string, it's just like having a local database.
3rd-party hosted solutions. There are companies that host data services in Azure, such as ClearDB (MySQL) and MongoLab (MongoDB).
One other option: Custom database solutions. If you're not using a built-in or 3rd-party storage service, you can always install a database server within a Virtual Machine. You're now managing the server, but this would give you ultimate choice.
Related
I have dozens of Azure Storage accounts and depending on the current HTTP session, I execute CRUD operations against a specific storage account. I have a single instance of HttpClient for other API calls (i.e. calls that are not related to Azure Storage). See this for the reasons behind.
For Azure Storage, I'm using the .NET SDK leveraging classes like CloudStorageAccount and CloudTable. Is there a similar re-use for Azure Storage so that the web server does not open connections over and over? For example, should a CloudStorageAccount instance be made static and re-used across the application? I can't find any documentation on official Microsoft recommendation.
Considering I have many storage accounts, I'd have to cache a connection to every single one separately. I'm not sure if doing this is a good practice or not.
First time using Azure. I have a basic node js bot built with Microsofts Bot Framework, and deployed on Azure. What are my options for storage?
I will most likely just be needing simple key:value storage. Mongodb was my first though but I dont think Azure supports it nativeley.
That said, what are my options for storage on Azure? I usual shy away from MySQL just from preference, but theres no actual reason that wouldnt work either.
Take a look at Azure Table Storage for a NoSql solution
Table storage is a key/attribute store with a schemaless design. Because Table storage is schemaless, it's easy to adapt your data as the needs of your application evolve. Access to data is fast and cost-effective for all kinds of applications. Table storage is typically significantly lower in cost than traditional SQL for similar volumes of data.
I am trying to get to grips with Azure Mobile Services and am a little lost about which Azure services I should be using for what. When you set up a new Azure Mobile Service you only get the option to create it with Microsoft SQL Server as the database. Can you configure it to use the documentDB service instead?
Also a lot of what I read about Azure Mobile Services seem to be setup around storing data for a particular user. Is this the correct place to store data and query it for all the systems users rather than an individual or should that be handled elsewhere?
thanks
Andy
using the .NET backend, you have a choice of using Azure SQL Database,MongoDB or Table Storage. There's no out of the box support yet for DocumentDB, but you can make it work as shown here
what you store in the storage listed above is up to you, there is no specific reason/restriction/limitation that's its only for user specific data. the samples just happen to show that.
You may use any backend database service. It's true you have to set up SQL when you create a new mobile service space. And the SDK has a Table provider that maps to SQL (or MongoDB). However, you can ignore all that if you want. As long as you can access the appropriate driver for your database-of-choice, you can make calls to the database from the API backend methods. This is especially true when building custom API methods.
Please let me know is there any way to programmatic-ally link the resources(sql database or storage account) to my Azure cloud service.
This is a vague question, but... Windows Azure SQL Database and Windows Azure Storage are both services you simply consume - grab an endpoint and connect. That's the link. Very loose coupling. For SQL Database, it's just like accessing an on-premises database: open a connection via connection string and start working with the database.
For Windows Azure Storage, you can connect to any storage account you create, even ones in different subscriptions, as long as you have the account name and access key.
If there's something more specific you're looking for, you'll need to post a more specific question.
I have a web role that talks to Azure Storage, Azure Shared Cache Service and Azure SQL Databases. It is only ever the web roles that communicate with these storage mediums, and never the client browser. The Azure Table Storage contains sensitive data, but the cache and SQL databases do not.
Question is, if all data access goes over plain HTTP, is there a risk that someone can intercept my packets, and read my storage key? If so, who can sniff these packets - just Microsoft employees, or do I need to worry about other Azure tenants that might have effected a jailbreak?
A few things to consider:
If your webrole and storage accounts are in the same data center, then the traffic is contained within data center. In that case, going of HTTP would not create any problems IMO. However if the webrole and storage accounts are in different data centers, then definitely make use of HTTPS.
Since you never send your storage account key with your requests to storage, you can be assured on that part. What you do is sign the requests using your key (or the storage client library does) and send that signature as a part of your requests. I don't think one would be able to reverse engineer that signature to get your storage account key.
HTH.
In addition to the previous answers, you should also take a look at the official security whitepaper: Windows Azure Security Overview. It talks about how isolation and packet filter secure the communication in the datacenter.