Storage. Holger Pirk

Transcription

1 Storage Holger Pirk

2 Purpose of this lecture We are going down the rabbit hole now We are crossing the threshold into the system (No more rules without exceptions :-) Understand storage alternatives in-memory vs. disk N-ary vs. decomposed storage slotted pages Sorted storage Main/Delta storage

3 Core Core CPU Core Core Let s look at the architecture again Database Architecture User External Interface Logical Plan Physical Plan Database Kernel Let s build one of these bottom up

4 Let s start with storage Insert processing Inserts are usually not optimized Arrive at the storage layer as intact tuples

5 A database kernel The key part of a data management system everything else is optional A library of needed functionality Usually implemented in C++/C Provides an interface to subsystems

6 Let s open up the kernel A (preliminary) database kernel architecture Catalog Storage Manager Operator Implementations Data RAM Database Kernel

7 Let s open up the kernel The kernel interface class StorageManager ; class OperatorImplementations ; class DatabaseKernel { OperatorImplementations & getoperatorimplementations (); StorageManager & getstoragemanager (); }

8 A simple storage manager

9 Inserting Data In SQL INSERT INTO " Employee " VALUES(4, holger,100000, ) ; In C++ struct Tuple { int id; char * name ; int salary ; int joiningdate ; StorageManager (). gettable (" Employee "). insert ({4, " holger ", , }) ;

10 Storage Manager Interface In C++ class Table ; class StorageManager { map <string, Table > catalog ; public : Table & gettable ( string name ) { return catalog [name ];

11 Storing tuples Two decisions to be made Where do we store them Disk Memory (Tape) (etc.) How do we store them N-ary or decomposed? Sorted? Hybrid? Dictionary-compressed?

12 Let s discuss In-Memory Storage first

13 The interface Simplified Storage Manageer Interface class Tuple { public : int id; char * name ; int salary ; int joiningdate ; bool deleted ; class Table { public : void insert ( Tuple ); void deletebykey ( int id); vector <Tuple > findbykey ( int id);

14 How to store tuples Fundamental Mismatch Relations are two-dimensional Memory is one-dimensional Tuples need to be linearized There are two mainstream strategies (and research on hybrids)

15 How to store tuples: N-ary vs. Decomposed Storage

16 The N-ary Storage Model (NSM) Example employees. insert ({4," holger ",100000, }) ; employees. insert ({5," sam ",750000, }) ; employees. insert ({6," daniel ",600000, }) ; Linearization in N-ary format 4 holger sam daniel In marketing they call this a row store

17 Linearization in N-ary format When N-ary storage works well 4 holger sam daniel Insert a new tuple employees. i n s e r t ({3," peter ",200000, }) ; Simply append the tuple 4 holger sam daniel peter

18 N-ary storage manager implementation In C++ class Tuple { public : int id; char * name ; int salary ; int joiningdate ; bool deleted = false ; class Table { vector <Tuple > storage ; public : void insert ( Tuple t){ storage. push_back (t); vector <Tuple > findbykey ( int id);

19 When N-ary storage is suboptimal The database 4 holger sam daniel peter They query find all tuples that have an id value of 17 In SQL select * from employee where id = 17;

20 N-ary storage manager implementation In C++ class Tuple { public : int id; char * name ; int salary ; int joiningdate ; bool deleted = false ; class Table { vector <Tuple > storage ; public : void insert ( Tuple t){ storage. push_back (t); vector <Tuple > findbykey ( int id){ vector <Tuple > result ; for ( size_t i = 0; i < storage.size (); i ++) { if( storage [i]. id == id) result. push_back ( storage [i]); } return result ;

21 Impact Data Locality Locality is king But why? Aren t we talking about in-memory databases? Doesn t RAM have constant access latency?

22 Impact Data Locality Locality is king But why? Aren t we talking about in-memory databases? Doesn t RAM have constant access latency? How much locality is necessary Processing Time per Value in CPU Cycles 1000 cycles K 32K 256K Stride in Bytes for ( size_t i = 0; i < storage.size (); i ++) i f ( storage [i]. id == id) result. push_back ( storage [i]);

23 Why data locality matters A CPU from the inside CPU Core 1 Core 2 Registers Registers L1 Cache TLB L1 Cache TLB L2 Cache L2 Cache Last Level (L3) Cache Memory on die off die

24 Cost estimation The database 4 holger sam daniel peter The question Calculation Query Find all records with the id 17 Costs Each (random) access to a value costs 3, each access to an imediately following value costs 1, accessing a value again is free

25 Decomposed Storage

26 The Decomposed Storage Model (DSM) Example employees. i n s e r t ({4," holger ",100000, }) ; employees. i n s e r t ({5,"sam ",750000, }) ; employees. i n s e r t ({6," daniel ",600000, }) ; Linearization in Decomposed format holger sam daniel In marketing they call this a column store

27 When decomposed storage works well The database holger sam daniel They query find all tuples that have an id value of 17 In SQL select * from employee where id = 17;

28 When decomposed storage works well Storage Manager class Table { vector <int > ids ; vector <char *> names ; vector <int > salaries ; vector <int > joiningdates ; public : vector <Tuple > findbykey ( int id){ vector <Tuple > result ; for ( size_t i = 0; i < storage.size (); i ++) { if(ids [i] == id) result. push_back ({ ids [i], names [i], salaries [i], joiningdates [i ]}) ; } return result ;

29 Cost estimation The database holger sam daniel The question Calculation Query Find all records with the id 17 Costs Each (random) access to a value costs 3, each access to an imediately following value costs 1, accessing a value again is free

30 When decomposed storage is suboptimal Linearization in Decomposed format holger sam daniel Insert a new tuple employees. i n s e r t ({3," peter ",200000, }) ; Tuples need to be decomposed before insertion holger sam daniel peter

31 DSM Inserts in C++ Storage Manager class Table { vector <int > ids ; vector <char *> names ; vector <int > salaries ; vector <int > joiningdates ; public : void insert ( Tuple t){ ids. push_back (t.id); names. push_back (t.name ); salaries. push_back (t. salary ); joiningdates. push_back (t. joiningdate );

32 When decomposed storage is suboptimal Tuples are decomposed in database holger sam daniel peter Access a single tuple s e l e c t * from employee where tuple_id = 3; -- assume index access tuple needs to be reconstructed

33 Catalog Metadata

34 Example The program employees. insert ({3, " peter ", , }) ; employees. insert ({4, " holger ", , }) ; employees. insert ({5, "sam ", , }) ; employees. insert ({6, " daniel ", , }) ; The database 3 peter holger sam daniel

35 Maintaining Metadata In C++ class Table { vector <Tuple > storage ; bool issorted = true ; bool isdense = true ; public : void insert ( Tuple t) { assume ( storage.size () > 1); issorted &= t.id >= storage. back ().id; isdense &= t.id == storage. back ().id + 1; storage. push_back (t); vector <Tuple > findbykey ( int id);

36 Exploiting Metadata In C++ class Table { vector <Tuple > storage ; bool issorted = true ; bool isdense = true ; public : void insert ( Tuple t); vector <Tuple > findbykey ( int id) { if( isdense ) return storage [id - storage. front ().id ]; vector <Tuple > result ; for ( size_t i = 0; i < storage.size (); i ++) { if( storage [i]. id == id) result. push_back ( storage [i]); } return result ;

37 Worksheet Assume the following Query Find the names of all employees with id 5 Costs Each (random) access to a value costs 3, each access to an imediately following value costs 1, accessing a value again is free On the following database {3," peter ",200000, } {4," holger ",100000, } {5,"sam ",750000, } {6," daniel ",600000, } Calculate the data access costs on these storage strategies! Which is the least expensive? N-ary storage (dense-flag set) N-ary storage (dense-flag not set) Decomposed storage (dense-flag not set)

38 Ensuring sortedness In C++ class Table { vector <Tuple > storage ; bool issorted = true ; bool isdense = true ; public : void insert ( Tuple t) { storage. push_back (t); sort ( storage. begin (), storage.end (), []( auto l, auto r) { return l.id < r.id; }); for ( size_t i = 1; i < storage.size (); i ++) isdense &= storage [i -1]. id == storage [i -1]. id +1; vector <Tuple > findbykey ( int id);

39 Handling Deletes In C++ class Table { vector <Tuple > storage ; public : void deletebykey ( int id) { for ( size_t i = 0; i < storage.size (); i ++) if( storage [i]. ids == id) storage [i]. deleted = true ;

40 Hybrid Storage: Delta/Main

41 Delta/Main storage manager implementation In C++ class Table { struct { vector <int > ids ; vector <char *> names ; vector <int > salaries ; vector <int > joiningdates ; } main ; vector <Tuple > delta ; public : void insert ( Tuple t) { delta. push_back (t); vector <Tuple > findbykey ( int id) { vector <Tuple > result ; for ( size_t i = 0; i < main.ids.size (); i ++) if( main. ids [i] == id) result. push_back ({ main.ids [i], main. names [i], main. salaries [i], main. joiningdates [i ]}) ; for ( size_t i = 0; i < delta.size (); i ++) if( delta [i]. id == id) result. push_back ( delta [i]); return result ;

42 Delta/Main storage manager implementation In C++ class Table { struct { vector <int > ids ; vector <char *> names ; vector <int > salaries ; vector <int > joiningdates ; vector <bool > deleted ; } main ; vector <Tuple > delta ; public : void merge () { for ( size_t i = 0; i < delta.size (); i ++) if (! delta [i]. deleted ) { ids. push_back ( delta [i]. id); names. push_back ( delta [i]. name ); salaries. push_back ( delta [i]. salary ); joiningdates. push_back ( delta [i]. joiningdate ); } delta = {

43 Variable Sized Datatypes

44 Let s think back to our example Linearization in Decomposed format holger sam daniel peter Names have different sizes they occupy variable space in memory We d like to maintain fixed tuple sizes, allows randomly access to tuples by their position e.g., when reconstructing decomposed tuples Two choices overallocate space for varchars (many systems need a size parameter: e.g., varchar(128)) store them out of place

45 In place storage Our example database stored in in place DSM (name length <= 6) h o l g e r s a m d a n i e l p e t e r Properties Good for locality Simple Wastes space particularly bad for in-memory databases

46 h o l g e r s a m d a n i e l p e t e r Out of place storage Our example database stored in out of place DSM Relation: Dictionary: Properties Space conservative Bad for locality Complicated Harder to implement Garbage-collection is tricky

47 Worksheet Assume the following Query Find the names of all employees with a salary above Costs Each (random) access to a value costs 3, each access to an imediately following value costs 1, accessing a value again is free On the following database {4," holger ",100000, } {5,"sam ",750000, } {6," daniel ",600000, } {3," peter ",200000, } Calculate the data access costs on these storage strategies! Which is the least expensive? Out-of-place N-ary storage In-place N-ary storage Out-of-place Decomposed storage In-place Decomposed storage

48 h o l g e r s a m d a n i e l p e t e r Database Nifty out of place storage: dictionary compression {4," holger ",100000, {5,"sam ",750000, {6," daniel ",600000, {3," peter ",200000, {9,"sam ",920000, Our example database stored in out of place DSM Relation: Dictionary:

49 h o l g e r s a m d a n i e l p e t e r Nifty out of place storage: dictionary compression Our example database stored in out of place DSM Relation: Dictionary: Dictionary compression Before every insert to the dictionary, check if the value is already present If so, elide the insert and use the address of the existing value Otherwise, insert the value

50 Assume the following Worksheet Query Find the names of all employees with a salary above Costs Each (random) access to a value costs 3, each access to an imediately following value costs 1, accessing a value again is free On the following database {4," holger ",100000, {5,"sam ",750000, {6," daniel ",600000, {3," peter ",200000, {9,"sam ",920000, Calculate the data access costs on these storage strategies! Which is the least expensive? Out-of-place N-ary storage with duplicate elimination In-place N-ary storage Out-of-place Decomposed storage with duplicate elimination In-place Decomposed storage

51 Data storage on disk

52 How are disks different? What changes Larger pages (Kilobytes instead of bytes) Much higher latency (ms instead of nanoseconds) Much lower throughput (hundreds of megabytes instead of tens of gigabytes per second) This is why you think of DBMSs as I/O bound The operating system gets in the way Filesize is limited DBMS needs to map tuple_ids to files and offsets Goals shift Disks are dominating costs by far Complicated I/O management strategies pay off Pages are large Each page behaves like a mini-database (in the case of N-ary storage)

53 Let s look back at the kernel A (preliminary) database kernel architecture Catalog Storage Manager Operator Implementations RAM Data Disk Buffer Manager Database Kernel

54 Disk-based storage manager implementation In C++ class BufferManager ; class Table { BufferManager * buffermanager ; string relationname = " Employee "; public : void insert ( Tuple t) { buffermanager ->getopenpageforrelation ( relationname ). push_back (t); buffermanager ->committoopenpageforrelation ( relationname ); vector <Tuple > findbykey ( int id) { vector <Tuple > result ; auto pages = buffermanager. getpagesforrelation ( relationname ); for ( size_t i = 0; i < pages.size (); i ++) { auto storage = pages [i]; for ( size_t i = 0; i < storage.size (); i ++) if( storage [i]. id == id) result. push_back ( storage [i]); } return result ;

55 The Buffer Manager Interface class BufferManager { map <string, vector <Tuple >> openpages ; map <string, vector <string >> pagesondisk ; size_t numberoftuplesperpage ; public : vector <Tuple >& getopenpageforrelation ( string relationname ); void committoopenpageforrelation ( string relationname ); vector <vector <Tuple >> getpagesforrelation ( string relationname );

56 The Buffer Manager Implementation vector <Tuple >& BufferManager :: getopenpageforrelation ( string relationname ) { return openpages [ relationname ]; void BufferManager :: committoopenpageforrelation ( string relationname ) { if( openpages [ relationname ]. size () >= numberoftuplesperpage ) { vector <Tuple > newpage ; while ( openpages [ relationname ]. size () > numberoftuplesperpage ) { newpage. push_back ( openpages [ relationname ]. back ); openpages [ relationname ]. pop_back (); } pagesondisk [ relationname ]. push_back ( writetodisk ( openpages [ relationname ])); openpages [ relationname ] = newpage ; } vector <vector <Tuple >> BufferManager :: getpagesforrelation ( string relationname ) { vector <vector <Tuple >> result = { openpages [ relationname ] for ( size_t i = 0; i < pagesondisk [ relationname ]. size (); i++) result. push_back ( pagesondisk [ relationname ][i]); return result ;

57 The $1000 question: what is the value of numberoftuplesperpage

58 Pages like mini-databases: Unspanned Pages Pages Goals Simplicity Databases normally deal with data in fixed sized blocks called pages Random access performance (assuming known page fill-factors) Given a Unspanned tuple_id, find the record with a single page lookup Example DBMS Architecture Pages reading one record only requires reading one page efficient when size of record is much smaller than size of page P i P i+1 a 103 P i+2 a 100 a 107 a 101 a 119 a 125 Disadvantage: Space waste Cannot deal with large records No in-page random access for variable-sized records P.J. M c.brien (Imperial College London) Storage & Indexing 7

59 Pages Spanned Pages: optimizing for space efficiency Goals Minimize space waste Support large Spanned records Example Databases normally deal with data in fixed sized blocks called page supports record sizes greater than one page more space efficient P i a 100 a 101 a 103 P i+1 a 103 a 119 a 107 P i+2 a 107 a 125 Disadvantages: P.J. M c.brien (Imperial College London) Storage & Indexing Complicated Random access performance No in-page random access for variable-sized records

60 Slotted Pages: Random Access for In-Place NSM Enabling In-page random access PAGE HEADER RH Jane 30 RH John 45 RH Jim 20 RH Susan 52 Explained Store tuples in in-place N-ary format (spanned or unspanned) Store tuple count in page header Store offsets to every tuple Offsets only need to be typed large enough to address page Bytes for pages smaller than 256 Bytes Shorts for pages smaller than 65,536 Bytes Integers for pages smaller than 4 Gigabytes

61 Worksheet In a particular database, each record occupies 620 bytes, and records are stored in in-place, spanned pages of 2KB. How many pages are required to stored 100 records?

62 Worksheet Assume a database with records of size 17 bytes, stored in unspanned, slotted 4KB pages. How many tuples can be stored in 10 blocks?

63 In-page dictionaries Some disk-based database systems keep a dictionary per page This solves the problem of variable sized records Also allows duplicate elimination Question: Why don t they keep a global dictionary

64 Conclusion

65 Conclusion Storage is not that hard Do you know what we have built? A Key-Value-Store

66 The End