---

DST Lezione 13-16

Availability or uptime

• In nosql systems, a value is readable and writable by a client because there are no other transaction locking that value
• Uptime (or availability) means that your system is up and operating.
• Uptime is commercially expressed in percentage. For example, 99% means that in one year you have four days where the system is unavailable.
• How much uptime you have depends on the application, cloud often goes up to 99.99% of uptime. The more uptime you want, the more it costs.
• 100% uptime is technically unreachable.

How would you increase this value? Redundancy. Add more servers, more nodes, geographically distributed, and so on. This is very expensive. But the uptime can be too much high for your client requirements, so it depends.

Reliability or Persistance

• It is expressed in percentage, and it’s the percentage that your data doesn’t get lost
• It is associated to the storage system.
• For example 99% of realiability means that there is 1% of probability that the data get lost. (1% is not acceptable, so here it’s just an example)
• For an online service on cloud a typical feature is eleven 9: 99.99999999999% that you don’t lose data.
• The more you pay, the more reliability you get.
• Cloud is generally the most reliable way to store data.
• A cons of using cloud is privacy. Encryption is a solution but it comes with his problems, like if you lose even one bit of an encrypted file then you lose everything.

Latency

• It’s time you wait until you get an answer from a system
• It can be reduced with redundancy like the previous ones, but you have to sacrify the absolute consistency requirements (so no ACID).
• Latency is often also human related. For example a manager that wants to know all the sales from the last year doesn’t care if you have billions of tuples, he wants them in some seconds. Ofcourse as we studied so fare there are techniques like indexing, materialized views, partitions and so on that can be built in advance to reduce latency.

Cloud services and data temperature

Latency, reliability and availability are like three coordinates, three parameters that depends on the system you are designing and from the context (requirements).

Example

Let’s say you run an online store that sells shoes. Who are your clients? If they are mostly Italian-speaking people, you can afford to sacrifice uptime during off-peak hours. For example, how many people will buy shoes at 3-4 a.m.?

However, if your target market is worldwide, you can’t apply this reasoning, and you need higher uptime to accommodate different time zones. Other parameters like latency and reliability ofcourse are necessary in this example. But you also have to consider that, the more you want of these three, the more you pay.

Cloud services often offer servers in a pyramid structure:

• Base of the Pyramid: Very cheap, high-latency servers (e.g., Google Cloud, Amazon Glacier). Storing data here is like freezing it at the North Pole. You pay very little for storage but face high latency. These servers are typically used for backups.
  • Storing data in clear text for faster recovery is risky, as it can be easily accessed by hackers, leading to stolen password
• Higher Levels: As you move up the pyramid, costs increase, but latency decreases. Usually on top of the pyramid you store frequently access data.

Data have a temperature:

• Hot Data: Frequently used.
• Cold Data: Less frequently accessed.
• Frozen Data: Rarely or never used, usually backup data

Example of data temperature

For a newspaper website, hot data is the newest content like from the last week. Cold data might be articles from the past month to a year, and anything older can be considered frozen. The same applies for emails: if you search emails from years ago you get an higher latency, and if you have an attachment from a year ago it will take a lot to download.

Throughput

If you have 1Gb/s of throughput, it means your system can process data at that rate. Throughput measures the amount of data your system can handle.

Your throughput should be designed to manage peak data loads, not just the average. Otherwise, your system might fail during data spikes.

Resiliance

System resilience is the ability to operate when some nodes are unavailable. One or two years ago, Disneyland experienced a significant incident illustrating this issue.

This was the organization: each server was managed through your ID on the phone, so you use your phone to pay the ticket, buy food, and even open the rooms. One day, a network outage happened and people were trapped inside Disneyland because the server couldn’t process their requests. They couldn’t exit from the room.

When designing a system, you have to think what happen if the system goes down, even if it’s unlikely to happen.

Access control

