Please enable JavaScript.
Coggle requires JavaScript to display documents.
Adding a Database layer - Coggle Diagram
Adding a Database layer
Database security controls
Migrating data into AWS databases :
Database layer considerations
Key considerations
1.1
Total storage requirements
How large does the database need to be?
will it need to store GB,TB or petabytes of Data.
1.2
scalability
How much throughput is needed?
will it be able to scale up if needed? (Autoscaling)
1.3
object size and type
Do you need to store simple data structures, large data objects, or both?
1.4
Durability
What level of data durability and data availability and recoverability do you need?
Data durability refers to the assurance that your data will not be lost
data availability refers to your ability to access your data when you want to
If the data you will store is absolutely critical to your business, you should choose a database solution that stores multiple redundant copies of your data across multiple geographically separated physical locations.
This solution will usually result in an increased cost, so it is important to balance your business needs with cost considerations
Do regulatory obligations apply?
Are there regional data privacy laws that you must comply with?
Database types
2.1
Relational database
2.1.1 Traditional examples
Microsoft SQL Server, Oracle Database, and MySQL.
2.1.2
Benefits :-
ease of use,
data integrity controls
excellence at reducing overall data storage,
their support for structured query language (SQL).
2.1.3
SQL is a language for querying or interacting with structured data stored in RDBMSs
2.1.4 Relational is ideal when you need
strict schema rules, where the schema structure is well defined and does not need to change often
Relational databases transactions are also ACID compliant, which means that they ensure data integrity by providing transactions that are atomic, consistent, isolated, and durable
Data quality enforcement
Do not need extreme performance as it is a characteristic of relational databases.
Do not need extreme read/write capacity, a relational database might not be the right choice (An RDBMS can be the best lowest effort solution)
2.2
Non-relational database
2.2.1 Examples include MongoDB, Cassandra, and Redis
Non-relational databases are sometimes called NoSQL databases.
They are different from relational databases because they are
purpose-built for specific data models and have flexible schemas
for building modern applications.
2.2.2
Benefits
flexibility,
scalability,
high performance,
highly functional APIs
2.2.3 - A non-relational database is ideal when database must
scale horizontally
to handle massive data volume.
A NoSQL database can scale horizontally by increasing the number of servers that it runs on
data does not lend itself well to traditional schemas
Non-relational databases have flexible schemas, where each object can have a different structure.
They can store structured data, such as relational database records; semistructured data, such as JavaScript Object Notation (JSON) documents and unstructured data, such as photo files or email messages
Non-relational databases work well when the data might have structural inconsistencies
read/write rates exceed what can be economically supported through traditional RDBMS
non-relational databases are optimized for specific data models and access patterns that enable higher performance instead of trying to achieve the functionality of relational databases
When you choose a database, consider
scalability, storage requirements, the type and size of objects to be stored, and durability requirements
Relational databases have
strict schema rules, provide data integrity, and support SQL
Non-relational databases
scale horizontally, provide higher scalability and flexibility, and work well for semistructured and unstructured data
.
