Database Design

Я побывал на достаточно большом количестве архитектурных встреч, чтобы знать, что происходит, когда кто-то упоминает теорему CAP: в комнате становится тихо, головы понимающе кивают, и внезапно все начинают обсуждать устойчивость к разделению, как будто планируют действия на случай ядерной аварии. Дело в том, что беспокоиться настолько сильно, вероятно, не стоит. Не поймите меня неправильно. Теорема CAP — это законная и важная концепция в распределённых системах. Но она также стала техническим эквивалентом спортивного автомобиля на пригородной подъездной дорожке: впечатляет, что он есть, редко используется на полную мощность и иногда используется для оправдания сомнительных решений в 2 часа ночи во время кризисного совещания....

Позвольте мне быть откровенным: в какой-то момент каждый разработчик сталкивается с тем, что смотрит на панель мониторинга своей базы данных, видит всплеск нагрузки и думает: «Тогда это казалось хорошей идеей». Если ваша база данных становится узким местом, поздравляю — это значит, что ваше приложение работает. К сожалению, это также означает, что нам нужно поговорить о шардинге. Что такое шардинг базы данных и почему это важно? Шардинг базы данных — это, по сути, искусство разбиения монолитной базы данных на небольшие кусочки и распределения их по нескольким серверам....

Посмотрите, я понимаю. NoSQL в тренде. Это круто. Он горизонтально масштабируется как настоящий профи, и где-то около 2015 года мы все решили, что реляционные базы данных устарели, как раскладушки. Но вот неудобная правда, о которой никто не хочет говорить на технических конференциях: для большинства приложений вам, вероятно, не нужен NoSQL, и настаивать на его использовании — это всё равно что принести огнемёт на церемонию зажигания свечей. Я видел слишком много команд, которые загоняли себя в тупик, выбирая MongoDB или Cassandra для проектов, которые были бы вполне довольны старой доброй PostgreSQL....

Когда дело доходит до проектирования баз данных, удивительно, как часто разработчики в итоге получают базу данных, которая скорее мешает, чем помогает. Это происходит не потому, что они некомпетентны, а скорее потому, что проектирование баз данных — сложная и тонкая область, требующая тщательного планирования, скрупулёзного выполнения и глубокого понимания основных принципов. Плохое планирование: фундамент неудачи Представьте, что вы строите дом без проекта. Скорее всего, у вас получится строение, которое будет нестабильным, неэффективным и, возможно, даже опасным....

Конфликт реляционных баз данных Реляционные базы данных десятилетиями были основой для хранения данных, но они имеют свои недостатки. Как разработчик, который сталкивался со сложностями SQL и ограничениями схем реляционных баз данных, я готов привести доводы против того, чтобы всегда использовать реляционные базы данных. Пришло время понять, почему эти устаревшие системы могут не подходить для каждого проекта. Несоответствие объектно-реляционного импеданса Одна из самых больших проблем с реляционными базами данных — это несоответствие объектно-реляционного импеданса....