In relational systems, you have permissions to control who can read or write data. However, many NoSQL products lack built-in access control, assuming a secure environment and handling authentication differently. The modern scenario is more complex, requiring careful consideration of security aspects based on specific requirements.

Lezione 16

Recoverability

Capability to recover from a poor outage, like any kind of proble when you have a network outage or electric problem and you have to recover. We will talk about recoverability and some importants concepct, how is managed and how is handed in non relational systems.

In this situation, some transaction were completed, some were not even started. Some other were runned but not completed.

We have to manage this situation, we have two approaches:

• Immediate update: undo the operation
• Delayed Update: nothing

For immediate update, we update values as we read the transaction operations. If a transaction doesn’t commit because of a fault, then the values are rewritten to the state before the transaction start.

For a delayed update, instead of writing as soon as you do the operation, you schedule the writings to be doen at the end. If a fault happen when i have to dhte writing, no data is written.

We must consider very carefult the defitinition of “commit point” of a transaction. A transaction reaches his commit point when the transaction is recoverable.

A common feature that helps recoverability is a log file: a file with some fields (timestap, what is the operation, transaction id and so on) and each operation is written in this log file.

When a transaction becomes recoverable if you use a log file? When the log file is readable. Usually a part of the log file is on disk, but a portion is on the main memory. So we have to consider also when happen the synchronization of the log file. Main memory content of the log in case of fault is lost. But if you flash into the disk ASAP then you get a very high I/O overhead.

Another question is, should be written first on disk or first on the log and then on the disk? Usually Log First. Some options are:

• WALL: Write Ahead Logging - you first write on disk;

If you want strong consistency, then you have to flash each operation from log into main memory.

An operation is recoverable when the log has been written on the disk and the operation has reached the end. At that point you have all the operations and transaction in your log and even if there is a fault or an outage or whatver you can repeat the operation on the transaction.

• Immediate Update: you first update the log, then the log is flashed on disk and in case of fault you undo operation.
• Delay update: you schedule the operation to be done and then eventually you have no undone.

But what happens if the fault or error is while you’re writing? It depends if it has reached the commit point or not because a transaction can schedule all the operations at the end, so first will be written on log, flashed and then transaction is done. But if operations are not completed on the data, what you should do? Redo your operation thanks to the log.

What about immediate update? There is a commit point, if you have not reached the commit point you have to undo the operation. Otherwise you have to do the redo. These are the two options: undo, redo(no undo). These two approaches to recoverability they both use a log file and both use the WAL principle and they have different advantages.

How many operation do you expect to fail?

• If i expect a lot of operation to fail then is most advantageous to delay the update and redo lots of operations.
• Otherwise, it’s better to undo the few operations that failed.

Steal/no-steal and Force/no-force

Forced Writing: you can force to synchronize immedietely each value you write. Otherwise is called no-force. The force rule means that REDO will never be needed during recovery. No-steal/ Steal approach: no steal when a cache buffer page updated by a transaction cannot be written to disk before the transaction commit. On the other hand, if the recovery protocol allows writing an updated buffer before the commi tpoint, it is called steal. No-steal rule means that UNDO will never be needed during recovery, since a committed transaction will not have any of its updates on disk before it commits.

          
----|-------|-------------------------->
(STEAL)  1. Write on log
         2. Write on disk
         (FORCED)

No-steal Forced is the most restricted policy with the most overhead: you write at the end of the transaction and you flash all exactly on that moment. Steal no force is the most permissive: you write on disk before transaction commits and you delay writings of the page after the commit.

Real systems often use the most permissive recoverable techniques, minimizing memory writes to avoid slowing down the system. Flashing main memory frequently can degrade performance, so policies are in place to minimize writes. In reality, when you get a transaction end on a real system there is a chance that the transaction hasn’t ended and not reached the commit point. The transaction may have only modified values in RAM, with disk synchronization delayed to reduce overhead.

Consistency in NoSQL

For NoSQL You have two apporaches:

