Advanced Weblob operations help to use Weblobs most effectively.
In an earlier post I introduced Weblobs. Weblob is a new data type that is supported by the Cloud Storage Engine for MySQL (ClouSE). To a database developer, a WEBLOB behaves (almost) like a regular BLOB. However, in addition to the regular BLOB functionality, Weblobs can be downloaded directly from Amazon S3 by HTTP URLs.
In MySQL, a Weblob is expressed via a pair of BLOB fields that have a special naming convention: field_name$wblob and field_name$wblob_info. The latter field is what provides the Weblob functionality. It can be used to retrieve the direct Amazon S3 URL for the BLOB content.
But why does the field_name$wblob_info field have the $wblob_info suffix and not $wblob_url suffix? Can it do more than just retrieve direct URLs? It actually can.
I got a few questions like the ones below that I’d like to address to avoid further confusion.
How exactly secure is ClouSE for MySQL, the first secure database in the cloud? Am I protected against standard application level security attacks or even accidental admin mistakes?
With the help of ClouSE I get instantaneous backup for my database on the highly durable cloud storage. But how would I protect my data in case a malicious attack or an accident did occur?
I’ve got a comment pointing out that data encryption on the storage level doesn’t protect from SQL injections. Of course, data encryption does not protect from SQL injections (as long as there is SQL involved, there will be a risk of a SQL injection). Neither does it protect from the infinite number of attack vectors that can happen at any layer of the application stack: PHP, Apache, MySQL, Linux, application code, application users, etc.
Want to learn how you can store your sensitive data in the cloud storage? Take a look at the thorough and honest security analysis of the approach you can take to deploy your existing MySQL workloads to cloud.
keep reading in August issue of Hackin9 security magazine.
OblakSoft is pleased to announce the release of the 1.0.3 version of the WP2Cloud WordPress plugin. This release addresses media handling issues reported by our early adopters. Thank you all for your feedback!
This release fixes the following nuisances:
The WordPress on S3 / Yapixx AMI is updated and tested with the latest releases of software.
Cloud-powered BLOB type provides ACID guarantees and fast direct access to blobs via Web URLs.
Typically unstructured data (such as pictures, media files, documents)
a) Is either stored on the file system, unlike the related with it relational data which is stored in the database. This is well known, “convenient” practice that allows fast access to files but offers no transactional story and no unified data management (for db and filesystem)
b) Or is stored in BLOBs. This ensures transactional consistency and reduces management complexities, but is really bad for performance and scalability.
We took advantage of the cloud, and came up with an upgrade to the BLOB – a solution that combines the benefits of the two.
How much trouble will it be if your webserver failed? No trouble at all, if your website keeps its content on reliable Amazon S3 storage.
There are a lot of nuances in ensuring proper backups and restores of websites. When was the last backup taken? How much data might have been lost? How long will it take to recover it? When was the last time you tested restore? Do you even have an offsite backup?
Now that you can run dynamic websites off Amazon S3 storage, we’ll demonstrate why you no longer need to worry about backing up and restoring your website data. Losing the webserver is no longer a disaster. Cloud storage offers almost unsurpassable reliability a lot of website owners (small & large) would benefit from. In a way you get an “instantaneous backup” to the cloud. Your data is always safe with the cloud storage. The webserver can simply be replaced in minutes.