Well, thank you all for coming, and David, thank you for that very kind introduction. So I'm going to be talking about whether we can upload our consciousness to the cloud. I should say that that is not actually the main focus of my research. I'm not actively involved in trying to do that, though as you'll see there are some people who are, but I thought it would be an interesting way to sort of frame a discussion of the kinds of things that I'm interested in. So I really wanted to start with this, which is a picture from Star Trek, which was really one of my favorite shows when I was a kid. And for those of you who don't know, this is the transporter from Star Trek, and the idea is that the characters on the show can stand on these little white discs, and then they slowly dematerialize from the enterprise, from their spaceship, and rematerialize somewhere else. And it actually turns out that the reason that there is a transporter in Star Trek was that the early set designers said it would be too expensive to bring the spaceships to the planet every episode. But it really is like one of the iconic features. It's turning a bug into a feature. It's really one of the iconic aspects of Star Trek. And when I was a kid, I spent a lot of time wondering about, well, what would happen if I dematerialized and then rematerialized somewhere else? Would I really be the same person there? And sort of the premise of the transporter in Star Trek is that it destroys each one of your molecules, and then it puts that molecule in exactly the same place in some other location. And at least for me, even though I was a little troubled by it, I concluded that, yeah, I would likely be the same person with the same thoughts when I was transported to somewhere else. That's not a universal feeling, and I think one of those might be Dr. McCoy, and fans of the show will know that Dr. McCoy did not feel comfortable being dematerialized and was usually worried about whether he was the same person. But the fact that I was convinced I was the same person basically put me in the camp of being a materialist, in that I believe that whatever it is that makes me me, whatever it is that gives me my thoughts and my feelings are contained in my physical body, unless I posit that the soul is transported along with the brain. But that was not something that was covered in the technology. So the idea is that somehow my existence emerges from my brain. And so that actually did, thinking about that actually is part of what set me on the road to being a neuroscientist. The other thing that set me on the road to being a neuroscientist, this again dates me, this is from Star Wars and this is from Terminator, was the idea that it would be, well, if the brain is a physical circuit, then why couldn't we build machines that have the same abilities that we do? And obviously, I'm not the first to think about that. And so I thought that it would be really cool to be able to build machines. And in fact, for my graduate work, what I did was I worked on artificial neural networks from a biological perspective. So I was interested in figuring out how the neural circuits that are actually part of real organisms differ or could be sort of abstracted and made into something that could do computation. Around the time that I finished my graduate work, I had to make a decision was I going to continue to try to build a terminator or was I going to try to understand how the brain worked. And I went with understanding how the brain works, but I never lost interest in that. Interestingly, a lot of my friends who were in that field at the time now work for companies like Google and Facebook. And as many of you may know, this technology actually kind of now work. So you can get if you, some of my families from the Bay Area.  And pretty soon they're going to be common. So in fact, Elon Musk, who is the founder of Tesla, and a great inventor who among other things wants to send people to Mars, having spent a lot of time working with his company, developing self driving Teslas is actually worried that artificial intelligence AI will take over. And he is interested in making sure that that doesn't happen. And so none of this though addresses exactly what I'm going to be talking about, which is not whether we can build robots that either serve coffee or drive cars or take over the world. But can we can we achieve immortality by uploading our brain to the cloud? And this is from a movie, Johnny, starring Johnny Depp a couple years ago, where Johnny Depp for various reasons is he's pretty grim about it here. But he's got to upload his brain to a computer. And it's not the first move. So there are people who seriously who take that idea seriously. And last year there was an article in the New York Times called the neuroscience of immortality. And Amy Harmon went and interviewed a bunch of scientists about whether they thought that this was going to be possible sometime soon, and what the prospects were. And there are people who seriously want to achieve immortality by somehow taking their brains and taking the essence of what is in their brains and putting them onto a computer. And so is that possible? Well, I will say that there's one very well known scientist named Winfrey Denk, who is well known to many of the neuroscientists or non neuroscientists at the lab, who is a director of the very prestigious Max Planck Institute who says why I can see he says, I can see within say 40 years that we would have a method to generate a digital replica of a person's mind. And then he says, well, it's not my primary motivation, but it is a logical outgrowth of our work. So reasonable people, and I think everybody who knows him would agree that he's reasonable actually do believe that this is possible. So what would that look like? So I'll just add that there's actually a project funded by a Russian billionaire to achieve it's called the Avatar project. And it's got the milestones here and they literally want to achieve uploading consciousness to the cloud by 2045. So what what what would that entail what would be required and that's really going to be the focus of my talk, which is what what is it that makes us us and how can we figure out what what that is and really what it is that makes us us what is the neural circuit. It's as David mentioned, there are 100 billion neurons and 100 trillion connections between these 100 billion neurons in the brain. And it is the details of of those connections. It is how those neurons communicate with each other that endows us with our our character with our individuality with our ability to do everything that we do to remember things to think to feel to act. All those things. Somehow that circuit is what makes us us. And so what I'll be telling you about is the technology that we've been developing to actually figure out what that circuit is. So the idea that that behavior arises from a neural circuit actually goes back quite far. The earliest demonstration of it that that I've seen goes back to Renee Descartes, who's some 350 years ago now, postulated a mechanism by which we withdraw our foot from a hot fire. Right.  So so how does that work? And he came up with really the first mechanistic circuit mechanism for that. And here's what he proposed. He proposed that the flames of the fire displaced the skin, which pulls on a tiny thread. The thread opens a pore in the ventricle. And then the animal spirits flow from the ventricle F through a hollow tube. And the animal spirits inflate the muscle of the leg causing withdrawal. So not everyone here has a medical background. But let me just clarify that that is not actually in detail how we think this happens today. So we know that the animal spirits are actually contained a little bit to the front here. No, it's easy to make fun of him. He had several disadvantages, which is he proposed this before they figured out that a good way to do science is actually to do experiments. So the way he came up with this was he just wrote it down. He was a smart guy, and he wrote down some smart things, but he did not use the scientific method to propose a hypothesis and then test it. But what I like about the hypothesis is that it at least has the form of a physical explanation for what's going on. And in that way, it really is a milestone in neuroscience. I mean, you know, we're making I'm making fun of it. But but it really it you one could imagine building a machine or a physical device based on these principles, right? So in fact, we we would call that a reflex. And the reflexes is worked out in other cases actually it's worked out for that too. But this is probably the the most famous one when you go to the doctor, and he taps your knee. What happens is that the hammer pulls on the patellar tendon, which stretches this right here. And then there's a nerve up here.  And then the activity here activates another nerve that activates the muscle. Okay, and that's what it's when the muscle is activated and contracts that you kick your knee. Right? So this is actually a simple circuit that we understand and that explains something that is relevant to all sorts of things. So it's a it's a circuit based explanation for what's going on. And I should I should add that although I'm not talking tonight mostly about neuropsychiatric disorders. Neuroscience circuits disrupted circuitry is at the at the basis of many if not most neuropsychiatric disorders. So right now over the last 20 years, I would say, drug companies have largely stalled in making new drugs for neuropsychiatric disorders for conditions like depression and addiction and bipolar and schizophrenia. They've they've actually they've run out of ideas that many if not most pharmaceutical companies have actually shut down their research because the traditional approaches to to making progress on these disorders do not involve circuits. And because we don't understand enough about these circuits, they these these companies have have sort of given up. So what where has the progress been well actually interestingly most of the progress in the last decade or two in treating severe neuropsychiatric disorders does not come from from drugs. It actually comes from Oh, well, okay, this is a slightly different slide. But basically, so the the usual the pharmaceutical approach is to basically take imagine that the the brain is soaked in a chemical in in some neurotransmitter and that if you the idea is to provide a drug. And if you give a drug that changes the level of some chemical like serotonin that you can ameliorate one condition like depression.  But the idea is that it treats the brain largely as being bathed in this in this sort of pharmacological soup. And what these slides are out of order. But what I was going to say is that the the progress over the last 10 or 20 years in treating neuropsychiatric disorders has not come from drugs. It's come from targeting specific circuits of which we know only a handful. But the ones that we do when properly targeted can actually result in some very impressive improvements. So for especially for Parkinson's for chronic pain, pain for depression, there are some really impressive results. But obviously neurosurgery is is is a is a very invasive kind of treatment. So right now, these these treatments are only used in cases where the traditional pharmacological approaches fail. So that that's my my digression on neuropsychiatric disorders. And I'm going to return to the main path of my talk, which is going to which is focusing on the fact that we need to know the brain's wiring diagram. So that's what's missing. We really don't know the brain's wiring diagram. If we knew it in in greater detail, we would have a better understanding of how we think and we feel and what goes wrong in these various disorders. So those of you who read the news and follow the science paper science times, let's say, might wonder, Well, what are you talking about? We recently actually did figure out the brain's wiring diagram. And so earlier this over this summer, with a lot of fanfare, there was an announcement that we now know the the connectome of the human brain. This was a the result of a very impressive multi year multi center, multi million dollar project called the human connectome project led by David van Essen. And they they carefully went through human brains and discovered they they cataloged the various areas, and they discovered 97 new regions bringing the total to 180 and I'm I don't want to diminish this in any way. This was a real tour de force. And it is important work. Similar work has been done in the mouse, which is the organism that along with the rat that my lab studies, where we know a fair amount about the wiring of the mouse. And I'm just going to make a little a little digression here and explain that the the mouse, you might wonder, you know, why why can we study the mouse if we're interested in people turns out that the the mouse the wiring diagram of the mouse brain is as far as we know very similar to that of the human brain, the monkey brain. And in general, the the the overall organization of the nervous system of mammals is is shared. So here's the mouse and here's the human. And if these look similar to you don't don't be distressed because they also look similar to me and they look similar to any neuro anatomist. And so the idea is that all these different organisms mouse and rat and rabbit and goat and cat and cheetah lion dog and human share the same basic organizational scheme with the obvious difference here of size. And you know, here's the mouse and here's the human. So basically, it seems like what happened is over evolution that mammals figured out how to build a brain. And then they built it on different scales. All right. So all right, we have the mouse connectome, so to speak, the human connectome. Why isn't that enough? Well, basically what we have is something that looks kind of like this. So these are the this is a highway map of the United States. And this is sort of the scale on which we we know the circuitry of the human brain. I didn't count up these little nodes here, but they're probably about 100 or 200, which is about as many areas as they discovered in the in the human connectome at least. But what we really need is something that's more like this on a very different scale. So this is, of course, Cold Spring Harbor, and this is 25a, which is what you came in on to go. And this is Bungtown Road. So we need a much, much much higher resolution map of the connectivity of the brain in order to really navigate through these circuits, right? It's nice to know that if you get on to a major highway, you can end up in Cincinnati. But if you actually want to go if you if you want to understand how signals, or in this case, cars go around, you need much higher higher resolution. So why don't we just get that? Why don't we just go and use whatever techniques were used to get the other atlases and use that to figure out this thing at at higher resolution? The limitation isn't simply that, you know, microscopes don't see well, we can we can see individual cells and synapses. But this sort of illustrates the problem. So here at up close is what an actual bit of cortical circuitry looks like. So what you see here are about a dozen or so neurons in the cortex of a mouse. Each one of this is the cell body of the cell. And this is the dendrites that receives information. And coming out of some of these are axons that send information. And what you can see is that it's a big mess. So if you wanted to know what this neuron, which where this neuron sent its its information where it sent its wires, you can see that you'd be really at a loss, right? You you could follow it up to there and boom, you lost it, right? And if you wanted to know how all these wires where all these wires went and how they were connected, what that spaghetti is like, you would really be you would find that challenging. And that right there is the problem that we face when trying to decipher and tease apart the wiring of a of a real neural circuit in the brain. So what can we do? Well, traditionally, the solution to that the way we figure out neural circuits is we don't worry where individual neurons go. We look at where collections of neurons go. So if we want to know where the neurons from one region send their information, we inject a tracer. There are lots of different tracers, but and some they all have special properties. But in general, what they do is they label neurons that in this case green. And then what what we can do is look at other brain regions and see if we see green. And the way this this experiment is set up, the only source of green is the neurons here that we labeled. So if we inject our tracer here, and we dissect out an area here, a different part of the brain, and we see green, then we know that there's information from these neurons that got sent to those to that location. If we dissect out five different regions, and we see green in three, we know that the information went from each of these to front. We know that the information went from this region to each of those regions, and not to these other two. But unfortunately, what we can't tell from those kinds of experiments is whether it looks like this where each neuron sends its information to exactly one region, or whether, for example, it looks like this where each neuron sends its information to all three of those regions, right? Or, right, so here this neuron is sending its information here and there and there and this to there and there and there and so on. Or maybe it looks like something more complicated. And each of those, each of those different pictures has different implications for how we think about information flowing through the brain. So for example, if your auditory information can simultaneously be must always go simultaneously to the part of your brain that processes fear and the part of your brain that processes music, then you might think that you would always be afraid when hearing music, right? And that would be, that wouldn't make sense. It wouldn't, it doesn't conform with how we think things work. And in fact, there are different neurons that send their information to different places. And so if we're really going to understand how that circuit works, we need to understand how which of these situations, which of these configurations is, is how it goes. So this is just to drive this point home. This is an example taken from one of my students, Eustis, who may be in the audience. So Eustis is a very hard worker, but after working very hard for a while, he decided he was just going to go on vacation.  And so he figured, I don't know, he would go to Brazil, because that might be a fun place or if the next flight was to India, maybe he'd go there. And so he showed up at the airport. And he was very disappointed to discover that that La Guardia, which looks like a bus station, only flies domestically, except for this one route, I don't know where that one goes. So that that sort of drives home the importance of routing of information. So in this analogy, the airports are neurons. And if the United States had 100 billion airports, then it would be a perfect analogy. All right, so there is a technique that allows us to trace the flight paths of individual neurons. And it's a very tedious one. You can take each individual neuron and fill it with a tracer. And it's a very laborious method.  And that there is an art to doing that. It's been around for 100 years. A lot of what we know actually comes from that kind of work. But as as you can imagine, it's incredibly slow and laborious. So you know, we've been talking numbers, there are millions and billions of cells in the brain. And really, if that's the way we're going to figure out how the brain is wired up, that is serious job security for teams and teams of people. And no, I mean, again, I this is this is a paper that was published in a respectable journal a few years ago. It's one that my lab refers to a lot. But you know, it represents the state of the art, there were 25 neurons successfully traced in 28 rats. And if you do the math, it takes a long time to get 100 million, or even 100,000. So there are some some clever approaches that have emerged over the last decade or so. And this is really the one that is the inspiration for the method that that my lab developed. It's called brain bow. One of the keys when coming up with a new technique is to give it a catchy name. So the idea is it causes neurons in the brain to form the colors of the rainbow, hence brain bow. And using some very clever genetic manipulations, what they did was they tricked neurons into expressing proteins that have colors. And each neuron in this in this specially designed mouse, expresses a random collection of any of these different colored proteins. And so the idea is that it's like painting by numbers, each neuron will have a unique color. And because each neuron has a unique color, these axons, these little wires which otherwise would look completely identical, the idea is that they won't look identical. This one will be blue, and this one will be red, and this one will be purple. So in principle, the theoretical diversity of this approach allows for up to 200 different colors, which is really quite a few. But the problem is that similar colors are hard to distinguish. So although the theoretical diversity based on this genetic trick is over 200, in practice, using real microscopes, you can't resolve more than just a few 10 as the absolute limit, but maybe three or four typically. And that's shown here, based on this randomness, I can be pretty confident that this neuron and this neuron and this neuron are all different colors. But they appear to be the same. So it's a sort of Zen issue. If neurons are different colors, but you can't see them, can you trace? Well, do they make a sound? I'll work on that one. So but that was the inspiration. That was the inspiration for our idea. The idea is that if only you could resolve those colors, if only there were more than than 200, more than five or 10 colors that you could resolve, then then we'd be set. And so because I'm at Cold Spring Harbor, which is effectively ground zero of DNA sequencing, I had the idea that instead of using colors, we could use sequences of nucleic acid. So as as many of you know, our genetic material consists of long strings of of four nucleotides, four letters, AG, ATGC, and any long string of them combined together, eventually produces a unique long string. So if you just put together random strings of letters, you can be pretty confident that those will be unique. So here's the idea in graphical form. If we could just replace those colors with numbers, if we have a way to read out the numbers, we're set. So each neuron, the idea is to express a unique sequence of DNA, a genetic barcode, a unique random label. And the theoretical diversity here is effectively infinite. So here's the core idea. Let's recast connectomics as a problem of high throughput DNA sequencing by labeling each neuron with a unique DNA sequence, a unique barcode. So why sequencing? Well, there are two reasons sequencing is incredibly cheap, and really fast. And so this is a plot of the cost of DNA sequencing over the last 10 or 15 years, 15 years, I guess. Back in 2001, where when the human genome was sequenced, thanks in part to Jim Watson's efforts and a lot of the efforts here at Cold Spring Harbor, the cost of a genome was of order a billion dollars. Yeah, of order a billion dollars. And you can see that the cost drops. So this is a logarithmic scale and the cost was dropping at a very respectable clip. So this line here is called Moore's Law, and that is the rate at which computers have gotten faster and cheaper with time. And so they've gotten faster and cheaper at an impressive rate, as everyone knows. This my my iPhone here has more computing power than the top of the line computer that I used to do my PhD thesis 30 years ago, in fact, considerably more. In fact, I looked it up, and it has as much computing power as a supercomputer from the early 80s, which is a little bit before I did my thesis. So this is a very respectable rate for things to get faster and cheaper. But what you can see is that the rate at which DNA sequencing has gotten faster and cheaper was was keeping up with Moore's Law up here. And then starting in 2007, due to the advent of so called next generation sequencing, it there was a kink and it started dropping at an incredibly, incredibly, incredibly fast rate. And so this curve is not quite as straight as that one, but it's still getting faster and cheaper and cheaper and cheaper. And so if you can convert, what we are reasoning was if we could convert the problem of connectivity into a problem of DNA sequencing, it would now be tractable, there would now be, it would not be expensive to figure out the wiring of an entire brain. Alright, so the idea is that we can randomly, that random sequences can uniquely label neurons. And just to drive that home, there are four different nucleotides. So the number of possible barcodes of length one is four, right, it can be A or T or G or C of length two, it's four times four equals 16, because you can have an A in the first place, and any of the four in the second place, you can have a T in the first place, any of the four in the next place, and so on. And so it's 16. And the overall pattern is four to the nth power. And we use barcodes that are of length 30, which are, which produce an astronomical number of possibilities. So 30 is a very short piece of DNA, we have over a billion nucleotides in our genome. So 30 is nothing. And yet, even by the time we get to a barcode of length 30, we can be guaranteed that we have a unique sequence. It turns out that 10 to the 18 is more than the number of all the grains of sand on the earth. So already by the time we get to even these short barcodes, we have astronomical numbers of possibilities. So the 10 to the 18 grains of sand are all the beaches of the world. And there are only about a few million neurons in the mouse cortex, which means that it says, though, each particular neuron, even if we barcoded every neuron in the mouse's brain with this diversity, every neuron in the mouse's brain would be selecting from 100 billion different possible unique choices and still without overlap. So because we're drawing these random barcodes from such a large pool, the chances that two neurons get the same barcode are infinitesibly small in theory. There are some practical issues that I'm going to skip over. But in theory, that's true. Alright, so how do we do that? Well, the way we do it is we don't actually currently barcode neurons. We actually barcode viruses, which we then used to infect neurons. So a virus, it turns out, is just a little it's nature's delivery system for nucleic acids. And our lab and many other labs use viruses to deliver sequences of nucleic acids that we would like. So what we did was slightly different, which is rather than having all the viruses in our tube be the same, which is usually the way we do it. Instead, we made each virus unique by this is a little picture of how you make a virus.  And these pieces have random sequences. So we insert these pieces with random sequences in these. That produces what we call a plasmid library and from there we get a virus library. So each one of these little things here is a virus and we've just for for illustration purposes given it a unique two digit number but in fact it should have a unique 18 digit number. Alright, and so then we take those viruses and we inject it into a into one part of the brain. And then we've also engineered a a protein that drags this barcode out to the synapse. And so this picture here summarizes about three years of work by a former graduate student of mine in Paikon along with some help from Eustis. But that is the the the overall scheme is that these viruses express or have this protein that grabs onto the barcode and drags it out to the synapse. So our first application of this was to look at the connectivity of a brain region called the locus ceruleus.  It's the sole source of noradrenaline to the cortex. So noradrenaline is a is a neuromodulator that causes neurons to wake up. It's like an alert signal. Alright, so when you get squirted when neurons get squirted with noradrenaline they become active. It says pay attention. There's something that's about to happen. And what we're interested in was how this circuit was wired up. And the reason is that the traditional model of how the locus ceruleus is wired up was that the locus ceruleus it was thought produced a sort of global signal. So the idea was that each one of these neurons just sort of spread its neurotransmitter globally throughout the brain as though there was a single alarm bell that when you hit it caused the entire brain to wake up. But there was another view that seemed sensible to us, which is that well, maybe you don't need your entire brain to become alert all at once.  Maybe that should be revved up and maybe the rest of the brain can can be not quite as revved up. So maybe these neurons could could provide more specific inputs to particular places. Right. So if in that view, maybe one neuron projected there and another to another part and a third to a third part of the brain. So the anatomy there as you as you could see if if all these neurons on average project to all places that if you just label these green, you can't tell these apart. What you need for this is to know where individual neurons project. And so Eustace came up with an experimental design in collaboration with our lab next door, Florin Albianu. And what they did was they injected into the locus ceruleus, which is right here. And then they cut the brain into slices and extracted the barcodes from each one of those slices. And so the idea is that if you see a particular barcode in this particular slice, then you know that the neuron here projected there. And so we could we could get all the barcodes from all the slices. And so what we found was in fact that not all neurons projected to all places. So here is a plot of the strength of the projection on this axis as a function of the position along the back front axis of the brain. So this particular neuron, which happened to be barcode 28 projected very strongly to this particular slight area of the brain and almost to nowhere else. So that was supporting the idea that you could have this very specific kind of control over the activation. And other neurons did other things. So this particular neuron barcode 79 projected more broadly. And a third neuron had a more complex pattern. So in fact, we saw a variety of different projection patterns. And out of the 1000 neurons that we looked at, each one had a somewhat unique pattern. But what what we got from that is the idea that in fact there is a degree of specificity that was not expected from the previous notions of how the locus ceruleus operated. Alright, so basically, that model is wrong. The solely specific model is wrong. And really what we think is going on is that there's a mix of different projection patterns, some of which are specific, and some of which are wiggly like this. Okay, so my main interest really is in the cortex, the part of the brain that allows us to think and reason. And so we're now scaling up to a much larger experiment, this is still underway, where instead of making only a single injection in the brain, we make hundreds of injections and tile the entire brain with barcodes, and then section the brain into much smaller pieces. So we get much higher resolution for where the different neurons send their information.  Each one of these balls, though, represents over 1000 individual neurons. So to drive that home, you can see here, this is some more significant fraction of the 50,000 or so neurons that were captured in this experiment. And for each one of those neurons, we have information about where so this is we just picked two here for illustration purposes. So this particular neuron sends its information there, this particular neuron sends its information there. And we have 49,998 more that we're thinking about and trying to understand right now. So these this is still early days, but this is orders of magnitude, more information about the connectivity of the brain than than really any other lab has ever had before. So in what can we use this for other than showing pictures of rotating brains? Well, one of the things that we're particularly interested in is understanding what goes wrong when in disorders like autism and schizophrenia that we know lead to disruptions of brain wiring. So we have mouse models of these disorders in which we know that they're behaviorally compromised. And we know that there's something wrong with the brain wiring, but we don't currently have a systematic way to go through the brains of these animals and figure out what exactly is wrong. We believe that if we can figure out what is going wrong in the brain of a mouse that expresses a gene that we know in a human causes autism or schizophrenia or depression, we think that that will provide at least the starting point for understanding what goes on in in in people. So that's that's one direction that my lab is going and then very briefly, I'm just gonna mention that. Well, so most of my lab until I start working on the connectome really has most of the work that I've done here through my career has been focused on understanding behavior, understanding the relationship between behavior and the circuitry that causes it. And so this is just I'm not really going to go through it, but it just it shows how we study that in in rats and mice. We train rats to to poke into a center port here. And then that causes a machine to our computer to deliver a stimulus. And then the rat has to make a decision about whether the stimulus had one property or another. In this case, it's being asked to determine whether the sound was lower, high frequency. And what we do is we try to figure out the neural circuits that enable the animal to make the decision about that. I'll just show you that because it's fun. I don't have the sound here, but go beep, beep. And the point is that it's like a little machine here. So early on I started this this talk talking about reflexes. This isn't a reflex, but it's a it's a bunch of decisions that we've we've trained the animal to perform in a systematic way that we can we can study and understand. And then what we do is we can look at the the activity of neurons using a variety of methods. This is an imaging method where those flashes of light correspond to to neural activity. So I just want to return to the question that I started with, which is so does this all mean that we're going to be able to upload our consciousness to the cloud anytime soon? Well, it saddens me to say that I don't think that anything that I've talked about is going to allow us to do that. I think that we'll understand a lot about how brains work in general. It might help us build build better machines or scarier machines depending on your perspective. But I don't think that we're going to be able to achieve immortality through through these methods or even by just looking at the circuits and to sort of explain why I thought I turned to the first car that I ever owned, which was a Fiat 128. It didn't look as nice as this one. But what I remember about it was that it was incredibly idiosyncratic. It made all sorts of noises. It often failed to start. But in ways that I could understand and sometimes predict, the gas tank only held three gallons, which was sort of like driving electric car, I guess. But it when it came off the assembly line, presumably it was fairly similar to the one next to it. And yet by the time I got it, it was really its own individual with its own history that caused its own dings and bings. And I can't imagine that no matter how much money I paid someone that they would be able to take my car and imagine that this was my car and replicate it and produce a copy of it that captured all the little dings and bings and quirks and idiosyncrasies. And so to the extent that I've been living in my brain now for a few decades, I feel like I'm sort of approaching the level of this Fiat. And it's highly unlikely that if you made another copy of me, you would actually be able to capture all my idiosyncrasies in a way that at least would be satisfying to me. So I'm pursuing more traditional approaches to immortality. I'm trying to leave a legacy by doing scientific work and by leaving children who might, well, we're in the audience early on, but got bored. And so with that, I just wanted to close and share with you this bit of wisdom that I got on a fortune cookie. If the brain were so simple, we could understand it. We would be so simple, we couldn't. And with that, I want to thank my collaboratome. In particular, my students, Ian Picon and Eustace Kepchol, who really drove this work, as well as many others, and the people who funded this work, my fundosome, including the Simons Foundation and Paul Allen Foundation and Cold Spring Harbor. Thank you for your attention.


My name is Shannon Kemp, and I am the Executive Editor of DataVercity. We would like to thank you for joining today's DataVercity webinar, Consistency in Distributed Systems, sponsored by Cloudant, an IBM company. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A section in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DataVercity. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and any additional information requested throughout the webinar. Joining us today is Mike Miller. Mike is one of the original co-founders of Cloudant, which was recently acquired by IBM. Congratulations, Mike. As Chief Scientist, Mike is responsible for developing and evangelizing Cloudant's technical vision, managing long-term product research and development, and directing special projects. Mike is a postdoctoral fellow. He co-founded Cloudant after cutting his teeth on petabyte per second problems at the Large Hadron Collider. Mike holds a B.S. in Physics and a B.A. in Philosophy from Michigan State, a Ph.D. in Physics from Yale, and is an affiliate professor of particle physics at the University of Washington. And with that, I will give the floor to Mike to start the presentation. Hello and welcome. I think we're going to go with a long introduction. That's great. I should give you another one. So it's a pleasure to be here. I'm going to talk about consistency and distributed systems. In particular, I'm going to focus on the portion that I think affects most of our lives these days, which is really boiling down to application space and that means databases. I hope to have saved enough time at the end for a decent amount of Q&A. I'll also note that I realized that today I had to cut a tenement amount of this to be able to package it into a time slot with a diverse audience without too fast. So there's a question of follow-up and future work that I'll talk about at the end, and I'll be working on it in more detail. So that's the end of the presentation. Before we move on to slide two, I'll just note in the beginning, you're going to hear me talking actually about one author in particular, Peter Thialis. I always left a last name, and I apologize if he hears that. But a lot of the fundamental research that's moving the field forward is actually coming out, a specific lab group at Berkeley. And we were lucky enough to grab Peter for a conference we have coming up next week in San Francisco, around on the 17th, and interested in learning more from one of the experts in the field. Feel free to reach out to me for a discount pass to Cloud and Con, including speaking in the morning of the 17th. So let's jump into it. Shannon gave you a pretty thorough introduction. But my name is in big systems. This is actually a picture of the last experiment I worked on in Geneva, Switzerland. There's a small human for scale at the very bottom, and a four-story device here. This is the greatest scientific achievement, I think. Now, as a general watch, I'm John Collider. A tremendous amount of engineering effort went into trying to understand the fundamental building blocks of nature and how they interact. In doing so, the field was forced to solve a lot of problems, practically because there were no solutions you could buy for various portions. So there's a tremendous amount of invention that happens and something like this. And that's where I found myself and my co-founders, and many people in the audience started to move into the realities of how do you deal with a problem, actually. It's actually over one X of a second or more for one of these devices. And clearly, that's the value that you couldn't dream of digitizing and writing to distributed and distributing globally to a large consumer base. So there are a lot of strategies in custom hardware and custom software to get there. But some of the things we learned very early on, actually, in kind of the first science lab in elementary school maybe, I think hold true all the way through that, and we'll come back to those at the end when we start talking about data modeling.  And that's kind of the general theme of a strategy that allows you to see what's going on. So one slide here, Modation, and then we'll jump into some more detail. I saw this presented very nicely by the founder of Joints, I believe, saying that kind of these two things, big data and mobile, have I think his words were broken, our model of computing. And at the very least, when it comes to applications, data and data, it's a greatly stressed model for consistency and transactional reasoning. And then, as a tech or developer or somebody's building a new product, these are combined to make a large opportunity space for your product or your ideas, but they also make it very challenging. To go into more detail, whose problem, you know, who really feels the pain, I think you feel the pain, the minute you're getting a benefit on a single computer or a single server. When you begin replicating your data for, say, redundancy purposes or to try to scale, let's say, split it back to one server and have it reflaid at the reload from other servers, you can begin spreading data between data centers or actually across more than one device. We're all very used now to having a single or experience, whether we take up our phone or a tablet or a laptop or, you know, a workstation, you name it, that's very challenging, especially when some of those devices are online or offline. When you have mixed read-write workloads and a high number of concurrent users, it's normal anytime you even take this application and go across more than one process. So, slide six, my personal statement is that this is pretty much now everyone's problem if you're building a new computer or something like that. Slide seven is that there's a lot of market response to this problem over the last half to a decade. And in particular, you're going to focus on new SQL, new SQL, and cloud. Probably a part of that. And I think that the great news is that there are new solutions hitting the market. Some of you on the phone are probably very familiar with that. We used steps and, you know, strategies to adopt. But I would say that this is still a fairly new field for the majority of folks. And I think it was a peel-back from a lot of people. And look at this from the view of the fundamental users of, you know, these types of technologies, distributed systems, and in particular databases. I think people are all very familiar with distributed systems from the first time you used a telephone if you had a landline or a mobile device if you had your hands on it. After all, we're all online right at some type of distributed system, not really for basis.  Like 80% of the data on the Internet now is user-created data. So that's what I'm usually talking about here when I'm talking about states, right? So maybe something like that. So that it's there for somebody else to need you. Or maybe you're at a later point in time. So maybe creation and updates and synchronization of all of that. One of your data is spread across multiple machines or processes. So I'm going to take a flight down here and give you a four-page clouded pitch to give you an idea of how to build your perspective. So bear with me real quick. And then I'll bring this back to what we're going to learn. So again, the country and space is new challenges. That means it's more of an opportunity. We've been very fortunate to grow into that. And so clouded is a distributed database as a service. And the key differentiator is that it shifts with its mobile strategy that there's kind of no mobile write master. So a big part of the marketing around this is trying to make it very easy for developers to involve and start using a service. So write with clouded. The hosted service will come in.  Your name is Janice. We could be janice.clouded.com. And that's the link for which you begin sending your JSON based on the straightforward. But wait, there's more. So what does the thing that you expect to adopt as a database to do? JSON documents, you can do it in B-trees like a regular database, a variety of secondary databases you can do search into space. And then in 2013, the big difference here is that, okay, I said it has a mobile strategy. So you can write local, whether that is an S-lite on a phone or a browser, or whether it's in the cloud. So I kind of have this single API that allows you as a developer to write all these different things at very distant scales. And then, at least, your data gets synchronized across the globe. So in Samsung, you have the billion-end user base. This allows your users to have their data synchronized wherever they are in the globe and deal with those problems of scale and geodes dispersion. These patterns, multi-tenor, are dedicated in the places where your app is located. No, here's a pretty different model than databases were originally built for. They were originally built to maybe be embedded in the application itself. I think the same thing happens. Eventually, it starts to be running as a separate application but on the same computer, right, as the application itself. And then you need different computers that are very nearby. We're talking about a highly, a small world now, a great scale, and semi-connected devices like phone come in and out. And then, the challenges you have are new. So kind of wrapping up that pitch, looking back to the developer perspective and picture my mentor here, who tends to look very surprised and very choked a lot of the time. Once we explain that type of a story to a developer, the first question we get is like, so how do you write code for that world? You can compare it to something that I know or something new that I know more about, like MongoDB, and then a long list of things, right? And part of that is like, how do I start to reason transactionally? So, you know, I'm trying to bring forth, bring the existing design and things that developers are comfortable with into this new world. And that's what we're here to talk about today and I think my overall message that I want everybody here to take away, and I know that the tenant marker, which is good, is that you do need to understand the basics of your data store. There's really little replacement for that if you want to get the most out of the system and drive the best way. I'm going to talk a lot about new SQL and no SQL databases. And then, they're very flexible. They're very new. It doesn't mean that they're not production-ready, but it does mean that a lot of the best practices and strategies and tooling and ecosystem around them, even the consultancies, is relatively fresh. And so, this is part of a series that events the end of the day. Diversity is running to try to help folks like yourselves understand how to really master them and get the most out of them. So, with that, I want to back up just a little bit and talk briefly about some classification of this history here. A lot of ideas you can trace back to some central minds. It shows two of them here that I've written some of my previous on. Like, Gene, Jeff, Dean, and Sanjay, again, want from... There's a nice link here to an article by Kegnet and Wired, which is a pleasure to contribute to. But I think that they, at least for me, in a large fraction of the field and the cohort of other companies, like, you know, Tengen, obviously, Shashara, et cetera, I think there's two large extent leaders that really inspired that field. So, maybe four pieces of literature or art leadership that really find that. Slide 17 shows you the ones that would choose. Google Photography talks about how you take the notion of a file system inspired across multiple devices. This shows you how to ease the way in which folks could interact and query and analyze that data in a batch system. Google, which inspired a lot of the database side of things, started to take those same primitives for distributed data and the standard gather of distributed systems and try to make that more accessible to actually store data in application state. And then I'll sneak one in here from Amazon, a Dynamo paper, which was published by Bernard Vogel, GEO, and others, which gave a really nice view into one of the systems that Amazon had built and used internally in the back of the shopping cart and other portions of the commerce business. And in particular, that one was one of the folks like myself because it gave you operational insight into not just the architecture of the system, but what you have to run it in production and what the perspective is in terms of, you know, how do they reason about consistency or availability in particular. Papers are really seminal, and we choose an infographic that I think was created by Clodin or for Clodin. The kind of thing is if you take those four papers and put them at the center, this is kind of some of the early portions of the new SQL, the NoSQL, and the kind of Fintupe ecosystem where at the top you have the system and MapReduce, and they have quite a large number of things that are really online batch analytics moving into real time, but very much old style systems. And really now I think we just refer to it as the Houdy ecosystem and everything that is being built on top of that as well. Incredibly disruptive to the analyze analytics market. And I think that to do this is a big part of our lives for a long time going forward. It's a big table and dynamo papers, you know, basically inspired a large fraction of the NoSQL databases and a large fraction of the algorithms that are incorporated into some of the new SQL databases like ODB or BoltDB or things like that. And I think we condense this down very quickly and efficiently, but I'm glad to take some more questions on this later on. I'll just talk about kind of two different types of databases here in particular. Those that are heavily dynamo inspired and these are based forandra, cloud instance, reoc, et cetera, gives you a highly available highly fault tolerant systems. I'm going to try to make references longer to be which adapts some of that philosophy, but not all, and it's kind of stuck in here as its own entity, but it's probably much more familiar to folks who are used to running MySQL. So, I'm going to jump into the biggest challenges to develop a reasoning. I wonder if you're going to see SQL people. Okay, this is great. I know that I'm sounding a little tinny. Let me know if there's anything I can do to speak up, Shannon. As you gain, it's also important to talk about some of the things that you give up in adopting your technologies and some of the challenges. So let's start with four high level things here where especially dynamo inspired systems when you're looking to replace single points of failure to give you reliable systems better feeling, which is one thing. And the fact that you no longer win something like a sample or a react or a cloud instance or some kind of ones, but you have to worry about how you manually partition your data sets to fit it onto the machine is very powerful. I pulled one quote here from the Google Center paper recently with the link that they talked about the experience they had trying to recharge their manually partitions model database which stores their F1 data, which was, I believe, the data that's really core to their advertising. And that's actually a fairly modest data set in order to buy it. And the next manual resharding that they performed or sorry, the most recent one before they decided to abandon that system and build something else to create some ideas for their coordination. And that's two years of incredible business risk. And one thing that I want everybody to remember is that the fact that we don't really talk very much about how users are responsible for partitioning their data on these distributed systems is a big step forward for the field because it's an incredibly much interesting thing. Folks who are used to building systems and dealing with high levels of concurrency, especially or high levels of workloads. The systems in asset compliance are consistent on disk by taking out lots and moving to a dynamo inspired system was incredible because those lots kind of go away and you end up with systems that are very tunable to be available at all times and even in failure modes or high levels of concurrency they will take your right. And that's an interesting strategy having worked on proprietary systems at large hand flyer where we are pumping some metadata into like Oracle and it's just going to keep up. We eventually realized that we would rather know that the system will eventually reach consistency and people will always take my right. You know don't want it to reject data and I want to make sure that if the right hits it is it's resilient and will be there for me to get it later today. And probably the most differentiating part of NoSQL in general is the fact that you don't have to start with a scheme of, right. It has optional and I think that if you think a system has done a good job of saying okay and you can throw everything into HDS and apply a scheme of unreed to bring structure after the fact where application developer again it's so important to allow you to get started easily if you can deal with very dynamic datasets. I know that when it comes to enforcing strong consistency or you know in some of these new datasets there's a high level of schema or tables and that does take away some power from the end point to efficiently do those 23 here just closes up this new list of tables, right. The fact that you know the web runs on JSON that's a study for new web and mobile applications of the enterprise sort of runs on as well similar things in rows and columns I think that at any time you've worked with that in large quantity that's impedance match for mobile or web engine 24 and Shannon do you mind just hopping in letting me know if the sound is okay I'll go a little just join it sounds like you're on a speaker I don't know if you have a handset or no I'm talking on my web before is it better if I talk quite about the sound check and now but it just kind of went a little wonky okay if I talk better so something must have changed since the sound check okay so we're on slide 24 now that was a high level review of just why we're interested in consistency why distributed systems are hard how we got to the new systems that we have the things that they've the power that they think is an offer architect or product start a little bit more and just kind of I think the two maybe sounding models that folks probably familiar with things that kind of classified things just familiar scaling systems in the real of scaling replays and then you have multiple secondary that's still a viable option whether I'm my sequel MongoDB or running your own solar you know in that system that you can split your workload in half by sending rates to the primary and then runs the things will eventually touch the data and in the case of MongoDB the the but now sounds like maybe a little too close to the mic a little bit too muddy sorry how that works it's weird how it changes it does let's see what the audience says so thank you for watching the challenge thank you everybody that's jumping in I'm going to classify master slay I'm going to talk about form based systems and I'll note that you're running a system that on a single server is surely a massive compliance like my sequel you introduce other servers for replica reasons then you're in a situation where you're in a distributed system and those are either to lock until that data is replicated from the primary to the secondary and most systems will give you in in latency and and or both are right which are the dynamo inspired systems and or react etc. where the idea is that there's no master and you're going to redundantly store data on different machines and it's right that gets hashed automatically to the and then that partition lives on three nodes the right is exceeded when two of those documents flush to two of the three nodes in the default configuration and then I get a redundantly on three machines and you succeed right by default it's two right even if the third right haven't been synchronously or slowly on the lead you have a voting mechanism where nodes can say here's the back to the situation where even if one of them is slow it knows that it's slow and can repair the system and that's with consistency in a distributed system even in the state of some challenges that will come back to as well I'll just note that you don't rigid anything for free in any of these systems that have its own disadvantages and make sure that you are using the optimal data model that's it for the purpose of time I'm going to focus more on the dynamological science that goes forward in the case that there's a tremendous amount of literature there I think there are a little bit newer and more interesting in their scalability you see right here suppose you have a class that comes in and is written copy is there a tremendous number of corner cases that you're discussing it away from when you're building a application or talking to users adopting a service like that trying to help them understand how to reason in this so Cloud and Cassandra and Dynamo then Dynamo then use fine-grained locking and some of them don't unless you have a lock update release lock and you have fairly locked systems that I can go into more detail on in the Q&A session and moving into the consistency side of things is a nice difference here from the real quick that developers these days are kind of left to those two choice items on the right are fast but consistent results and algorithms that deliver those consistent results say by locking and updating in place and releasing are all slow and worse under failure. A lot of the large real-world systems giving developers significant impact. And then the reason that you kind of have those two classes of choice is not it's not fundamental it goes down to the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the system, things don't have to be consistent on the disk for them to be consistent from the calling perspective. I'm interested in coming in, you know, if you're interested in speaking part about consistency models and eventual consistency in particular, I urge you to read this one kind of high-level summary paper here by similar authors from Berkeley. It's a great, great overview, and it goes into details of, you know, how do you actually reason and how is it that we have so much of the web that's been built on these systems we buy them today, we trade real money, we have shopping carts, you get all the material good, that and, you know, $10 that are being transacted based on systems like this. A lot of those systems don't have fundamental guarantee of safety, right? Inventual guarantee of safety. How is it that it's built? And what's the start? Another paper that really goes into something that I really like to do, which is, okay, there's a good number on it. When we talk about eventual consistency, what's eventual are we talking? Is it an hour? It's no assessment. The answer to that is going to, you know, define for me whether or not I'm comfortable with that. And it's also going to help me understand whether or not that's a good choice or something that I'm built. For instance, the ability to distribute a counter that's being updated a billion times a second may not be the most natural fit for a dynamo database, but something that's being updated at the rate of once per second is a great fit. How you follow the data kind of to balance will depend strongly on the system you're on and where it falls in that curve. So there's a lot of times here in slide 28. I want to make sure we save time for questions and actually show a few. But some of that paper, they do a very nice analytic derivation and then look at real-world data from Yammer, I believe, before they were bought by Microsoft. And then there's also data for read. Some of the bottom, they show data for write. On the left have the kind of single-reader, single-reader requirements. So that would be one, three, writes for read to have to succeed right before you send the data to the client in a dynamo system. That means you have available partition talent because you're not there in the TDB system like this. That's where you say, okay, if I'm starting three copies of my data then I only succeed to write when all three copies are flushed together. And then there's different curves here. Different colors represent whether you're on SSD, which I think is the green triangle and all the way to the right, would be at least one of the copies is the cross-liber network, say, on a different data center. On the left here are seconds. So 10 to the 0 would be one second. And then look at, as you say, I need to start data recently and consistency requirements to write or read, you know, marches from left to right. What may answer the question, how long are you going to take for the system to be fully consistent, right? So I need 50% consistency. You would read 0.5 mark on the y-axis, run that across until you hit one first and then look down on the x-axis, read off those seconds or seconds that it takes to do that. The general trends are what you would expect if you're running locally to SSD. That's much better than if you're writing across, you know, two different data centers connected by y-axis. And so this would change from literally a single millisecond to, I guess, hundreds of seconds. But if you're marching forward a slide, you know, you can also then apply that to real-world systems and start to just put some ballpark numbers on it. So from that original paper I quoted, you know, they say you can go off and measure this. And some simple DD, kind of the first no-SQL database was a service from very early in their portfolio, was consistent, always consistent by about 500 milliseconds in Amazon S3, which has a hard job right, but something like nine of redundancy for the project takes about 10 seconds. From this work that I just talked about, it's something like this. Re-appliance is generally consistent on this, depending on, you know, spending media, depending on the order of 10s or hundreds of milliseconds. And so that's the ballpark that we're talking about here. So when you're designing one of these systems and thinking about the data model, what I think is okay, and what I'd like to maximize is the benefit, right, from scalability because minus, you know, what is the cost of me getting any of these stale data? You know, the last version of this document at the state-of-the-art show times the rate of those stale, you know, return on things stale for time. And so that's the thing that you need to have in your mind, and a lot of the time, this is qualitative. I'll note that if you do have a code now, that code can be analyzed. I'm not sure this is a tool or something, academic research can be analyzed to tell you what the consistency requirements of that code are and help you match that two systems. So that's what I think. I've been talking about what systems are and are not eventually consistent. I think that's always important. My favorite example is something that is eventually consistent and actually may converge to see lost audio. Can you still hear Shannon? Yeah, I can hear you fine. That's terrible. I don't know if it's mobile through to the whole thing. It's perfect, but it's been... it's workable. Okay, thanks. It sounds like it's worse for you. So one example of eventual consistency is the pictures. And there was a parade event about 14 months ago where the social press, Twitter account was hacked, so a three-minute drop in the Dow Jones of 100 points, which must have been billions of dollars. What is the most inventive paper of all time or has been saved? But the interesting thing here is there is a very real business cost to that, and the time for that to converge was about three minutes. There are more examples that feel very familiar with, except in town, it's kind of the most classic original version of eventual consistency, where you write a check that could be turned into money before to either realize whether or not you have a cash. And that, you know, if you look at ATMs, they may not always be fully connected. I don't know. They never worked for a bank, but I think you can talk about this from folks in the industry for some of the reasons that you have a limit to your ATM daily so that you don't gain the system of other ways. And then both of these things you need to think about that figure of merit, right, what's the penalty and what's the strategy and what's the cost of being wrong. And the number one strategy from a developer's perspective here to lay down a few slides of actual just on them is to adopt the idea of commutability. The idea of maybe not updating a place, but you're treating your application as a state machine, and going into more detail. But thinking about that bank connection, you may not always have a single, you know, float that stores the value for your account, but you do exactly what you do with your own checkbook, which is you write the deltas, right? You write the changes I'm taking next dollars out for this check. I'm taking a Y dollar for that check. And then the example of how you can model the M&Js on documents, or you can say, you know, $137 U.S. as a state account, 1-2-3-4, and depositing an entire 6-7-8. Going into a little bit more detail, that's the general gist of it. And if you're looking for maybe the most recent post-person for this deal, and that can really bring you up to date, there's a great talk by Richickey on the values from one or two years ago, and I think he gave him some conferences. He is through this closure, the language, and the author of the comment, and the mutable database runs on top of other data storage itself. And he really talks about, okay, some of the reasons that got into the situations are historical. The fact that you didn't have large amounts of data, lots of storage, et cetera, and he gives you a nice kind of walk-through to rethink this from the beginning, how would you do it in a while? Although it's not as simple as I'm necessarily talking about here, but it's very powerful. And so, this is one of the key things here. Thank you for this interview. You know, there's a great post, there's a hyperlink in the slides that we'll send around from 2007. It talks about accountants, don't use it. So it's a great concept that's been at the core of functional thinker programming languages for a long time. For example, and once you assign the values to a variable, you can never update that. Right? And so this is the first thing the language can do to keep you from having, you know, race conditions and loss. And in general, that's a very important thing as you start thinking about writing programs that fill, literally, with the number of cores on systems. This concept is deep that the core of five systems, especially modern systems like DFS, you'll hear the phrase, and it's also bundled into the storage engines and databases themselves. So at the core of, you know, the storage, many different database storage engines and databases like Zatomic and HTV and Cloudants, take those concepts and make sure that you're never updating data in place. You're putting this at different levels, sometimes at the language level, but you can also then do this at the data model level itself as an architect or developer. And that's the part that I want to kind of close with here, and then we can go into it now. So I'm going to give you three simple strategies and then kind of talk briefly about future work. The biggest one here is that you don't want to update in place. You want to write only. And so, you know, an example would be if I need to change the value of, you know, some space within them, I can either, you know, do a read and just write the new value, or I can even just write the change to that value. Different systems differently. But then versions, and maybe put into the newest version, you can make sure that time is always going forward. You will converge to the space and that you are building something that is highly scalable from some of those concurrent writer-reader-access patterns that I think are about when pointing to the demo-inspired problem. So an example to make this very explicit, I think, you know, even the deletes are done by writing only. And so a delete where you write a special two-stone type of record in a row or a new document are some of the mental parts of, you know, many existing SQL RMS systems, as well as the new SQL system. That's two standard things. But then down to more brass tacks, and the same thing about building a system, say, within the cloud and through the app or Cassandra now, breaking out many to many or one to many relationships, using foreign keys and links, right? Notifying the data in a standard way is the best way to build a system that can scale and minimize concurrent, you know, minimize contention when people are trying to read or write. This is kind of in contrast in broad search through the MongoDB strategy where you tend to bundle things up into rather fat documents and trade those on the wire very quickly. It's something like, you know, Cloud Ant or Dynamo in general. It also works to independently indexing options you have to take something like a relationship between a user, a friend, which is a lot of people that are trying to deal with a lot of thousands of friends, that's actually at large and tough to connect as well as to trade on the wire and multiple people trying to update that in place are going to stress the system and oftentimes that can bring it to its knees. So the same thing is to move to maybe a more normalized start schema where you start to put arbitration, right, at the data model and level types of data, right? So what I'm going to say, some object relational map will do this for you on top of no SQL and SQL systems. Sometimes you can just do it yourself. But here, you know, the transition from having the one-to-many relationship in a single document versus breaking into multiple documents is going left to right in the screen. And so I would break up, you know, my Miller user document to just have information about myself and a primary T, which is the underscore T. Every time I add a new friend, right, I can just write a new document to the same system. I've done that as a link or make an edge in the graph here, right? Each one has vertices that says, okay, user and Miller, which is a specific document ID that says that this target, you know, user A-Hoff, is a friend of this. I have a thousand friends or a thousand updates to my friend list, right, a thousand of these small documents, right? So they're very small. And we're going to talk about the wording which they arrive in the next slide as we kind of wrap up here. But the important thing is that many of these systems, and this is where it really breaks down a little bit into the details of an individual system, the options you have for secondary indexing are critical, right? So if you have an individualized U, that would say you need to say who are the friends of Mike Miller or that the entire user state. I can do that with a single query to the system. And the standard makes that easy with the notion of columns, columns, columns, families, et cetera. So there are ways where you can efficiently set all the data in a single query without having to walk the relationships explicitly, right, in multiple search rounds. But the big thing here is I would argue that that's often not the case at all and it's the exact opposite. When you're looking for a scale, you want to bring it up in the smallest pieces possible in these secondary indexes. I'm not going to star around that to make this the problem easier. And just to point that out, I'm going to talk about the regional banking example. Thinking commutatively is very important. And so in the checkbook, you're just going to delta, not new versions of the state. So, for example, a friend is nice, but in the ending relationship from the last slide, we didn't actually have to do a cumulative operation to say, like, how many friends do I have total? Right? That type of thing will be very important for your checking account if you want to know the total value there. So, really, I could store my checking account on the left as a single document with a list of transactions and a single floating float for the number of dollars in my account. Or I have a pretty empty account document on the right that labels the account number is that type. And then through the transaction, I can identify the amounts, the source accounts, and the target accounts. I'm going to come back to the order question. Absolutely. The key point here is that you're able to then get the value of your accounts via materialized view. That's usually things to note are what happens to the order of operations, and that's what we're talking about continuously. And what happens, what is the actual workflow, was here to fully accept the transaction. I would say, that that may change underneath me, just like with an ATM. And in that process, I'm going to limit the user for making a key larger transaction and write that back. I can come back to in the details of the Q&A, but to break it out, you understand the penalty being wrong. You make an estimate that it will take for the system to be fully consistent. And the type of operation that's needed is whether or not you're going to let somebody make a transaction that will take the account for both the year and the year, what the penalty is. That's very analogous to what happens in the real world. This is actually a whole level of literature. And thinking community-wise, there are a new style of work around something called quantitative data types, taking things like addition or share counters and looking at how you build those on top of modern distributed systems and making those simpler and racking those up in client libraries for developers so that they don't have to do that type of underlying logic themselves. Not going into any details of those and just note that they're very popular right now in the general Cassandra for common secret. So I'm going to turn forward to things that I'd love to talk about in the future. Sometimes I guess when I think that the audio is working better. There will be some more details about like, okay, let's talk about facts about the timing of document rights and reads in that 19th example. That takes you into some of the reasoning. I will glance over the facts that secondary index are very powerful in this immutable data modeling paradigm. I understand the interplay between the primary index and the secondary indexes and that's a very different system to system. There's new transactional systems as well which kind of examine and review everything that exists in previous generations of databases or what relapses can we or what sometimes can we relax and then a really nice post-recording that'll get you reading there if you want to. I will just note that when I go to the Berkeley AMP plan, which is algorithms, machines, and people, that's really the best writing on this. What they don't write about there becomes tomorrow's enterprise architecture and so consistency here's the link and how you can read bottom to top and you will be a world expert. I'll close and say thanks and hopefully we can do some Q&A. Thank you for the sound issues. You know, technology is so great when it works. We do have some great questions that have come in and this has been a great presentation despite the sound quality issues that we had being at the top here and it was one of the most popular questions that we get as people want to know if they'll have access to the link to the slides and the recording of the session. We will be sending that out by end of day Monday so I will get it out to everybody including the additional information that Mike has passed on somebody was asking about the papers that you had mentioned so I will add that and we can get that out to everyone. The first question is Mike, on slide 29, what is the underlying technology streaming plus in memory? What are typical structures of metamodel? I'm not very fond of relational but I've seen many relational. Would you shed light on how to leverage semantics into metamodel? I am not quite sure exactly what we mean by metamodel but I just want to make sure on the mental consistency here are you the numbers quoted from Amazonas 3 versus simpleC versus Cassandra? I can have a little moment to respond to that and you can send me another question there. If that's the case I'll just jump into that real quick and just say that each of these systems has a different approach but most of them make use of a different hierarchy where you have some type of stream coming in different places say clouds different the fact that it doesn't have a right head log everything is committed to this so it's always consistent something like Cassandra will have a right head log and you can replay from that but all of these systems make use of a tiered hierarchy where you have things that are in the cache that if you have an append only storage engine and so level db is at the core of many of these systems that is very cache friendly. One of the great things about the unique ability that Vichy talks about is how cache friendly they are. If you're always writing something new then that tends to be in the cache if you have a right and multiple reasons that come after it. I'm not sure how to answer the question about metamodels in general but I'll note that these approaches are there whether you're talking about streaming in memory or on disk. You understood the question appropriately in your initial question to what it was about so that was good that's perfect. And Mike would you summarize the perspectives or checklist for consistency considerations? I would generally begin by asking users tell me about the relationships in your data. Do you know if you have one to many and many to many relationships? That's number one. Most data is highly one form or another and so then I say okay are there you know one to many example where you have a user with friends? How much does that user have? Is it a hundred? How does that impact on whether or not I think about bringing that document up into multiple pieces or we're not going to think about keeping it in a single piece but perhaps most importantly in a dynamo in a product system like Cloud Inc. or Cassandra or React asks the question of how often do you want to change the state of one of those documents? And then I compare that to the curves on slide I forget where it was right after this from what is the coherence time of a system like that and it depends very strongly on the deployment of this multi-data center to make sure that you're not in one of those regions where you're saying that 90% or above regions for consistency. If not, you'll be in a world of pain where you're reading still data introducing conflicts into the system and then the system will drag what needs trying to repair those conflicts with the various of the entropy underneath. So those are the two big ones probably or three big ones. Tell me about the relationships to one to many, many, many. Tell me about the size of those and how often those are going to be changed. Correct. And next is how do you really abstract data modeling for these NOSQL databases? All I've seen is kind of a hard coding of actual values and abstractions as used in the relational world. That's a big question. I guess I'll note that from this from the developer's perspective, I was very my bias is very much towards objects relational mapping or I think objects or data structures within a language or work and then I'm looking for the most efficient way to write, read and query those myself or to let the system do it for me. One of the things is that a lot of the web frameworks Ruby on Rails, Python's Django you know what you're working with Node.js or something like that. A lot of these frameworks will just give you a default mapping of your objects in memory onto documents or rows and columns on disks whether that's SQL or NOSQL. NOSQL is if I want to define things for instance to reach for a Python library and then create classes and define the relationships between those classes and ORMs will turn those into document types and impose form key management for me under the hood. The databases themselves NOSQL databases especially are just getting to the point where the thing to do is to provide tooling for the form keys. That's one of the things that you always get for Freeride within R2DMS systems. This is all I mentioned it's entity and I think that there's really no replacement here for trying to find experts in the fields to help you walk through the whole data modeling stages there. The problem that you're thinking about has been solved in a pretty language centric way on Stack Overflow or something like that. But as per specific tools that allow you to lay down some theory and turn that into a schema or document model those are very young. The next question actually is more of a request. Can you show the strategy number one slide one more time? I want to pull that up. I will ask the next question here. The next question is what are the strategic differences between write only and logs? What are the best use cases for write only rather than logs? I'm going to interpret logs as actual logs data say web server logs or something like that. There does seem to be a convergence between what's happening in a lot of the database technology and file systems and actually what happens on the media itself versus what's happening in the log world. But there are some key differences. In any of the systems that I talked about there is the ability to go back and change the state of something that you've written. In a log file system and as you know as you're storing time series data where you're taking measurements for sensors and writing a disk for your data center or something like that those values will never be changed ever. Whereas when we're talking about application states the state will transition between different states that go in in a database and invalidate the tree in the past. So you have the ability to write a tombstone and delete that. In general carries significantly more overhead to give you the flexibility of retrieving something in order, log and time. They're fully indexed. Primary and secondary indexes allow you to comprehend the queries and are not really based on scans. A large fraction of the data especially as you think about Internet of Things tends to be right once time series data where that will never be represented by something else. And for that a lot of people are reaching for databases when that is not necessarily the right choice. So what you'll see is being able to keep the same API from the developer perspective with swap out storage engine to something that's really meant for pure time series data in that log based approach. There's one more question here for you. Would you share design patterns of indexing? We may not have time for it. Sounds like both columnar and more relational are choices in the same system. The second part got a little bit of an awkward answer but yes. The primary and secondary indexing options are different across different databases even particularly in the Dynamo family. Cloud ints is different than say Cassandra. Differences themselves on the flexibility to always build a new type of index points in the future. In columnar databases we're talking like big columnar not necessarily like Vertica columnar disk or in memory that allows it to be very fast to retrieve at a later point in time and to do index in new waves you may have to actually update the schema in order to do that in something like a big table family. Those are the big differences right there I think between kind of the ability to always build a secondary index at any point in time in the future. That's what document databases let you do versus columnar style data databases. But then in the NoSQL family with Cloud int we have the ability to build scene-based indexes and things like true columnar dial-up probably in the road map for this entire family of databases. But the key point for you as a developer data modeler is to understand what is this system exposed to me and how can I use that to best like how would I best leverage that. So the explicit example is like as you use to do aggregations of these types of CRDTs are very important in that immutable model that I was talking about before. I don't have a sharp answer to that but there's no replacement for just like maybe yourself a big cheat sheet. Look at the secondary indexing options like projection, compound, pre-commit, post-commit, those are really critical things for you to think about as you're wrapping one of these solutions off the shelf and trying to cause it into a problem. This has been a great webinar of course even with the sound issues you're always a great speaker and always appreciate the education you can provide our subscribers. So thank you everyone for your patience and working through it and thanks for your attending as always. Thanks for the great part, participating great questions throughout the webinar. And I will be sending out slides and links to the slides and links through recording by end of day Monday and they will be posted to dataversed.net and additional information requested throughout the conversation throughout the presentation. And Mike you just had a request for would you please write a book on this topic? So that's great. We're happy to help. So thanks everyone. I hope you have a great day and again Mike thank you so much for this great presentation. Thank you all. Thank you for recording out to everyone. Thanks everyone. Thank you.