1. Just store the log of the operation
2. Snapshot

You can just store the log of the operation and synchronize on disk periodically i.e. every 5 minutes. If a fault happen, i lose only the 5 minute content. It depends on the situation, like in an online game it wouldn’t be acceptable more than 30 seconds.

For snapshot, you lose all the data written from one snapshot to the other. A thing that could happen using snapshot is called Cascading Transaction Killing. You could have a transaction that rely on data or state changes made by the initial transaction. So if the initial transaction is undone, all the subsequent dependent transactions must be undone.

Versioning is one way to guarantee consistency. It doesn’t mean that everything is allowed because there are some situation where transactions must be killed but also the other transaction that have read value written by this. Multiversioning is another way. Another way is lock. Another way is timestamp.

While relational systems relies on the transaction and the log file, nosql only relies on log and snapshot. But when you use only the log file and the snapshot you are assuming the risk of losing some data.

If you are on cloud, you can accept a system that doesn’t give you absolute consistency becuse you can recover it. Self recoverability: the whole cloud idea is built on cloud system that “self fix” themself. There is a field study called reliability theory, historically born in 2 WW when we had airplanes that fails continuosly. Each part of the airplan has a probability of error say 1/250. If there are more than 250 parts, then airplane failes continuosly. Reliability theory studies the probability of having a failure in a system. It has been also applied to computer, for example you it is used to estimate the life of a component. hard disk have MTTF parameters: Mean Time TO Failure, that it’s in the order of 20 years.

If you have a huge datacenter and thousands or hundred of thousands computer connected, they will fail continuosly, every day. Yahoo solved this with a self recovery system: if a motherboard fails, they disconnect it, put into trash and insert a new motherboard. The system will recognize the new hardware and use his resources. The self recovery file system is the hearth of cloud computing. Of course, this is the reason because cloud is more reliable than a standalone server.

In cloud application when you pay big money to amazon web service these risks are very low. In theory they don’t give you complete guarantee because you could lose a snapshot or lose data between snapshots. In reality probability is really really low so could be acceptable.

Log file

• A log file isn’t just for recovery; it can also be used for auditing to see what users are doing and track system changes.
• However, let’s say you write all the modification you have done up to a certain point. A catastrophic failure could happen and you could still lose everything.
• One solution is a complete backup, but that’s costly in terms of memory and time, and recovery can be slow. You need to decide how often to perform complete backups. More backups mean more memory and higher costs, and you still risk losing data between backups.
• Instead, you can do an initial full backup and then use incremental backups, storing only the changes made since the last backup (deltas). This approach combines snapshots (full backups) and logs (incremental changes). By starting with a snapshot and applying the log’s modifications, you can restore your backup efficiently.

How often do you want to backup? It depends on requirements. Incremental backups are usually cheaper and more efficient than full backups. So, you’ll likely use a mixed strategy: rarely doing full backups, occasionally taking snapshots, and regularly flashing logs on the server.

To restore data from a snapshot, you apply the log to bring the data back to the point of the last log flash. Instead of redoing all operations from the log, read the log backwards and use the last value for each variable. This way, you quickly recover the system to its last state without reapplying every change.

Relational systems are designed to be reliable and resistant to failure. Non-relational systems don’t always have this built-in reliability. Non-relational system doesn’t have this facility.

Another thing to consider that is that when you recover, you do not bring the system back to the time before the fault but to the last consistent state.

Last Consistent State

Another way to look at it is that your system starts in a consistent state and moves to another consistent state after a transaction finishes. During the transaction, temporary data loss might occur. If a failure happens and the system has self-recovers capabilities, it recovers himself to the last consistent state before the failure, effectively going back in time.

In contrast, NoSQL systems often offer eventual consistency. They recover to the state at the time of the failure, but it may take some time to reach full consistency. It’s important to understand that NoSQL systems are designed for eventual consistency, and you need to choose based on your specific requirements.

See BASE properties → eventual consistency