What is the difference between BLOB and CLOB datatypes?

Blob and Clob together are known as LOB(Large Object Type).

 I have been pretty much fascinated by these two data types. According to Oracle Docs, they are presented as follows :

BLOB : Variable-length binary large object string that can be up to 2GB (2,147,483,647) long. Primarily intended to hold non-traditional data, such as voice or mixed media. BLOB strings are not associated with a character set, as with FOR BIT DATA strings.
CLOB : Variable-length character large object string that can be up to 2GB (2,147,483,647) long. A CLOB can store single-byte character strings or multibyte, character-based data. A CLOB is considered a character string.

Following are the major differences between Blob and Clob data types.

Blob	Clob
The full form of Blob is Binary Large Object.	The full form of Clob is Character Large Object.
This is used to store large binary data.	This is used to store large textual data.
This stores values in the form of binary streams.	This stores values in the form of character streams.
Using this you can store files like text files, PDF documents, word documents etc.	Using this you can stores files like videos, images, gifs, and audio files.
MySQL supports this with the following datatypes: TINYBLOB BLOB MEDIUMBLOB LONGBLOB	MySQL supports this with the following datatypes: TINYTEXT TEXT MEDIUMTEXT LONGTEXT
In JDBC API it is represented by java.sql.Blob Interface.	In JDBC it is represented by java.sql.Clob Interface.
The Blob object in JDBC points to the location of BLOB instead of holding its binary data.	The Blob object in JDBC points to the location of BLOB instead of holding its character data.
To store Blob JDBC (PreparedStatement) provides methods like: setBlob() setBinaryStream()	To store Clob JDBC (PreparedStatement) provides methods like: setClob() setCharacterStream()
And to retrieve (ResultSet) Blob it provides methods like: getBlob() getBinaryStream	And to retrieve (ResultSet) Clob it provides methods like: getClob() getCharacterStream()

Cloud Well-Architected Framework

The Well-Architected Framework identifies a set of general design principles to facilitate good design in the cloud:

1- Stop guessing your capacity needs: Eliminate guessing about your infrastructure capacity needs. When you make a capacity decision before you deploy a system, you might end up sitting on expensive idle resources or dealing with the performance implications of limited capacity. With cloud computing, these problems can go away. You can use as much or as little capacity as you need, and scale up and down automatically.

2- Test systems at production scale: In the cloud, you can create a production-scale test environment on demand, complete your testing, and then decommission the resources. Because you only pay for the test environment when it's running, you can simulate your live environment for a fraction of the cost of testing on premises.

3- Automate to make architectural experimentation easier: Automation allows you to create and replicate your systems at low cost and avoid the expense of manual effort. You can track changes to your automation, audit the impact, and revert to previous parameters when necessary.

4- Allow for evolutionary architectures: Allow for evolutionary architectures. In a traditional environment, architectural decisions are often implemented as static, one-time events, with a few major versions of a system during its lifetime. As a business and its context continue to change, these initial decisions might hinder the system's ability to deliver changing business requirements. In the cloud, the capability to automate and test on demand lowers the risk of impact from design changes. This allows systems to evolve over time so that businesses can take advantage of innovations as a standard practice.

5- Drive architectures using data: In the cloud you can collect data on how your architectural choices affect the behavior of your workload. This lets you make fact-based decisions on how to improve your workload. Your cloud infrastructure is code, so you can use that data to inform your architecture choices and improvements over time.

6- Improve through game days: Test how your architecture and processes perform by regularly scheduling game days to simulate events in production. This will help you understand where improvements can be made and can help develop organizational experience in dealing with events.