тва приводит к ухудшению другого. В зависимости от требований выбирается база данных, у которых либо преобладает два каких-то свойства, либо они находятся в нужном компромиссе, при этом значимость свойств не равнозначна. Так, если база данных полностью недоступна, то согласованность и устойчивость не могут компенсировать этот недостаток из-за нарушения смысла СУБД – обеспечивать доступ к данным. Согласованность является вторым по значимости фактором, так если данные неверны существенную часть времени – для обычной эксплуатации такая СУБД не подходит. Но, вполне можно можно смириться с некоторой несогласованность в течении какого-то времени при записи логов в обмен на распределённость, дающая возможность хранить их в нужном объёме. С ростом нагрузки и количества данных, требованию к отказоустойчивости, при невозможности обеспечить их в рамках одного сервера, и возросшей доступности облачных технологий, борьба производителей СУБД сводится к увеличению разделимости и сокращению пагубного влияния их на первые два описанных свойства. В настоящем времени это удаётся сделать (Google Spanner, YandexDB), но платой является накладные расходы, которые нивелируются при обработке больших данных за счёт распараллеливания обработки. Примерами распределённых баз данных могут быть CouchDB (2005), Cassandra (2008), MongoDB (2009), а обеспечивающих по всем векторам CAP теоремы наилучшие показатели – Google Spanner (2012) и YandexDB в обмен на неторопливость и внутреннюю сложность.
Облачные технологии предоставили новые форматы предоставления, в особенности, в публичном облаках. Надёжность подобны баз данных высока, ниже мы протестируем и прикинем её. Одним из них – формат предоставления баз данных – базы данных, распространяемые только как версис для сервисов в облаке. Примерами, подобных баз данных, могут быть Amazon Redshift и Amazon DynamoDB в AWS (Amazon Web Services, Amazon Cloud), Yandex Database в Яндекс.Облако, Spanner в GCP (Google Cloud Platform), Microsoft Azure SQL Databases в Azure Cloud. Производители самих баз данных, выпускаю свои базы данных как сервис, так поступили 1C и MongoDB в виде MongoDB Atlas, а обзавевшись публичными облаками и в них, например Clickhouse в Яндекс.Облако и Oracle Database Cloud в Oracle Cloud. Универсальные свободные базы данных, такие как MySQL и PostgresQL, не предназначены быть распределёнными в полной мере, также, получили модификации и стали доступны в облаках как сервис, где обслуживанием занимается облако, за что берётся плата за израсходованные ресурсы и сервис, но не за саму базу данных. Пользователю достаточно выбрать базу данных, а облако само развернёт кластер базы данных, позаботится о масштабировании и бэкапировании, и предоставит пользователю гарантии (SLA) по доступности и масштабируемости. Близкое можно сделать и самому, воспользовавшись операторами в Kuberntes, который развернёт кластер базы данных – об этом в следующих главах. В противопоставление разрабатываются свободные облачные базы данных, такие как CockroachDB, на примере котором мы и рассмотрим работу баз данных в облаке, специально разработанных под него.
База данных в облаке
Разновидностей баз данных довольно много. Разновидности, в основном, определяет пригодность базы данных для конкретных задач. Сильным помощником в выборе класса СУБД (далее, для простоты, база данных) является, так называемая, CAP теорема. CAP теорема – это сокращение conssistency (согласованность), availabiliry (доступность), portition tolerance (устойчивость к разделению). Она определяет, что при этих свойства базы данных и гласит, что база данных (система управления базой данных) обладает двумя или менее свойствами из трёх перечисленных. При этом свойства не дискретны (присутствует или отсутствует), а преобладание одного свойства приводит к ухудшению другого. В зависимости от требований выбирается база данных, у которых либо преобладает два каких-то свойства, либо они находятся в нужном компромиссе, при этом значимость свойств не равнозначна. Так, если база данных полностью недоступна, то согласованность и устойчивость не могут компенсировать этот недостаток из-за нарушения смысла СУБД – обеспечивать доступ к данным. Согласованность является вторым по значимости фактором, так если данные неверны существенную часть времени – для обычной эксплуатации такая СУБД не подходит. Но, вполне можно можно смириться с некоторой несогласованность в течении какого-то времени при записи логов в обмен на распределённость, дающая возможность хранить их в нужном объёме. С ростом нагрузки и количества данных, требованию к отказоустойчивости, при невозможности обеспечить их в рамках одного сервера, борьба производителей СУБД сводится к увеличению разделимости и сокращению пагубного влияния их на первые два описанных свойства, и в настоящем времени это удаётся сделать (Google Spanner, YandexDB), но платой является накладные расходы, которые нивелируются при обработке больших данных за счёт распараллеливания обработки. Примерами распредённых баз данных могут быть CouchDB (2005), Cassandra (2008), MongoDB (2009), а обеспечивающих по всем векторам CAP теоремы наилучшие показатели – Google Spanner (2012) и YandexDB в обмен на неторопливость и сложность.
Рассмотрим базу данных (СУБД) на примере CockroachDB – современной замене популярной Open Source безе PostgeSQL в облаке. Она разработана специально быть распределённой в облаке и доброжелательна к пользователям. Администраторам предоставляются YML-конфиги, HELM чарты, OpenShift операторы для развёртывания. CockroachDB существует в двух редакциях:
