INMEMORY COMPUTING CHALLENGES Larry Strickland Data Kinetics LARRY

IN-MEMORY COMPUTING: CHALLENGES Larry Strickland Data. Kinetics

LARRY STRICKLAND Chief Product Officer ? © 2019 Data. Kinetics Ltd. All rights reserve

? © 2019 Data. Kinetics Ltd. All rights reserve

IS THE MAINFRAME STILL RELEVANT? © 2019 Data. Kinetics Ltd. All rights reserve

WHY IS IN-MEMORY CONSIDERED (ON MAINFRAMES) It’s nearly always about the $ However, when looking deeper, the rational is always one of: • Improve Response Time • Reduce Elapsed Time • Reduce CPU Usage © 2019 Data. Kinetics Ltd. All rights reserve

TWO PARTS …. Reducing I/O wait times • Improves Response Time • Reduces Elapsed Time • (minimal impact on CPU used) Reduced Code Path Improves Response Time Reduces Elapses Time Reduces CPU Usage © 2019 Data. Kinetics Ltd. All rights reserve

MAINFRAME USES MANY TECHNIQUES FOR REDUCING I/O Caching Buffering • DB 2 buffering • Buffer pools • 3 rd-party buffer tools like BPT, BPA 4 DB 2 • VSAM Buffers CICS managed data tables COBOL internal tables SSD ? © 2019 Data. Kinetics Ltd. All rights reserve

TABLEBASE – IN-MEMORY TABLE MANAGER Removes I/O Reduces Code Path © 2019 Data. Kinetics Ltd. All rights reserve

WHAT WE’VE LEARNED ALONG THE WAY • Which data? • Indexing is very important • Not all Hashes are created equal • Rules, Rules • Separate out Read-Only • Accusations fly © 2019 Data. Kinetics Ltd. All rights reserve

WHICH DATA? What to put in-memory © 2019 Data. Kinetics Ltd. All rights reserve

BIG OR SMALL TABLES Large data takes longer to search, so has huge Elapsed time advantages in being accessed from Memory • Great Response Time Improvement Every row read into memory Not every row read once it is there • Great Elapsed Time Improvement • CPU impact is minimal Small data - small in size, accessed very frequently (Reference Data) • Good Response time Improvement • Good Elapsed Time Improvement • CPU impact is huge Every row read into memory Every row read potentially 1, 000’s of times © 2019 Data. Kinetics Ltd. All rights reserve

IN-MEMORY TECHNOLOGY: LOOKING AT CPU Consider the large table here You won’t gain much my reading it into memory and Product table (200 rows) accessing the data from there – as each row isn’t read frequently Different story for smaller reference data tables Tax region table (5000 rows) Top table is read once into memory, then each row accessed 50, 000 times from memory Bottom table is read once into memory then each row is accessed 2, 000 times from memory In actual use, some rows are read once into memory and accessed from there many millions of times per day… Data from every transaction from previous day (10, 000 rows) © 2019 Data. Kinetics Ltd. All rights reserve

RESULTS FROM CREDIT CARD PROCESSING Challenge Reconciliation batch processing taking too long Solution Move a table describing the credit card options into table. BASE Each transaction required data from that table Results 97% reduction in CPU time Batch job that took 8 hours to complete now takes 15 min © 2019 Data. Kinetics Ltd. All rights reserve

BIG OR SMALL DATA - ECONOMICS Large data takes longer to search, so has huge Elapsed time advantages in being accessed from Memory • Great Response Time Improvement • Great Elapsed Time Improvement • CPU impact is minimal Cost neutral or more expensive (increased memory requirements) Small data - small in size, accessed very frequently (Reference Data) • Good Response time Improvement • Good Elapsed Time Improvement Reduces cost • CPU impact is huge © 2019 Data. Kinetics Ltd. All rights reserve

INDEXING IS IMPORTANT Probably obvious but… © 2019 Data. Kinetics Ltd. All rights reserve

INDEXING IS IMPORTANT COBOL Internal Tables are in Memory Often used to manage temporary tables Primary index – no alternative indexes • Serial Search required if alternative searches required © 2019 Data. Kinetics Ltd. All rights reserve

ONE CUSTOMER’S EXPERIENCE Challenge A COBOL program was using an internal table and a binary search The search code was called 1. 25 million times and had 4 searches in it Took over an hour of CPU to execute Solution Replace the 4 searches with calls to table. BASE Results 98. 3% reduction in CPU Now takes less than a minute to execute © 2019 Data. Kinetics Ltd. All rights reserve

INDEXES Indexing for Speed (with table. BASE – but probably generally applicable for other implementations) • <10 rows – serial search • >10, <100 rows – binary search • >100 rows – Hash search © 2019 Data. Kinetics Ltd. All rights reserve

HASH INDEXING Not all Hashes are created equal © 2019 Data. Kinetics Ltd. All rights reserve

WHAT DOES HASH DO? Maps space to another space • One way • Typically shrinks (doesn’t have to) • Arbitrary bytes to specific length • Can encrypt © 2019 Data. Kinetics Ltd. All rights reserve

WHEN USING HASH TO INDEX Hash is used to calculate a slot • Slot calculated can simply be a pointer to the key (if in memory) • Need to deal with collisions Density is #keys/#slots Slot (address) Slots • Higher value less memory used More collisions • Lower value more memory Less collisions Possible values of Key © 2019 Data. Kinetics Ltd. All rights reserve

