Microsoft Enterprise Library 5.0 Integration Pack for Windows Azure
As far as I understand, cache will be stored in database, and all web roles are sharing same cache which is same as Azure's in-memory distributed caching.
I'm wondering anyone has successfully used Caching Application Block on Windows Azure instead of Azure Caching.
If so, how is the speed? Any noticeably different from Azure Caching.
Thank you for comments!
The caching application block is deprecated (see here). It is replaced by the System.RunTime.Caching namespace. However, SqlDependency is not supported by SQL Azure, so you cannot use the caching namespace either for a database-driven cache.
So your choices boil down to: implement your own local cache by reading from SQL Azure yourself, use Windows Azure cache, or simply read from SQL Azure on demand.
The performance will be much better with the local cache because it is... local :). A background thread (that you need to write) will refresh your cache on a specific frequency. So accessing the local cache will be going at memory access speed. But... it will not be synchronized perfectly across your Windows Azure nodes, because each node will have its own cache. To work around this issue, you could code your refresh logic in a way that it is done at the same time across all your nodes.
Reading from the Azure Cache will be slower than accessing the local cache, but all your Windows Azure nodes will have access to the same data at the same time. You still need to build a thread that will update the Windows Azure cache on a specific frequency; it won't refresh itself automatically.
Warning: keep in mind that Azure Cache works well if you know in advanced the key of your key/value pair cache entry. In other words, you have no way of getting the list of keys from the Azure Cache. For example, if you store a list of Zip Codes / Temperature, the zip code would be your key (which is a known set). So you could use the Azure Cache for this purpose. The Azure Cache was designed to help store ASP.NET session state, which also has a known key (the Session ID).
Finally, keeping your data in SQL Azure (or another store, like an Azure Table) may work very well too. However that depends on how much traffic you get and how many times you will read from the data source. Remember that in some cases building a caching mechanism is be more work than necessary.
I am not very familiar with Enterprise Library. But Windows Azure Caching stores cache data in a remote server’s memory. When we request a cached data, we make a web request, and the server will return the data from its memory. If the cache server and our Windows Azure server are in the same data center (which is a recommended practice), the web transfer is extremely fast. If we use SQL Azure to store cached data, it takes about the same time for the data to transfer from SQL Azure server to our Windows Azure server. But it will take longer to query the data from the database compared to query the data from the cache server’s memory. SQL Azure may do some optimizations to increase data access, for example, cache the data in memory. But it is recommended you to use Windows Azure Cache over SQL Azure in this case.
Best Regards,
Ming Xu.
The Caching Application Block does not provide the features required for distributed caching. Instead, you should consider using one of the following technologies:
Windows Azure Caching. This enables you to provision a distributed
cache in the cloud. For more information, see Windows Azure Caching
Service.
Maintaining state and value in Windows Azure table storage.
Examples of how to implement this, and other useful resources, are
included in the Windows Azure Training Kit.
The caching mechanism of
the System.Runtime.Caching namespace of .NET Framework 4.0. For more
information, see System.Runtime.Caching Namespace.
The SQL Scripts which are compatible with the SQL Azure and are required for the Caching Database provider are available as a separate download. To get the scripts, download the EnterpriseLibraryIntegrationPack-WindowsAzure-sqlscripts.exe from the Microsoft Enterprise Library 5.0 Integration Pack for Windows Azure.
For information on using other classic Enterprise Library blocks in Windows Azure applications, see this white paper.
Related
I have read here and on other post and forums that the best place to save session state in Azure is AppFabric Cache, but I find that very expensive and would like to give a go to either table storage or a SQL database.
I read that a SQL database will be faster but I can't understand why it would be. Surely the SQL database will cache hot data in memory, but I would expect Table Storage to also do that (does it?). Otherwise I don't see why a SQL database would be faster at retrieving a row than Table Storage, in the end both are just retrieving data from a local disk based on a key. I would even expect that because Table Storage scales up well and automatically (vs a SQL databases that needs to be partitioned manually), it would be preferable as session state isn't a good candidate for local caching.
Does anyone have any experience or opinion on this?
thanks
Charles
You mentioned AppFabric Cache, which is a retired service. Regarding SQL vs Table: There isn't really a right answer to this. If you want to spin up a SQL Database instance (running about $2.50 monthly for a Basic-tier database), you'll have 2GB to work with. With Table storage, you'll pay about $0.15 for the same storage. Then there is Redis cache, your own cache (such as memcached), Azure Managed Cache service, etc. Performance-wise, you'd need to do some benchmarking to see how each performs. Any of these would work with Virtual Machines, Cloud Services (web/worker roles), and Web Sites, as they all have very well-defined APIs and, if using ASP.NET MVC, good provider support. Each has different capacity limits and different pricing.
One thing with Table storage: each entity (row) is limited to 1MB, so if you're attempting to cache > 1MB per cache entry, you'll need to consider another option.
#Gaurav mentioned in-role cache. This is a great way to use extra memory in your web/worker role instances. However: It's limited to web/worker Cloud Services; it doesn't help with Web Sites or Virtual Machines. For those, you really need some type of independent cache provider.
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.
I'm new to Azure, and a little confused about blob storage. I have a need for clients to access via FTP / SFTP to push and pull files (XML, CSV, EDI, etc). The pushed files are read in by a .net application and written to a database. As I understand, we would use a VM role to create a FTP / SFTP server, a worker role to execute the .net code, SQL Storage for the DB and Blob storage for the files.
Am I correct in this assumption first, and second can a VM role attach a storage blob for writing and reading files and can a worker role attach to the same storage blob to read and write files as well.
Sample:
client pushed xml file to VM via FTP. VM writes XML file to storage. Worker role reads file, processes it and writes contents to db.
Is my thinking correct or am I missing the boat?
Thanks
Given Azure has an array of services so you have a few options. One important thing to keep in mind with Azure is that your worker roles, which are simply Windows Server 2008 without IIS installed, are very flexible so there is a lot you can do with them – this includes writing your own FTP server and being able to host it via a worker role VMs. The FTP to Azure Blob Storage Bridge (on CodePlex) solution is an example of this.
In addition, you could use a web role (which is the same as a worker role but with IIS enabled) to do the same - so rather than rolling your own FTP server you can use IIS. A visual guide to setting IIS up to run as an FTP server in Azure can be found on ITQ.
I’d recommend doing some further reading to determine which is the better option of the two. Also have a think about you requirements as this may influence your approach, i.e. scaling, bandwidth, costs, your preferred deployment model etc.
As far as storing the files goes you can certainly use Blob Storage. If you have no need for a relational database in your system then you could skip using SQL Azure altogether (in which case the web role solution referenced above won’t be of much use) – but again that comes down to your particular requirements.
The official Windows Azure website is a good source of knowledge, especially if you’re getting started, so do take the time to look through some of the pertinent documentation.
My website is a .net 4.5 mvc site built with VS 2012. I have a SQL Server Compact DB in my app_data folder. All works great on my localhost. I deploy to Azure website and get this error?
Unable to find the requested .Net Framework Data Provider. It may not be installed.
I've googled it and get lots of possible answers, but none specific to Azure and SQL server compact. So my question is simple. Does a windows Azure Website which is deployed to an Azure shared hosting server support SQL Server Compact? If so, what do I need to do to eliminate the aforementioned error and make it work?
It certainly is possible to use SQL Server Compact on Windows Azure. However, you need to ask yourself:
Will I change anything in database?
This includes adding, updating and removing data. If you do, you should not use SQL Server Compact on Windows Azure. Because, if you use SQL Server Compact on Windows Azure and change anything in the database, you'll run into two problems:
Data is not replicated.
You risk losing data.
Data is not replicated
If you change anything in the database, the changes stays local. This means that if you have multiple instances running your web application, then each web application will have their own database, and if you change something in one of them, the change won't be replicated to other instances, which will result in unpredictable behaviour in your application.
You risk losing data
If you change anything in the database after deployment, you risk losing data, because Windows Azure might decide to redeploy your instance to another virtual or physical machine. When this happens, the new instance will be setup with the deployment package you originally uploaded to Windows Azure, and this package does not contain any changes you make to the database. And this redeployment can happen at any time for several reasons.
Conclusion
So, SQL Compact on Azure? Sure, no problem if your data is read-only. However, note that you won't get the performance you would with SQL Azure. But if your need changes down the road, you can always migrate your application from SQL Server Compact to SQL Azure.
If you want to use SQL Server Compact with Windows Azure, you can use the "private deployment" method, as explained on "ErikEJ"'s blog.
Edit: Microsoft has announced that they now provide 1 free 20 MB SQL Azure Database for every Azure subscription. This means you can create a subscription and create a free website, with a free SQL Azure Database. (As long as it's less than 20 MB) You can also have multiple Web Sites associated with the same SQL Azure Database for free. So, if you're considering SQL Server Compact on Windows Azure because your database will be very small and you don't want to pay for a 100 MB database, you can consider this option. In most cases, it will be a better solution. Your website will perform better, your database performance will be better and you have the ability to change your data and it will be replicated.
It's possible for SQL Server Compact 4.0 on Azure!!
I write an an article for it
And this is the English version I found
By few step:
Below is the solution after my research:
Step by Step like this:
Install two nuget: EntityFrame.SqlServerCompact & Microsoft SQL Server Compact Edition
put your SQL database file(.sdf/.mdf) in APP_Data folder
(Put the connection string like this in order to use it:
<add name ="DefaultConnection" connectionString ="Data Source=|DataDirectory|CompactDB.sdf" providerName ="System.Data.SqlServerCe.4.0" />)
Publish full project include above SQL database file to AzureWebsites.
you can find it can work well and is totally free.
Second Wenchao Zeng of Microsoft the Azure don't support Sql Compact.
I could use once but this is not recommended because the Windows Azure work with replication of the data (this is the cloud, remember?) and the Sql CE does not support this functionality. If you can to put a Sql CE in Azure sometimes will not get access or users see data outdated or broken because the async.
The best way is you to use the Azure Sql ou BLOB storage.
I'm developing a .NET app, which needs to run both on Azure and on regular Windows Servers(2003). It needs to store a few GB of data and SQL Azure is too expensive for me, so I'll use Azure tables in the cloud version. Can you recommend a storage solution, which will run on standalone servers and have an API and behavior similar to Azure tables? From what I've seen Server AppFabric does not include Tables.
If you think what Windows Azure Table Storage is, it is a Key-Value pair based non-relational databse which is accessible through REST API. Please download this document about Windows Azure and NoSQL database details.
If I were in your situation, my approach would have been to find something similar to Azure Table Storage which I can access over REST and have similar accessibility API. So if you try to find the similar database to run on a machine you really need to look for:
Key Value Pair DB
Support for basic operations i.e add, delete, insert, modify an entity
Partition Key and Row Key based Accessibility
RESTful Interface to connect
If you would want to try something you sure can look at:
DBreeze (C# based Key Value Pair NoSQL DB) I just saw it and looks exciting
Googles LevelDB (Key Value Pair DB, open source and available on Windows) I have no idea about API
Redis (Great Key-Value Pair DB but not sure for Windows compatibility and API)
Here is a list of key/value databases without additional indexing facilities are:
Berkeley DB
HBase
MemcacheDB
Redis
SimpleDB
Tokyo Cabinet/Tyrant
Voldemort
Riak
If none works, you sure can get any of open source DB and modify to work for your requirement and then make that available to others as your contribution to community.
ADDED
Now you can use Windows Azure Virtual Machine to run any kind of Key-Value pair DB on Linux or Windows Machine and connection with your application.
I'm not sure which storage solution to recommend, but just about any database solution would work provided that you write an Interface to abstract all your data storage code. Then write implementations of that interface for Azure Table storage and whatever other database you want to use on the non-cloud server
You should be doing that anyway so that your code isn't tightly coupled with Azure Table Storage APIs.
If you combine coding against that Interface with an IoC container, then a single line of code or a single configuration setting would enable you to switch between data implementations based on which platform the code is running on.