دانلود کتاب CockroachDB -راهنمای قطعی داده‌های توزیع‌شده در مقیاس بزرگ

Welcome to CockroachDB: The Definitive Guide, and thank you for being here! With this book, we want to help you learn to build and deploy applications with CockroachDB, the distributed SQL database that meets you where you’re at on your journey—in the cloud, on-premises, or hybrid. First, the question everyone asks: Why the name CockroachDB? One immutable fact of engineering is that things break. At large enough scale, things are breaking all the time. The kinds of failures that might happen once a year on a single machine become daily occurrences when you’re running thousands of them. A system that aspires to handle large scale must treat fault tolerance as a core responsibility. This was one of the key insights of Google’s MapReduce framework. By requiring all computation to fit within a relatively restrictive framework, it became straightforward for the system to automatically rerun the necessary pieces of work after a failure. We believe that this is how it should be: highly available replication should be the default state of a database from Day One, not the result of painstaking configuration work. And looking ahead to Day Two (or Day Two Hundred), the database must be able to grow along with the application so that runaway success is a cause for celebration, not panic. When Cockroach Labs set out to build a relational database from scratch, we wanted to bring consistency, native resilience, data locality, and massive scale to modern applications. Our vision was of a system able to colonize any resource that you gave it and then relentlessly optimize itself. A database that would use available space and reach equilibrium across a coordinated set of distributed nodes so that it would not only incorporate new resources, but—if a machine or data center or even an entire region went down—the database would simply equalize the remaining available resources. CockroachDB’s origin is a tale of necessity. Quite literally, Spencer Kimball, Peter Mattis, and I, Ben Darnell, set out to build the relational database that we ourselves needed. After working together at Google, the three of us went in different directions for a while. Eventually we ended up back together (along with Spencer’s brother Andy, a Microsoft SQL Server veteran) at a startup called Viewfinder, building an application for photo organization and social sharing. We, of course, hoped it would be successful, so we wanted to build for scale. After all, as Spencer says, “Sometimes shit happens. And, at scale, shit’s always happening.” It turns out that, given the history of that project, we didn’t do well enough to ever need massive scalability, but we wanted to plan for it from the beginning. We also didn’t want to lock ourselves into a monolithic database, sharding MySQL or anything like that. We had been down that road before and knew it didn’t lead where we wanted to go. This left us looking at NoSQL options as the best alternative and eventually we settled on DynamoDB. DynamoDB ticked a lot of boxes: it’s scalable, it’s fast, it’s predictable. It’s very similar to Bigtable, which I had used as the backend for Google Reader while I was at Google. And so, on paper at least, we really liked that model. But as we got experience with it, we realized we had a couple of fundamental problems with NoSQL. The biggest one was we found that we really needed secondary indexes. The Bigtable/ DynamoDB model is really primary keys only; there’s no concept of secondary indexes. To get them, we had to build our own partial implementation of transactions on top of DynamoDB, which was workable. Once we were using this system, however, we found a subsequent problem. DynamoDB on its own is very fast, predictable, and scalable—but once you start doing things that combine multiple records, as we were doing with our secondary indexes, then things got difficult. Ultimately, we came up with a system that worked, but the layering of transactions and indexes on top of DynamoDB was inefficient, both in terms of performance and our engineering efforts. During this time we did start talking about the idea of building a database ourselves, but Viewfinder was a startup with a small team. We decided, You know, DynamoDB is not ideal, but it exists and we can use it today, so that’s what we’ll do. But then a year or two later Square bought Viewfinder, and we found out they were struggling with sharded MySQL. We realized then, Okay, it’s not just us, this is a real database need that’s not getting met. At Square we were now in a good position to try building a system that was both inherently scalable and supported secondary indexes. So that’s where the effort really started in earnest. Spencer started on it as a side project on nights and weekends at first. And then he got some more contributors, and eventually it even became an official project at Square. But we knew that the real destiny of this project was to serve the entire database market, so that’s when we decided to leave Square and start a company to do just that: Cockroach Labs was founded in 2015.