Select the appropriate storage option

Question 1

Overview

Answer 1

1) Understanding data access patterns
2) Selecting a data storage solution
3) Evaluating data storage qualities

Question 2

Read/write patterns

Answer 2

1) Tradeoffs between performance and consistency often need to be made so that these readers and writers can work together in harmony.
2) Depending on the number of readers and writers, the frequency of data operations, and concurrency requirements, you’ll need different strategies

Question 3

Immediate Consistency

Answer 3

1) all observers of this entity will have a consistent view of the updated entity.
2) to ensure strong consistency, some sort of locking method needs to be used, preventing the application from accessing the data for the duration of data updates.
3) when there are multiple replicas of data, maintaining consistency across the replicas needs extra processing cycles before the update is available for reading across all of the replicas.

Question 4

Eventual Consistency

Answer 4

1) certain replicas of data to be updated ahead of others, and updates are eventually propagated across the entire replica set
2) very fast in some systems, such as a well-connected Redis cluster.
3) takes longer in DNS

Question 5

Pessimistic concurrency

Answer 5

1) holds a quite pessimistic view of possible update conflicts.
2) So, it asks the database to lock the item during its update operations.

Question 6

Optimistic concurrency

Answer 6

1) considers the probability of conflicts being relatively low.
2) When it reads data for update, it keeps a revision number of the original data but it doesn’t hold a lock.
3) Then, as it writes back, as long as the latest revision number on the database is still the same as it has read, the update will succeed.

Question 7

Application type and concurrency

Answer 7

1) large amount of writes -> pessimistic concurrency, because optimistic concurrency will lead to many failed operations.
2) mostly read - you can use optimistic concurrency
3) simpler method: last-write wins.

Question 8

Dynamic schema, or schema-less, or NoSQL

Answer 8

1) don’t have enforced schema
2) Data is saved in the database as key–value pairs.
3) Complex queries are often difficult on such databases. 4) Most data retrievals are done by providing specific keys or key ranges.

Question 9

To enable complex queries on NoSQL databases

Answer 9

1) use advanced indexing techniques such as full-text indexing.
2) In some cases, schemas can be inferred from data to support complex queries.
3) For example, you can infer a schema from JSON documents by treating each property as a field.

Question 10

Combination of data stores

Answer 10

1) SQL Database for your transactional data,
2) Azure Blob for large binary files,
3) DocumentDB for loosely structured data, and
4) Azure Search for indexing free-text files.

Question 11

Selection data store solutions

Answer 11

1) Combination of data stores
2) Keep data close to compute
3) Cost matters

Question 12

ctor Pattern, or Actor Model,

Answer 12

A is a good example of an entity keeping its status close to itself. An actor can access and update its states quickly because its state is kept local. There’s no external service calls or additional network hops to go through. Moreover, because an actor is the only writer to its own state, you can achieve maximum parallelism without locking.

Question 13

Reduce storage cost

Answer 13

1) Layered storage and periodic data reduction can help you to control of your storage costs
2) reduce data size by using compression and periodic trimming
3) Layered storage keeps “hot” data in a more capable storage to provide rich interactions, such as complex queries and faster accesses, whereas it keeps “cold” data in cheaper storage to reduce overall costs

Question 14

Evaluating data storage qualities

Answer 14

1) Most applications require data stores to be scalable and reliable

Question 15

Reliability

Answer 15

1) use replicas

2) keeps three copies of your data automatically ( third-party data stores such as Redis, MongoDB, and MySQL.)

Question 16

Scalability

Answer 16

1) data sharding
2) Shard map management (SMM)
3) Data dependent routing (DDR)
4) Multishard query (MSQ)

Question 17

Shard map management (SMM)

Answer 17

Defines groups of shards for your application and manages mapping of routing keys to shards. With Elastic Scale, you can dynamically reallocate tenants to different shards as loads from particular tenants change. You can monitor the performance of each shard and split busy shards, or merge idle shards dynamically as needed.

Question 18

Data dependent routing (DDR)

Answer 18

Routes incoming requests to the correct shard (such as routing by tenant ID) and ensures correct routing as tenants move. DDR makes writing queries against shared databases easy

Question 19

DDR usage

Answer 19

DDR helps you to route the query to the appropriate shard where the tenant data resides. To avoid repetitive queries to SMM, the Elastic Scale client library also provides a route map cache so that the client application doesn’t need to continuously utilize SMM to look up shards.

Question 20

Multishard query (MSQ)

Answer 20

Interactively processes data across multiple shards. For example, you can execute the same statement on all shards and get results in a T-SQL UNION ALL semantic.

Question 21

Adopting Multitenancy

Answer 21

Adapting a single-tenant application for multitenancy is a serious architectural change that should not be taken lightly. Such change often needs modifications across all application layers, so it’s a high-risk change. More important, multitenancy often has profound impacts on business processes, such as sales strategy, support workflow, and version managements