Podcsts S2

Designing Data Intensive Applications

We dive back into Designing Data-Intensive Applications to learn more about replication while Michael thinks cluster is a three syllable word, Allen doesn’t understand how we roll, and Joe isn’t even paying attention. For those that like to read these show notes via their podcast player, we like to include a handy link to get to the full version of these notes so that you can participate in the conversation at&nbsp;. Sponsors  &nbsp;– &nbsp;Sign up today for a free 14 day trial&nbsp;and&nbsp;get a free Datadog t-shirt after creating your first dashboard. &nbsp;– Sign up for $100 in free credit and simplify your infrastructure with Linode’s Linux virtual machines. &nbsp;– Learn in-demand tech skills with hands-on courses using live developer environments. Visit&nbsp;&nbsp;to get an additional 10% off an Educative Unlimited annual subscription.  Survey Says          How important is it to learn advanced programming techniques?    Take the survey at: .       News  Thank you to everyone that left us a new review:  Audible: Ashfisch, Anonymous User (aka András)     The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair Douglas Adams Douglas Adams  In this episode, we are discussing Data Replication, from chapter 5 of “Designing Data-Intensive Applications”. Replication in Distributed Systems  When we talk about replication, we are talking about keeping copies of the same data on multiple machines connected by a network For this episode, we’re talking about data small enough that it can fit on a single machine Why would you want to replicate data?  Keeping data close to where it’s used Increase availability Increase throughput by allowing more access to the data   Data that doesn’t change is easy, you just copy it 3 popular algorithms  Single Leader Multi-Leader Leaderless   Well established (1970’s!) algorithms for dealing with syncing data, but a lot data applications haven’t needed replication so the practical applications are still evolving  Cluster&nbsp;group of computers that make up our data system Node&nbsp;each computer in the cluster (whether it has data or not) Replica&nbsp;each node that has a copy of the database   Every write to the database needs to be copied to every replica The most common approach is “leader based replication”, two of the algorithms we mentioned apply One of the nodes is designated as the “leader”, all writes must go to the leader The leader writes the data locally, then sends to data to it’s followers via a “replication log” or “change stream” The followers tail this log and apply the changes in the same order as the leader Reads can be made from any of the replicas This is a common feature of many databases, Postgres, Mongo, it’s common for queues and some file systems as well  Synchronous vs Asynchronous Writes  How does a distributed system determine that a write is complete? The system could hang on till all replicas are updated, favoring consistency…this is slow, potentially a big problem if one of the replicas is unavailable The system could confirm receipt to the writer immediately, trusting that replicas will eventually keep up… this favors availability, but your chances for incorrectness increase You could do a hybrid, wait for x replicas to confirm and call it a quorum All of this is related to the CAP theorem…you get at most two: Consistency, Availability and Partition Tolerance  Site Note: Can you ever have Consistent/Available databases?&nbsp;   The book mentions “chain replication” and other variants, but those are still rare  Example: Chain replication in Mongo:&nbsp;    Steps for Adding New Followers  Take a consistent snapshot of the leader at some point in time (most db can do this without any sort of lock) Copy the snapshot to the new follower The follower...

Designing Data-Intensive Applications – Single Leader Replication

We continue to study the teachings of&nbsp;Designing Data-Intensive Applications, while Michael’s favorite book series might be the Twilight series, Joe blames his squeak toy chewing habit on his dogs, and Allen might be a Belieber. Head over to&nbsp;https://www.codingblocks.net/episode121&nbsp;to find this episode’s full show notes and join in the conversation, in case you’re reading these show notes via your podcast player. Sponsors  Educative.io&nbsp;– Level up your coding skills, quickly and efficiently. Visit&nbsp;educative.io/codingblocks&nbsp;to get 20% off any course or, for a limited time, get 50% off an annual subscription.  Survey Says          With the new year coming, what kind of learning resolution do you plan on setting? I plan to learn ... Take the survey at: https://www.codingblocks.net/episode121.          News  So many new reviews to be thankful for! Thanks for making it a point to share your review with us:  iTunes: bobby_richard, SeanNeedsNewGlasses, Teshiwyn, vasul007, The Jin John Stitcher: HotReloadJalapeño, Leonieke, Anonymous, Juke0815   Joe was a guest on&nbsp;The Waffling Taylors. Check out the entire three episode series:&nbsp;Squidge The Ring,&nbsp;Jay vs Doors,&nbsp;and&nbsp;Exploding Horses. Be aware of “free” VPNs.  This iOS Security App Shares User Data With China: 8 Million Americans Impacted&nbsp;(Forbes) Facebook shuts down Onavo VPN app following privacy scandal&nbsp;(Engadget)   Allen will be speaking at NDC { London } where he will be giving his talk&nbsp;Big Data Analytics in Near-Real-Time with Apache Kafka Streams. Be sure to stop by for your chance to kick him in the shins! (ndc-london.com)  Scalability  Increased load is a common reason for degradation of reliability. Scalability is the term used to describe a system’s ability to cope with increased load. It can be tempting to say X scales, or doesn’t, but referring to a system as “scalable” really means how good your options are. Couple questions to ask of your system:  If the system grows in a particular way (more data, more users, more usage), what are our options for coping? How easy is it to add computing resources?    Describing Load  Need to figure out how to describe load before before we can truly answer any questions. “Load Parameters” are the metrics that make sense to measure for your system. Load Parameters are a measure of stress, not of performance. Different parameters may matter more for your system. Examples for particular uses may include:  Web Server: requests per second Database: read/write ratio Application: # of simultaneous active users Cache: hit/miss ratio   This may not be a simple number either. Sometimes you may care more about the average number, sometimes only the extremes.  Describing Performance  Two ways to look at describing performance:  How does performance change when you increase a load parameter, without changing resources? How much do you need to increase resources to maintain performance when increasing a load parameter?   Performance numbers measure how well your system is responding. Examples can include:  Throughput (records processed per second) Response time    Latency vs Response Time  Latency is how long a request is waiting to be handled, awaiting service. Response time is the total time it takes for the client to see the response, including any latency.  What do you mean by “numbers”?  Performance numbers are generally a set of numbers: i.e. minimum, maximum, average, median, percentile. Sometimes the outliers are really important.  For example, a game may have an average of 59 FPS but that number might drop to 10 FPS when garbage collection is running. Average may not be your best measure if you want to see the typical response time.   For this reason it’s better to use percentiles.  Consider the median (sort all the response times and the one in the middle is the median). Median is known as the 50th percentile or P50.  That means that half of...

Designing Data-Intensive Applications – Scalability

In this episode, Allen is back, Joe knows his maff, and Michael brings the jokes, all that and more as we discuss the internals of how databases store and retrieve the data we save as we continue our deep dive into Designing Data-Intensive Applications. If you’re reading these show notes via your podcast player, did you know that you can find them at&nbsp;? Well you do now! Check it out and join in the conversation. Sponsors  &nbsp;– Sign up today for a free 14 day trial&nbsp;and&nbsp;get a free Datadog t-shirt after creating your first dashboard. &nbsp;– Level up your coding skills, quickly and efficiently. Visit&nbsp;&nbsp;to get 10% off any course or annual subscription. &nbsp;– The fast and enjoyable project management platform that breaks down silos and brings teams together to ship value, not features.&nbsp;Sign up to get two additional free months of Clubhouse on any paid plan by visiting&nbsp;.  Survey Says          Which fast food restaurant makes the better fries? Take the survey at: .          News  We thank all of the awesome people that left us reviews:  iTunes: TheLunceforce, BrianMorrisonMe, Collectorofmuchstuff, Momentum Mori, brianbrifri, Isyldar, James Speaker Stitcher: adigolee   Come see Allen, Joe, and Michael in person at the 15th Annual Orlando Code Camp &amp; Tech Conference, March 28th. Sign up for your chance to kick them all in the shins and grab some swag. ()  Database Storage and Retrieval  A database is a collection of data. A database management system includes the database, APIs for managing the data and access to it.  RDBMS Storage Data Structures  Generally speaking, data is written to a log in an append only fashion, which is very efficient.  Log: an append-only sequence of records; this doesn’t have to be human readable.   These write operations are typically pretty fast because writing to the end of a file is generally a very fast operation. Reading for a key from a file is much more expensive though as the entire file has to be scanned for instances of the key. To solve this problem, there are indexes.  Generally speaking, an index is just different ways to store another structure derived from the primary set of data. Having indices incurs additional overhead on writes. You’re no longer just writing to the primary data file, but you’re also keeping the indices up to date at the same time.  This is a trade-off you incur in databases: indexes speed up reads but slow down writes.      Hash Indexes  One possible solution is to keep every key’s offset (which points to the location of the value of the key) in memory.  This is what is done for Bitcask, the default storage engine for Riak. The system must have enough RAM for the index though.   In the example given, all the keys stay in memory, but the file is still always appended to, meaning that the key’s offset is likely to change frequently, but it’s still very efficient as you’re only ever storing a pointer to the location of the value. If you’re always writing to a file, aren’t you going to run out of disk space?  File segmenting / compaction solves this.  Duplicate keys in a given file are compacted to store just the last value written for the key, and those values are written to a new file.  This typically happens on a background thread.   Once the new segment file has been created, after merging in changes from the previous file, then it becomes the new “live” log file. This means while the background thread is running to create the new segment, the locations for keys are being read from the old segment files in the meantime so that processes aren’t blocked. After the new segment file creation is completed, the old segment files can be deleted.  This is how Kafka topic retention policies work, and what happens when you run “force merge” on an Elasticsearch index (same goes for similar systems).       Some key factors in making this work well:  File format  CSV is not a great format for logs....

