Database Reliability Engineering Book Review
Hello colleagues!
We have just arrived from the printing house the long-awaited fundamental work of Martin Kleppman, referred to in the original as “ Designing Data-Intensive Applications ” (we announced it in September 2016). The book is available for ordering on the site (do not thank, we ourselves rejoice)
')
And at the end of November last year, the long-awaited book “Database Reliability Engineering” was published by O'Reilly, which, in our opinion, would perfectly complement Kleppman's work. By the way, so far on Amazon - only rave reviews
Under the cut, we offer you not only an optimistic review of a book with a horse, but also a realistic commentary on this review, which we hope will also interest you
When looking at the cover of Database Reliability Engineering, the question arises: “Just a second — how does this engineering differ from database administration?”
I will please you: it is to this question that Lane Campbell and Charity Major are the first to answer directly in the preface.
Open page 189, section "Data Replication" in Chapter 10. The authors explain the differences between:
Single master replication is discussed on p. 190-202; here the authors phenomenally manage to explain all the advantages and disadvantages of such a system as the “Accessibility Group”. Yes, on 12 pages it is impossible to spell out in detail how to design, implement or debug an accessibility group. However, having mastered these 12 pages, you will learn much better when you should recommend such a solution, and which pitfalls to fear.
That is the engineer’s task of ensuring the reliability of databases. Such an engineer not only knows how to work with one database, but also knows when to use specific capabilities, when it is not worth it and (by and large) how to automate the system and eliminate weak points in it.
I like these 12 pages because they demonstrate how widespread this 250-page book is in terms of coverage. The authors have in-depth knowledge not only about the specifics of the database, but also about the interactions between the database and applications, and how business logic is implemented in the database. Authors are able to abstract themselves from their own experience just so that the book would be interesting to everyone who works professionally with data; nevertheless, they manage to write clearly enough so that the material presented in the book can be directly applied when working with other modern technologies.
For example, it does not explain how to use versioning while providing infrastructure at the code level. The book simply states that versioning is necessary to master, and introduces you to key terms with which you can begin to master this skill.
You will have to learn new terms and concepts. It may take years before they are put into practice in the organization where you are currently working. This is normal - because the book is needed to expand the horizons.
Managers, this book will also be interesting for you. After all, you will understand: "Oh, I need a team of database administrators who can do this and that"
I recommend that you carefully study Chapter 2 (service level management) and begin to work in this mode with the staff that you now have. Start setting goals at this level, discuss how to measure the pace of their achievement. In my opinion, this is the hardest part of the book; she assumes that business owners will be willing to compromise on these issues. These are problems of a social, not a technological, plan, and it’s up to the manager to solve them ...
From this chapter I would like to quote two simply delightful lines (italics mine):
If you are just starting to deal with database administration, then some terms may seem familiar to you (“release management”, “monitoring”, “human factor”).
Chapters 10-12 seem just amazing.
In these chapters you will learn a lot of large-scale concepts (ACID, CAP-theorem, caching, messaging systems). You just blink your eyes in amazement, and your ego may shrink when reading such a text. Do not despair: already reading these chapters, you will learn a lot of everything that most database administrators are not even aware of.
Yes, of course, I recommend this book.
After all, this is a book that is easy to read, but difficult to implement. Seriously, the implementation of services at the service level alone (the topic of chapter 2) in most typical companies requires months to coordinate and track all aspects.
Over time, the place of the current commercial and open-source tools will come to others, but the concepts themselves, set out in the book, will remain unshakable for at least ten years. This book is a wonderful mission for all those who are used to look 5-10 years ahead, but do not mind looking further.
If you like these books, I also recommend Google’s Site Reliability Engineering. Not a book, but just a miracle.
COMMENT DANA CAROLLO
Yes, the book definitely lays a solid foundation on topics such as design, development, releases, production management life cycle. This is a must-read for database administrators who want to grow above themselves, and not just manage the infrastructure.
Some database administrators may turn into “grumpy watchmen”, closing the production chain. On the contrary, this book emphasizes how important it is for a professional data engineer to connect to the process at the very early stages - in the design and development of systems.
Of the shortcomings of the book, however, I would like to complain about the refined style. Ugh!
In addition, there is a clear bias towards open-source platforms (Linux, MySQL) in the book, which may scare readers who masterfully manage with Microsoft platforms. (Glory to SQL Server!). Comrades, SQL Server Specialists, you just need to adapt the concepts outlined here to your native platform.
The specifics of the book is clearly sharpened for work with distributed applications on the Internet - that is, it is not limited to data analysis, the scope of big data and data warehouses. The authors unambiguously report this on page 86: "We presume that data warehouses should be distributed."
So - if you close your eyes to some minor flaws, this book is an excellent resource for database administrators and their teammates.
We have just arrived from the printing house the long-awaited fundamental work of Martin Kleppman, referred to in the original as “ Designing Data-Intensive Applications ” (we announced it in September 2016). The book is available for ordering on the site (do not thank, we ourselves rejoice)
')
And at the end of November last year, the long-awaited book “Database Reliability Engineering” was published by O'Reilly, which, in our opinion, would perfectly complement Kleppman's work. By the way, so far on Amazon - only rave reviews
Under the cut, we offer you not only an optimistic review of a book with a horse, but also a realistic commentary on this review, which we hope will also interest you
When looking at the cover of Database Reliability Engineering, the question arises: “Just a second — how does this engineering differ from database administration?”
I will please you: it is to this question that Lane Campbell and Charity Major are the first to answer directly in the preface.
“... for a very long time, the DBA’s craft was to make cells and snowflakes. Everyone had different tools, different hardware, programming languages ​​are also different (...) the days of real efficiency and stability of such a model are already numbered. This book talks about ensuring the reliability of systems from the point of view of a database engineer. ”This book simply delivers: this is, in fact, a 250-page variation on Google’s Site Reliability Engineering concept book (I like it), addressed to professionals who may be used to thinking of themselves as database administrators, but dream of working in dynamic, ambitious companies.
How a senior database engineer should read this book
Open page 189, section "Data Replication" in Chapter 10. The authors explain the differences between:
- Single-host replication — as in Always On accessibility groups in Microsoft SQL Server, where only one server can accept write operations to a specific database.
- Replication without a master node - as in SQL Server peer-to-peer replication, where any node can accept write operations
- Replication with multiple host nodes — these are complex replication topologies, where only 2-3 nodes can accept write operations, but all others can accept read operations.
Single master replication is discussed on p. 190-202; here the authors phenomenally manage to explain all the advantages and disadvantages of such a system as the “Accessibility Group”. Yes, on 12 pages it is impossible to spell out in detail how to design, implement or debug an accessibility group. However, having mastered these 12 pages, you will learn much better when you should recommend such a solution, and which pitfalls to fear.
That is the engineer’s task of ensuring the reliability of databases. Such an engineer not only knows how to work with one database, but also knows when to use specific capabilities, when it is not worth it and (by and large) how to automate the system and eliminate weak points in it.
I like these 12 pages because they demonstrate how widespread this 250-page book is in terms of coverage. The authors have in-depth knowledge not only about the specifics of the database, but also about the interactions between the database and applications, and how business logic is implemented in the database. Authors are able to abstract themselves from their own experience just so that the book would be interesting to everyone who works professionally with data; nevertheless, they manage to write clearly enough so that the material presented in the book can be directly applied when working with other modern technologies.
For example, it does not explain how to use versioning while providing infrastructure at the code level. The book simply states that versioning is necessary to master, and introduces you to key terms with which you can begin to master this skill.
You will have to learn new terms and concepts. It may take years before they are put into practice in the organization where you are currently working. This is normal - because the book is needed to expand the horizons.
How should the manager read this book?
Managers, this book will also be interesting for you. After all, you will understand: "Oh, I need a team of database administrators who can do this and that"
I recommend that you carefully study Chapter 2 (service level management) and begin to work in this mode with the staff that you now have. Start setting goals at this level, discuss how to measure the pace of their achievement. In my opinion, this is the hardest part of the book; she assumes that business owners will be willing to compromise on these issues. These are problems of a social, not a technological, plan, and it’s up to the manager to solve them ...
From this chapter I would like to quote two simply delightful lines (italics mine):
“ SLO (Service Level Objectives) govern the rules of the game to which we obey . These goals are needed to decide what risks we are ready to take, what architectural decisions to take, how to design the processes that will ensure the functioning of such architectures. ”The “availability” and “lag time” phenomena for a database engineer are as important as “revenue” and “profit” for a sales person. Who would think to tell marketers: "Oh, just knock out the best price you can, and everything will be fine." With the engineers to ensure the reliability of this number also will not work.
How should the developer and sysadmin read this book
If you are just starting to deal with database administration, then some terms may seem familiar to you (“release management”, “monitoring”, “human factor”).
Chapters 10-12 seem just amazing.
In these chapters you will learn a lot of large-scale concepts (ACID, CAP-theorem, caching, messaging systems). You just blink your eyes in amazement, and your ego may shrink when reading such a text. Do not despair: already reading these chapters, you will learn a lot of everything that most database administrators are not even aware of.
Yes, of course, I recommend this book.
After all, this is a book that is easy to read, but difficult to implement. Seriously, the implementation of services at the service level alone (the topic of chapter 2) in most typical companies requires months to coordinate and track all aspects.
Over time, the place of the current commercial and open-source tools will come to others, but the concepts themselves, set out in the book, will remain unshakable for at least ten years. This book is a wonderful mission for all those who are used to look 5-10 years ahead, but do not mind looking further.
If you like these books, I also recommend Google’s Site Reliability Engineering. Not a book, but just a miracle.
COMMENT DANA CAROLLO
Yes, the book definitely lays a solid foundation on topics such as design, development, releases, production management life cycle. This is a must-read for database administrators who want to grow above themselves, and not just manage the infrastructure.
Some database administrators may turn into “grumpy watchmen”, closing the production chain. On the contrary, this book emphasizes how important it is for a professional data engineer to connect to the process at the very early stages - in the design and development of systems.
Of the shortcomings of the book, however, I would like to complain about the refined style. Ugh!
In addition, there is a clear bias towards open-source platforms (Linux, MySQL) in the book, which may scare readers who masterfully manage with Microsoft platforms. (Glory to SQL Server!). Comrades, SQL Server Specialists, you just need to adapt the concepts outlined here to your native platform.
The specifics of the book is clearly sharpened for work with distributed applications on the Internet - that is, it is not limited to data analysis, the scope of big data and data warehouses. The authors unambiguously report this on page 86: "We presume that data warehouses should be distributed."
So - if you close your eyes to some minor flaws, this book is an excellent resource for database administrators and their teammates.
Source: https://habr.com/ru/post/349748/
All Articles