What's up, everyone? It's your girl, Kenty here from Layton Sports Guards, and I'm ripping 2022 Panini Obsidian football hobby six bucks half case break number 17 pick your team We've got Adam F chiefs Adam C Browns Allen L Jags and Vikings Ali Fonzo M Niners Anthony C bangles Anthony P Cardinals and Barakos Armando B Chargers Barry T Steelers Christie bills DeWard B Seahawks Edward P Cowboys Rams Eric J Washington Gregory M with the Bears Packers and Giants and Titans Jeff G Lyons John F Falcons Kent I Jets Lewis C with the Raiders Patriots Saints Ravens Dolphins and Bucks Luca B Panthers Morgan L Texan Steve R Colts and Vinny D Eagles. All right What's up, Wahoos Here we go. My first look at Obsidian. Let's see a sweet color blast. Come on Garrett Wilson Rookie Who's got the Jets? Oh, we've got E.J. Brown Eagles. Oh my goodness already second card of the break. How about it? Aaron Rodgers color blast Packers Green Bay Gregory M they go Greg Wow first box There you go. Aaron Rodgers color blast. Congrats on that one, Greg. We'll get that one magged up. My goodness We've got orange Deontay Johnson the 75 Steelers and purple two out of 100 dolphins To 75 we've got eclipse patch of Jason Taylor for the dolphins player worn use material on this one Got out of 50 cardinals lightning strike green auto of Robbie Anderson Robbie Anderson on the lightning To 199 we got rookie auto Desmond Ritter Falcons.  Greg killed this box Dobbs RPA to 50 and a Rodgers color blast Wow Vilas Jones junior rookie Bears and Cooper cup orange for the Rams 17 to 75 Unbreakable to 75 rookie patch Davis Price Niners To 25 Tyreek Hill cutting edge patch nice three color patch there dolphins Six of 25 auto Steelers rookie of Jaylen Warren It's on there Pittsburgh. It's good. Had a great rookie season last year Great backup to Maji and to 25 RPA Christian Watson. Greg with the Packers continuing To reel in some nice cards You go Two RPAs and a color blast out of two boxes for you, Greg Go pack go Cheeseheads We got Jaylen Thompson rookie for the Cardinals Out of 125 trifecta materials David Bell rookie Browns We've got Amon Ross St. Brown atomic materials lions back to the Lions 89 of 99 orange rookie auto Malcolm Rodriguez Let's grab number 44 Rodriguez And we've got Titans to 99 RPA Malik Willis You go Tennessee Craig M. Wow With the Willis to 99 38 of 99 on that one Nice Willis Got delvin cook for the Vikings to 50 Hey, and what's up, Greg? Volcanics of Dak Prescott 11 of 15 Nice one there cowboys Volcanics All right box four And y'all only spots remaining for the daytime breaks gonna be prism football Those are four box pick your team breaks all remaining teams are on sale Do you have a redemption on the bottom? Pull my checklist here give me one second All right, David a jobbo rookie for the Ravens We've got red Aaron Jones Packers man. Wow that one's five out of 10 And Tariq woolen on the uh gold to 25 Seahawks Out of 100 we've got cutting edge Lamar Jackson patch Go Ravens any gamer event 275 Eclipse of uh brine dockins Eagles oh this next one's sick To 75 Steelers how about a Heinz Ward galaxy ink? One of my favorite all-time players nice Heinz Ward And redemption Let's see what we got here Good luck y'all sitting in rookie jersey ink card 15 of Wondale Robinson it's gonna be giants Giants on the Wondale My name is Wondale box five Got austin eckler base chargers Chris Olave on the unbreakable patch Saints That was 16 of 75 Cowboys to 199 rookie auto of tyler smith Magnetic to 75 nick chub auto there you go brown Nice nick chub there Matrix materials to 25 lions patch auto de deandre swift Lions doing well a couple hits orange debo for the Niners 70 of 75 And tunnel vision ray lewis 43 of 50 Ravens ray lewis All right last box here what a nice half case here we go Uh julius chestnut rookie chestnut rookie Titans They've got tristan ebbner for the bears ebbner for the bears that is three out of 75 We got short bridge uh the etch contra rookie of damian pierce you go texans Nice short print those whites are nasty We've got to 125 cmc on the trifecta material Niners Eight out of 125 Titans to 199 rookie auto of okongwoo To 10 wow jim kelly on the aura auto gold Bill's a mafia there sick when they're buffalo chris d the bills And last but certainly not least a 175 rpa Number two here for the packers and greg romio dobs What a half case break for the packers my goodness That was insane All right, this half case there do a quick recap of all the hits Romeo dobs packers cmc niners chrysalovay saints brine dockins eagles Lamar jackson ravens jason taylor dolphins a mon rossine brown lions David bell browns tyrie keld dolphins We had davis price niners tyler smith cowboys Nick chubb browns jim kelly gold to 10 bills malcom rodriguez lions desmond ritter falcons Bokongwoo titans jalen warren steelers Heinz ward on the galaxy ink stealers lightning strike rob robbie anderson carnells Giants wandale robinson redemption Packers romeo dobs deandre swift lions christian watson packers We also had the malik willis rpa that one was 38 of 99 Titans and then colorblast it's going to be an erin rogers for the packers Alrighty that will do it for number 17. We got 18 coming up shortly