00 0 10 , 0 00 50 , 0 0 10 0 0, 00 20 0 0, 00 30 0 0, 00 40 0 0, 00 50 0 0, 00 60 0 0, 00 70 0 0, 00 80 0 0, 00 90 0 0, 1, 000 00 0, 2, 000 00 0, 3, 000 00 0, 4, 000 00 0, 5, 000 00 0, 6, 000 00 0, 7, 000 00 0, 8, 000 00 0, 9, 000 00 0, 00 0 1, HASH ALGORITHM BEHAVIOR - FIRST ATTEMPT Collisions / Key 0. 173 0. 168 0. 163 0. 158 F Ideal 0. 153 0. 148 © 2019 Data. Kinetics Ltd. All rights reserve

10 1 0. 1 1, 100 00 10 0 , 0 0 50 0 , 0 10 00 0, 0 20 00 0, 0 30 00 0, 0 40 00 0, 0 50 00 0, 0 60 00 0, 0 70 00 0, 0 80 00 0, 0 90 00 0 1, , 00 00 0 0 2, , 00 00 0 0 3, , 00 00 0 0 4, , 00 00 0 0 5, , 00 00 0 0 6, , 00 00 0 0 7, , 00 00 0 0 8, , 00 00 0 0 9, , 00 00 0 0, 00 0 1, 00 10 0 , 0 0 50 0 , 0 10 00 0, 0 20 00 0, 0 30 00 0, 0 40 00 0, 0 50 00 0, 0 60 00 0, 0 70 00 0, 0 80 00 0, 0 90 00 0, 1, 00 00 0 0 2, , 00 00 0 0 3, , 00 00 0 0 4, , 00 00 0 0 5, , 00 00 0 0 6, , 00 00 0 0 7, , 00 00 0 0 8, , 00 00 0 0 9, , 00 00 0 0, 00 0 SOME RESULTS (CORRELATED KEYS) Collisions / Key CPU / Key 10000 1000 100 6 10 Ideal 1 6 F 0. 1 0. 01 © 2019 Data. Kinetics Ltd. All rights reserve

0 0 1, 0 10 00 , 0 50 00 , 10 000 0, 20 000 0, 30 000 0, 40 000 0, 50 000 0, 60 000 0, 70 000 0, 80 000 0, 90 000 1, 0, 0 00 00 2, 0, 0 00 00 3, 0, 0 00 00 4, 0, 0 00 00 5, 0, 0 00 00 6, 0, 0 00 00 7, 0, 0 00 00 8, 0, 0 00 00 9, 0, 0 00 00 0, 00 0 1, 0 10 00 , 0 50 00 10 , 000 0 20 , 000 0 30 , 000 0 40 , 000 0 50 , 000 0 60 , 000 0 70 , 000 0 80 , 000 0 90 , 000 1, 0, 0 00 00 2, 0, 0 00 00 3, 0, 0 00 00 4, 0, 0 00 00 5, 0, 0 00 00 6, 0, 0 00 00 7, 0, 0 00 00 8, 0, 0 00 00 9, 0, 0 00 00 0, 00 0 LOOKING AT SOME ALTERNATIVES Collisions / Key - Best CPU / Key - Best 30 0. 12 25 0. 1 20 0. 08 15 10 5 F S 0. 06 D 0. 04 Ideal 0. 02 F S D © 2019 Data. Kinetics Ltd. All rights reserve

SO WHERE DOES THIS LEAVE US? If we don’t know much – should use a Hash with low collisions • I recommend the Fowler-Noll-Vo Hash function (FNV) But, if we know • Well distributed key • Small number of keys • V. Low Density …. . we may consider a cheaper function to calculate Hash © 2019 Data. Kinetics Ltd. All rights reserve

SPECIFIC HASHES With some knowledge of a key, we can create some very effective (high performance, low collisions) Hashes. E. g. Canadian Postcodes e. g K 1 A 3 M 2 • Letters D, F, I, O, Q or U are not used • Letters W, or Z are not used in first position • 6 bytes have 300, 000, 000 combinations • Can limit to 7, 400, 000 with knowledge of distribution • Only about 830, 000 in use © 2019 Data. Kinetics Ltd. All rights reserve

STANDARD HASH © 2019 Data. Kinetics Ltd. All rights reserve

RULES, RULES Most frequently read tables © 2019 Data. Kinetics Ltd. All rights reserve

RULES PROCESSING Business rules are among the organization’s most valuable intellectual property. For speed of processing, business rules were often embedded within mainframe applications. For business flexibility, these are often externalized into rules tables Rules tables accessed potentially 100’s of times per transaction • Processing transaction logic • Fraud Rules © 2019 Data. Kinetics Ltd. All rights reserve

SEPARATE OUT READ-ONLY Getting more efficient © 2019 Data. Kinetics Ltd. All rights reserve

SHARED MEMORY TABLES Read and Write locks are standard practices to allow multiple programs to access the same table (almost) simultaneously • Routines required to deal with failures to remove locks and clean up • 60 -85% of code path! Alternatives • Separate out Read-Only data (no locks required) 3 to 4 times improvement • Use table versioning and logical switches © 2019 Data. Kinetics Ltd. All rights reserve

LET THE ACCUSATIONS FLY What happens when you remove the IO wait time © 2019 Data. Kinetics Ltd. All rights reserve

ACCUSATIONS You’re using all the memory You’re using all the CPU! © 2019 Data. Kinetics Ltd. All rights reserve

CONCLUSION © 2019 Data. Kinetics Ltd. All rights reserve

CONCLUSION The Mainframe is still relevant In-memory can help on multiple fronts • But needs a business case In-memory small data has a bigger impact on $ Indexing (including the appropriate Hash function) is essential Rule tables are often the most read Careful what you wish for © 2019 Data. Kinetics Ltd. All rights reserve