Designing Data-Intensive Applications – Storage and Retrieval

It’s time to learn about SSTables and LSM-Trees as Joe feels pretty zacked, Michael clarifies what he was looking forward to, and Allen has opinions about Dr Who. These show notes can be found at&nbsp;&nbsp;where you be a part of the conversation, in case you’re reading this via your podcast player. Sponsors  &nbsp;– Sign up today for a free 14 day trial&nbsp;and&nbsp;get a free Datadog t-shirt after install the agent. &nbsp;processes &gt; 200,000 API calls per minute. You like things that scale? Give their corporate page a visit! They are looking for new team members! Apply now at&nbsp;. &nbsp;– One of the top 50 nationally ranked universities, UCI offers over 80 certificates and specialized programs designed for working professionals. Spring registration is&nbsp;NOW OPEN!&nbsp;&nbsp;and reserve your seat today!  Survey Says          Do you leave your laptop plugged in the majority of the time? Take the survey at: .          News  Thank you for all of the great reviews:  iTunes: devextremis, CaffinatedGamer, Matt Hussey, index out of range Stitcher: Marcos Sagrado, MoarLiekCodingRokzAmirite, Asparges69   Sadly, due to COVID-19 (aka Coronavirus), the 15th Annual Orlando Code Camp &amp; Tech Conference has been cancelled. We’ll keep you informed of your next opportunity to kick us in the shins. ()  During this unprecedented time, TechSmith is offering Snagit and Video Review for free through June 2020. ()    SSTables and LSM-Trees SSTables  SSTable&nbsp;is short for “Sorted String Table”. SSTable requires that the writes be sorted by key.  This means we cannot append the new key/value pairs to the segment immediately because we need to make sure the data is sorted by key first.    What are the benefits of the SSTable over the hash indexed log segments?  Merging the segments is much faster, and simpler. It’s basically a&nbsp;mergesort&nbsp;against the segment files being merged. Look at the first key in each file, and take the lowest key (according to the sort order), add it to the new segment file … rinse-n-repeat.  When the same key shows in multiple segment files, keep the newer segment’s key/value pair, sticking with the notion that the last written key/value for any given key is the most up to date value.   To find keys, you no longer need to keep the entire hash of indexes in memory. Instead, you can use a&nbsp;sparse index&nbsp;where you store a key in memory for every few kilobytes from a segment file  This saves on memory. This also allows for quick scans as well.  For example, when you search for a key,&nbsp;Michael&nbsp;and the key isn’t in the index, you can find two keys in the sparse index that&nbsp;Michael&nbsp;falls between, such as&nbsp;Micah&nbsp;and&nbsp;Mick, then start at the&nbsp;Micah&nbsp;offset and scan that portion of the segment until you find the&nbsp;Michael&nbsp;key.     Another improvement for speeding up read scans is to write chunks of data to disk in compressed blocks. Then, the keys in the sparse index point to the beginning of that compressed block.  So how do you write this to disk in the proper order?  If you just write them to disk as you get them, they’ll be out of order in an append only manner because you’re likely going to receive them out of order. One method is to actually write them to disk in a sorted structure. B-Tree is one option. However, maintaining a sorted structure in memory is actually easier than trying to maintain it on disk though, due to well known tree data structures like red-black trees and AVL trees.  The keys are sorted as they’re inserted due to the way nodes are shuffled during inserts. This allows you to write the data to memory in any order and retrieve it sorted.   When data arrives, write it to the memory balanced tree data structure, such as a red-black tree. This is also referred to as a&nbsp;memtable. Once you’ve reached a predefined size threshold, you dump the data from memory to disk in a new SSTable file. While the new...

