Здравствуйте, коллеги!
У нас только что пришла из типографии долгожданная фундаментальная работа Мартина Клеппмана, именуемая в оригинале "Designing Data-Intensive Applications" (анонсировали ее мы еще в сентябре 2016 года). Книга доступна для заказа на сайте (не благодарите, мы сами ликуем)
А в конце ноября прошлого года в издательстве «O'Reilly» вышла долгожданная книга «Database Reliability Engineering», которая, на наш взгляд, отлично дополнила бы работу Клеппмана. Кстати, пока на Amazon — только восторженные отзывы
Под катом мы предлагаем вам не только оптимистичный обзор книги с лошадкой, но и реалистичный комментарий к этому обзору, который, надеемся, также вас заинтересует
При взгляде на обложку Database Reliability Engineering напрашивается вопрос: «Секундочку – а чем этот инжиниринг отличается от администрирования баз данных?»
Обрадую вас: именно на этот вопрос Лэйн Кэмпбелл и Черити Мейджорс первым делом отвечают прямо в предисловии.
Откроем страницу 189, раздел «Репликация данных» в главе 10. Авторы объясняют отличия между:
Репликация с одним ведущим узлом обсуждается на с. 190-202; здесь авторам феноменально удается объяснить все достоинства и недостатки такой системы как «Группы доступности». Да, на 12 страницах невозможно подробно изложить, как проектировать, реализовывать или отлаживать группу доступности. Однако, усвоив эти 12 страниц, вы гораздо лучше усвоите, когда следует рекомендовать подобное решение, и каких подводных камней при этом опасаться.
Именно такова задача инженера по обеспечению надежности баз данных. Такой инженер не просто умеет работать с одной базой данных, но и знает, когда стоит использовать конкретные возможности, когда не стоит и (в общем и целом) – как автоматизировать систему и устранять в ней слабые места.
Эти 12 страниц нравятся мне, так как демонстрируют, насколько же в самом деле широка по охвату эта 250-страничная книга. Авторы обладают глубочайшими знаниями не только о специфике баз данных, но и о взаимодействиях между базой данных и приложениями, о том, как в базе данных реализуется бизнес-логика. Авторы умеют абстрагироваться от собственного опыта именно настолько, чтобы книга была интересна всем, кто профессионально работает с данными; тем не менее, им удается писать достаточно внятно, чтобы изложенный в книге материал можно было непосредственно применять при работе с другими современными технологиями.
Например, здесь не рассказывается, как пользоваться версионированием при обеспечении инфраструктуры на уровне кода. Книга просто констатитрует, что версионирование освоить надо, и знакомит вас с ключевыми терминами, с которых можно начинать освоение этого навыка.
Вам придется изучать новые термины и концепции. Возможно, уйдут годы, прежде, чем они станут применяться на практике в той организации, где вы сейчас работаете. Это нормально – ведь книга нужна для расширения кругозора.
Менеджеры, и вам эта книга тоже будет интересна. Ведь вы поймете: «О, мне нужна команда администраторов баз данных, умеющих делать это и это»
Вам рекомендую внимательно проштудировать главу 2 (управление на уровне услуг) и приступить к работе в таком режиме с теми сотрудниками, которые сейчас у вас есть. Начинайте постановку целей на этом уровне, обсуждайте, как измерять темпы их достижения. На мой взгляд, это сложнейшая часть книги; она предполагает, что владельцы бизнеса будут готовы приходить к компромиссу по этим вопросам. Это проблемы социального, а не технологического плана, и решать их должен именно менеджер…
Из этой главы хочется процитировать две просто восхитительные строки (курсив мой):
Если вы только начинаете заниматься администрированием баз данных, то некоторые термины могут показаться вам знакомыми («управление релизами», «мониторинг», «человеческий фактор»).
Главы 10-12 кажутся просто восхитительными.
В этих главах вы изучите массу масштабных концепций (ACID, CAP-теорема, кэширование, системы обмена сообщениями). Вы просто глазами захлопаете от изумления, а ваше эго при чтении такого текста может скукожиться. Не отчаивайтесь: уже за чтением этих глав вы узнаете массу всего такого, о чем большинство администраторов баз данных даже не подозревает.
Да, разумеется, я рекомендую эту книгу.
Ведь это именно такая книга, которая легко читается, но сложно реализуется. Серьезно, на реализацию одних только услуг на уровне сервисов (тема главы 2) в большинстве типичных компаний требуются месяцы на согласование и отслеживание всех аспектов.
Со временем на место нынешних коммерческих и опенсорсных инструментов придут другие, но сами концепции, изложенные в книге, останутся незыблемыми на протяжении как минимум десяти лет. Эта книга – чудесная лоция для всех, кто привык заглядывать на 5-10 лет вперед, но не против заглянуть и дальше.
Если же вам нравятся такие книги – то также рекомендую Site Reliability Engineering от Google. Не книга, а просто чудо.
КОММЕНТАРИЙ ДЭНА КАРОЛЛО
Да, книга определенно закладывает солидные основы по таким темам, как проектирование, разработка, релизы, жизненный цикл управления производством. Это обязательное чтение для администраторов баз данных, желающих расти над собой, а не просто управлять инфраструктурой.
Некоторые администраторы баз данных могут превращаться в «сварливых вахтеров», замыкающих производственную цепочку. Напротив, в этой книге подчеркивается, как важно для профессионального инженера по работе с данными подключаться к процессу уже на самых ранних этапах – при проектировании и разработке систем.
Из недостатков книги, правда, хотелось бы пожаловаться на переусложненный стиль. Фу!
Кроме того, в книге наблюдается явный перекос в сторону опенсорсных платформ (Linux, MySQL), что может отпугнуть читателей, виртуозно управляющихся с платформами Microsoft. (Слава SQL Server!). Товарищи специалисты по SQL Server, вам просто понадобится адаптировать изложенные здесь концепции к вашей родной платформе.
Специфика книги явно заточена под работу с распределенными приложениями в Интернете – то есть, не ограничивается анализом данных, сферой больших данных и хранилищ данных. Авторы недвусмысленно сообщают об этом на 86-й странице: «Исходим из того, что хранилища данных должны быть распределенными».
Итак — если закрыть глаза на некоторые небольшие огрехи, эта книга – великолепный ознакомительный ресурс для администраторов баз данных и их коллег по команде.
У нас только что пришла из типографии долгожданная фундаментальная работа Мартина Клеппмана, именуемая в оригинале "Designing Data-Intensive Applications" (анонсировали ее мы еще в сентябре 2016 года). Книга доступна для заказа на сайте (не благодарите, мы сами ликуем)
А в конце ноября прошлого года в издательстве «O'Reilly» вышла долгожданная книга «Database Reliability Engineering», которая, на наш взгляд, отлично дополнила бы работу Клеппмана. Кстати, пока на Amazon — только восторженные отзывы
Под катом мы предлагаем вам не только оптимистичный обзор книги с лошадкой, но и реалистичный комментарий к этому обзору, который, надеемся, также вас заинтересует
При взгляде на обложку Database Reliability Engineering напрашивается вопрос: «Секундочку – а чем этот инжиниринг отличается от администрирования баз данных?»
Обрадую вас: именно на этот вопрос Лэйн Кэмпбелл и Черити Мейджорс первым делом отвечают прямо в предисловии.
“…очень долго ремесло администратора баз данных (DBA) заключалось в изготовлении ячеек и снежинок. Инструменты у всех были разные, аппаратура разная, языки программирования тоже разные (…) дни реальной эффективности и стабильности такой модели уже сочтены. Эта книга рассказывает об обеспечении надежности систем с точки зрения инженера баз данных.”Эта книга попросту доставляет: это, фактически, 250-страничная вариация на тему концептуальной книги Google’s Site Reliability Engineering book (она мне нравится), адресованная специалистам, которые, возможно, привыкли считать себя администраторами баз данных, но мечтают о работе в динамично развивающихся грандиозных компаниях.
Как должен читать эту книгу старший инженер баз данных
Откроем страницу 189, раздел «Репликация данных» в главе 10. Авторы объясняют отличия между:
- Репликация с одним ведущим узлом – как в группах доступности «Always On» в Microsoft SQL Server, где только один сервер может принимать операции записи в конкретную базу данных
- Репликация без ведущего узла – как в одноранговой репликации SQL Server, где любой узел может принимать операции записи
- Репликация со множеством ведущих узлов – речь идет о сложных топологиях репликации, где всего 2-3 узла могут принимать операции записи, но все остальные могут принимать операции считывания.
Репликация с одним ведущим узлом обсуждается на с. 190-202; здесь авторам феноменально удается объяснить все достоинства и недостатки такой системы как «Группы доступности». Да, на 12 страницах невозможно подробно изложить, как проектировать, реализовывать или отлаживать группу доступности. Однако, усвоив эти 12 страниц, вы гораздо лучше усвоите, когда следует рекомендовать подобное решение, и каких подводных камней при этом опасаться.
Именно такова задача инженера по обеспечению надежности баз данных. Такой инженер не просто умеет работать с одной базой данных, но и знает, когда стоит использовать конкретные возможности, когда не стоит и (в общем и целом) – как автоматизировать систему и устранять в ней слабые места.
Эти 12 страниц нравятся мне, так как демонстрируют, насколько же в самом деле широка по охвату эта 250-страничная книга. Авторы обладают глубочайшими знаниями не только о специфике баз данных, но и о взаимодействиях между базой данных и приложениями, о том, как в базе данных реализуется бизнес-логика. Авторы умеют абстрагироваться от собственного опыта именно настолько, чтобы книга была интересна всем, кто профессионально работает с данными; тем не менее, им удается писать достаточно внятно, чтобы изложенный в книге материал можно было непосредственно применять при работе с другими современными технологиями.
Например, здесь не рассказывается, как пользоваться версионированием при обеспечении инфраструктуры на уровне кода. Книга просто констатитрует, что версионирование освоить надо, и знакомит вас с ключевыми терминами, с которых можно начинать освоение этого навыка.
Вам придется изучать новые термины и концепции. Возможно, уйдут годы, прежде, чем они станут применяться на практике в той организации, где вы сейчас работаете. Это нормально – ведь книга нужна для расширения кругозора.
Как должен читать эту книгу менеджер
Менеджеры, и вам эта книга тоже будет интересна. Ведь вы поймете: «О, мне нужна команда администраторов баз данных, умеющих делать это и это»
Вам рекомендую внимательно проштудировать главу 2 (управление на уровне услуг) и приступить к работе в таком режиме с теми сотрудниками, которые сейчас у вас есть. Начинайте постановку целей на этом уровне, обсуждайте, как измерять темпы их достижения. На мой взгляд, это сложнейшая часть книги; она предполагает, что владельцы бизнеса будут готовы приходить к компромиссу по этим вопросам. Это проблемы социального, а не технологического плана, и решать их должен именно менеджер…
Из этой главы хочется процитировать две просто восхитительные строки (курсив мой):
“SLO (Цели на уровне услуг) регламентируют правила игры, которым мы подчиняемся. Эти цели нужны, чтобы решить, на какие риски мы готовы пойти, какие архитектурные решения принять, как спроектировать процессы, которые будут обеспечивать функционирование таких архитектур.”Феномены «доступность» и «время задержки» для инженера по надежности баз данных столь же важны, как «доход» и «прибыль» для продажника. Кому придет в голову сказать сбытовикам: «Ой, просто выбейте оптимальную цену, какую сможете – и все будет нормально». С инженерами по обеспечению надежности такой номер тоже не пройдет.
Как должен читать эту книгу разработчик и сисадмин
Если вы только начинаете заниматься администрированием баз данных, то некоторые термины могут показаться вам знакомыми («управление релизами», «мониторинг», «человеческий фактор»).
Главы 10-12 кажутся просто восхитительными.
В этих главах вы изучите массу масштабных концепций (ACID, CAP-теорема, кэширование, системы обмена сообщениями). Вы просто глазами захлопаете от изумления, а ваше эго при чтении такого текста может скукожиться. Не отчаивайтесь: уже за чтением этих глав вы узнаете массу всего такого, о чем большинство администраторов баз данных даже не подозревает.
Да, разумеется, я рекомендую эту книгу.
Ведь это именно такая книга, которая легко читается, но сложно реализуется. Серьезно, на реализацию одних только услуг на уровне сервисов (тема главы 2) в большинстве типичных компаний требуются месяцы на согласование и отслеживание всех аспектов.
Со временем на место нынешних коммерческих и опенсорсных инструментов придут другие, но сами концепции, изложенные в книге, останутся незыблемыми на протяжении как минимум десяти лет. Эта книга – чудесная лоция для всех, кто привык заглядывать на 5-10 лет вперед, но не против заглянуть и дальше.
Если же вам нравятся такие книги – то также рекомендую Site Reliability Engineering от Google. Не книга, а просто чудо.
КОММЕНТАРИЙ ДЭНА КАРОЛЛО
Да, книга определенно закладывает солидные основы по таким темам, как проектирование, разработка, релизы, жизненный цикл управления производством. Это обязательное чтение для администраторов баз данных, желающих расти над собой, а не просто управлять инфраструктурой.
Некоторые администраторы баз данных могут превращаться в «сварливых вахтеров», замыкающих производственную цепочку. Напротив, в этой книге подчеркивается, как важно для профессионального инженера по работе с данными подключаться к процессу уже на самых ранних этапах – при проектировании и разработке систем.
Из недостатков книги, правда, хотелось бы пожаловаться на переусложненный стиль. Фу!
Кроме того, в книге наблюдается явный перекос в сторону опенсорсных платформ (Linux, MySQL), что может отпугнуть читателей, виртуозно управляющихся с платформами Microsoft. (Слава SQL Server!). Товарищи специалисты по SQL Server, вам просто понадобится адаптировать изложенные здесь концепции к вашей родной платформе.
Специфика книги явно заточена под работу с распределенными приложениями в Интернете – то есть, не ограничивается анализом данных, сферой больших данных и хранилищ данных. Авторы недвусмысленно сообщают об этом на 86-й странице: «Исходим из того, что хранилища данных должны быть распределенными».
Итак — если закрыть глаза на некоторые небольшие огрехи, эта книга – великолепный ознакомительный ресурс для администраторов баз данных и их коллег по команде.
Only registered users can participate in poll. Log in, please.
Книга Database Reliability Engineering
73.03% Очень интересует65
2.25% Совершенно не интересует2
33.71% Интересует только после выхода русского перевода «Site Reliability Engineering»30
89 users voted. 17 users abstained.
