Hello, can I get some guidance on how this simulator could be implemented in Python? Background A

Hello, can I get some guidance on how this simulator could be implemented in Python?

 

Transcribed Image Text:

Background A database buffer is an area of memory that is used to store databases pages (another name for disk blocks). When the database engine requests a block (either to read or to write data) the buffer is first checked to see if the requested page is loaded in memory. If the page is already in memory then the operation is carried out on the data that is in memory. If the page is not in memory then the storage manager causes the disk block to be brought in from disk and stored in memory. The operation is then completed on the page in memory. Thus the storage manager interacts with the buffer manager and the physical storage as the database executes queries. The set of pages that are in memory is referred to as the buffer pool. Each buffer page stores just one block of data that has been loaded from disk. The size of the buffer pool refers to the maximum number of pages that can be stored in memory. If all the buffer pages in the buffer pool are occupied and there is need to bring a new block from disk then one page that is in the buffer must be replaced by the incoming block. The page that is evicted depends on the buffer replacement strategy that is being used. The Least Recently Used (LRU) policy is one in which the page that has not been referenced the longest is replaced. The cost involved in evicting a page is also considered. A page that has been written to is referred to as a dirty page. If a dirty page is to be evicted it must be written out to disk before being replaced. By this token, a dirty page is only evicted if there is no other page that was last accessed earlier. Other considerations include pinned pages and locked pages. A page can be marked to indicate that it should not be removed from the buffer by locking it. Similarly, a page can have a count (a pin count) of transactions that are currently using its data. This simulation will not consider pinned pages nor locked pages. The entries that might be kept in a simple page table that facilitates LRU policy are sketched below: Buffer # Page # Last Access Dirty Other data....... 0 43 10 1 1 438 3 1 2 8 8 0 3 -1 Buffer # is a number for buffer page Page # - holds the page (block #) that is stored in the buffer. In the case where a buffer does not store a page this value is -1 Last Access - stores the time when the page was last accessed. A simplification is to store the value of a counter here. A real buffer manager will use more sophisticated methods but a counter will do for this exercise. Dirty - is set to the value 1 if data has been written to the page since it was loaded into memory otherwise this field has the value 0. Other data (e.g. whether or not a block is pinned) might also be stored in the page table. We will ignore these data for the time being. The Simulator You are required to write a computer program to simulate the operations of a Buffer Manager under a set of simulated database operations. The data for the exercise is given as the file bufferSimulator.csv. Input Data Line 1 contains comma separated values for: Buffer pool size (number of pages/blocks) in the database buffer. Disk size (number of blocks on the disk Lines 2-n shall contain simulated operations that make page references. Again, each line should be comma separated (see sample input) and shall contain: An operation (READ, or WRITE) A page # (should not exceed disk size) A sample input file is illustrated below: Output Line 1: 10, 3000 Line 2: READ, 200 Line 3: WRITE, 158 Line 4: READ, 200 The simulator shall read the input and shall produce output after each operation is carried out. The output shall be a line of comma separated values being: Counter. This starts at 1 for the first operation The operation that was requested Background A database buffer is an area of memory that is used to store databases pages (another name for disk blocks). When the database engine requests a block (either to read or to write data) the buffer is first checked to see if the requested page is loaded in memory. If the page is already in memory then the operation is carried out on the data that is in memory. If the page is not in memory then the storage manager causes the disk block to be brought in from disk and stored in memory. The operation is then completed on the page in memory. Thus the storage manager interacts with the buffer manager and the physical storage as the database executes queries. The set of pages that are in memory is referred to as the buffer pool. Each buffer page stores just one block of data that has been loaded from disk. The size of the buffer pool refers to the maximum number of pages that can be stored in memory. If all the buffer pages in the buffer pool are occupied and there is need to bring a new block from disk then one page that is in the buffer must be replaced by the incoming block. The page that is evicted depends on the buffer replacement strategy that is being used. The Least Recently Used (LRU) policy is one in which the page that has not been referenced the longest is replaced. The cost involved in evicting a page is also considered. A page that has been written to is referred to as a dirty page. If a dirty page is to be evicted it must be written out to disk before being replaced. By this token, a dirty page is only evicted if there is no other page that was last accessed earlier. Other considerations include pinned pages and locked pages. A page can be marked to indicate that it should not be removed from the buffer by locking it. Similarly, a page can have a count (a pin count) of transactions that are currently using its data. This simulation will not consider pinned pages nor locked pages. The entries that might be kept in a simple page table that facilitates LRU policy are sketched below: Buffer # Page # Last Access Dirty Other data....... 0 43 10 1 1 438 3 1 2 8 8 0 3 -1 Buffer # is a number for buffer page Page # - holds the page (block #) that is stored in the buffer. In the case where a buffer does not store a page this value is -1 Last Access - stores the time when the page was last accessed. A simplification is to store the value of a counter here. A real buffer manager will use more sophisticated methods but a counter will do for this exercise. Dirty - is set to the value 1 if data has been written to the page since it was loaded into memory otherwise this field has the value 0. Other data (e.g. whether or not a block is pinned) might also be stored in the page table. We will ignore these data for the time being. The Simulator You are required to write a computer program to simulate the operations of a Buffer Manager under a set of simulated database operations. The data for the exercise is given as the file bufferSimulator.csv. Input Data Line 1 contains comma separated values for: Buffer pool size (number of pages/blocks) in the database buffer. Disk size (number of blocks on the disk Lines 2-n shall contain simulated operations that make page references. Again, each line should be comma separated (see sample input) and shall contain: An operation (READ, or WRITE) A page # (should not exceed disk size) A sample input file is illustrated below: Output Line 1: 10, 3000 Line 2: READ, 200 Line 3: WRITE, 158 Line 4: READ, 200 The simulator shall read the input and shall produce output after each operation is carried out. The output shall be a line of comma separated values being: Counter. This starts at 1 for the first operation The operation that was requested