Designing Data-Intensive Applications - SSTables and LSM-Trees

We dig into the details of how databases use B-trees as we continue our discussion of Designing Data-Intensive Applications while Michael’s description of median is awful, live streaming isn’t for Allen, and Joe really wants to bring us back from the break. For those reading this via their podcast player, this episode’s full show notes can be found at&nbsp;&nbsp;in all their glory. Check it out, as Joe would say, and join the conversation. Sponsors  &nbsp;– Sign up today for a free 14 day trial&nbsp;and&nbsp;get a free Datadog t-shirt after install the agent.  Survey Says          What tools are you using to ease WFH? Take the survey at: .          News  We really appreciate the latest reviews, so thank you!  iTunes: Anips79, Jacobboyd23, LoadedGalaxy, JenT Avid Listener   Pluralsight is free for the month of April! () TechSmith is offering Snagit and Video Review for free through June 2020. () Remember when we gushed over Zoom?  Zoom: Every security issue uncovered in the video chat app&nbsp;() Zoom Go Boom&nbsp;()   Maybe should use Jitsi instead of Zoom. () Be on the lookout for live streams of Joe on&nbsp;&nbsp;or Twitch!  B-Trees are Awesome  B-trees are the most commonly used indexing structure. Introduced in 1970, and called ubiquitous 10 years later. They are the implementation used by&nbsp;most&nbsp;relational database systems, as well as a number of non-relational DB’s. “Indexing” is the way databases store metadata about your data to make quick look ups. Like the SSTable, the B-tree stores key/value pairs sorted by key. This makes range query look ups quick. B-trees use fixed block sizes, referred to as pages, that are usually 4 KB in size which (generally) map well to the underlying hardware because disks are typically arranged in fixed block sizes. Every page has an address that can be referenced from other pages. These are pointers to positions on a disk. Knowing (or being able to quickly find) which page the data you are looking for is in, drastically cuts down on the amount of data you have to scan through. B-trees start with a root page. All key searches start here.  This root will contain references to child pages based off of key ranges. The child pages might contain more references to other child pages based off of more narrowly focused key ranges. This continues until you reach the page that has the data for the key you searched for.  These pages are called leaf pages, where the values live along with the key.     The branching factor is the number of references to child pages in one page of a B-tree.  The branching factor is tied to the space needed to store the page references and the range boundaries.  The book states that it’s common to have a branching factor of several hundred, some even say low thousands!   The higher the branching factor means the fewer levels you have to go through, i.e. less pages you have to scan, when looking for your data.   Updating a value in a B-tree&nbsp;can&nbsp;be complicated.  You search for the leaf node containing the key and then update the value and write it to disk.  Assuming everything fits in the page, then none of the upstream references change and everything is still valid.   If you are inserting a new key, you find the leaf node where the key should live based on the ranges and then you add the key and value there.  Again, if everything fits in the page, then similar to the update, none of the upstream references need to change. However, if the key/value would exceed the size of the page, the page is split into two half-pages, and the parent page’s references are updated to point to the new pages.  This update to the parent page might require it to also be split. And this update/split pattern might continue up to and including the root page.       By splitting the pages into halves as data is added that exceeds the page size, this keeps the tree balanced. A balanced tree is the secret to consistent lookup times. It terms of big-O, a...

Designing Data-Intensive Applications - To B-Tree or not to B-Tree

The world of computer programming is vast in scope. There are literally thousands of topics to cover and no one person could ever reach them all. One of the goals of the Coding Blocks podcast is to introduce a number of these topics to the audience so they can learn during their commute or while cutting the grass. We will cover topics such as best programming practices, design patterns, coding for performance, object oriented coding, database design and implementation, tips, tricks and a whole lot of other things. You'll be exposed to broad areas of information as well as deep dives into the guts of a programming language. While C# and Microsoft.NET are our preferred development platform, most topics discussed are relevant in any number of Object Oriented programming languages such as Java, Ruby, PHP, etc.. We are all web and database programmers so we discuss Javascript, HTML, SQL and a full spectrum of technologies and are open to any suggestions anyone might have for a topic.  So please join us, subscribe, and invite your computer programming friends to come along for the ride. 