Отдельно стоит упомянуть уровни изоляции, потому что их понимание позволяет находить баги в коде, который работает с базой. Самих уровней существую большое множество, но рассмотрим четыре основных:<\/p>\n
- \n
- read uncommited<\/b> — позволяет избежать потерянных обновлений, когда две транзакции изменяют одни и те же данные. Для этого одна транзакция блокирует данные, которые хочет изменить для других UPDATE операций в других транзакциях.<\/li>\n
- read committed<\/b> — решает проблему грязного чтения, когда вычитываем данные во время их обновления. Это может привести к тому что мы получим частично обновленные данные. В таком случае UPDATE операции в транзакции блокируют UPDATE и SELECT операции в других транзакциях. Именно этот уровень изоляции используется по умолчанию в большинстве БД.<\/li>\n
- repeatable read<\/b> — внутри транзакции может быть несколько операций SELECT, которые читают одни и те же данные. Repeatable read гарантирует что это операции внутри одной транзакции будут возвращать одинаковые данные. Даже если другие транзакции хотят их удалить или изменить. В таком случает транзакция блокирует все строчки, которые затрагивают операции UPDATE и SELECT.<\/li>\n
- serializable<\/b> — исключает проблему «фантомных чтений», которые возникают при вставке новой строки между двумя операциями SELECT внутри одной транзакции. Больше всего эта проблема влияет на агрегационные запросы. Такой уровень изоляции является самым строгим, все транзакции выполняются так, будто других параллельных транзакций не существует.<\/li>\n<\/ul>\n", "date_published": "2022-05-06T10:20:27-04:00", "date_modified": "2022-04-30T10:27:31-04:00", "tags": [ "бази даних", "програмування" ], "_date_published_rfc2822": "Fri, 06 May 2022 10:20:27 -0400", "_rss_guid_is_permalink": "false", "_rss_guid": "265", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "241", "url": "https:\/\/www.stefaniuk.website\/all\/gcp-databases\/", "title": "GCP: Databases", "content_html": "
Google Cloud Platform предоставляет большой выбор разных способов хранить данные. Некоторые из них построены на базе существующих продуктов, другие — собственная разработка гугла.<\/p>\n
Для начала нужно понять, что такое managed databases. Это услуга по настройке и администрированию баз данных. Облачный провайдер сам отвечает за работу сервера, установку патчей безопасности, доступность сервиса. Для того чтобы достичь такого же результата с помощью self hosted, нужно иметь в штате специалиста, который умеет администрировать сервера, закупить железо и подготовить инфраструктуру. В случае с managed databases платишь только за то количество ресурсов, которое используешь.<\/p>\n
Cloud SQL<\/h2>\n
Cloud SQL это классический managed database сервис. Он позволяет развернуть 3 самые популярные базы данных. Такие как:<\/p>\n
- \n
- MySQL (5.6, 5.7 и 8.0)<\/li>\n
- PostgreSQL (9.6, 10, 11, 12)<\/li>\n
- MS SQL Server 2017<\/li>\n<\/ul>\n
Также гугл гарантирует доступность базы данных на уровне 99,95%. Дополнительно получаем автоматическую репликацию и бекапы.<\/p>\n
Ограничения<\/b><\/p>\n
- \n
- 30 Tb хранилища<\/li>\n
- 60,000 IOPS<\/li>\n
- 624 Gb RAM<\/li>\n
- Реплики БД только для чтения<\/li>\n<\/ul>\n
Cloud Spanner<\/h2>\n
Spanner — реляционная база данных, разработка Google. Spanner позиционирует себя как горизонтально масштабируемая база данных, способна хранить петабайты информации, гарантирует строгую согласованность данных. А также доступность 99.999%.<\/p>\n
По своей природе Cloud Spanner это распределённая база данных с автоматическим шардированием и репликацией, которые скрыты под капотом. Чтобы создать БД, нужно выбрать локацию (region или multi-region) и количество нод. Количество нод влияет на размер данных, которые кластер способен хранить и его доступность. Каждая нода может обслуживать до 2 Тб данных.<\/p>\n
Пример кластера, который состоит из 4 нод. Каждая зона содержит полную копию базы данных и 4 процесса, которые обслуживают эти данные.<\/p>\n
\n![\"\"](\"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-regional-instance-config.png\")
\n<\/div>\nГугл советует иметь минимум 3 ноды для прода. Но есть один нюанс — цена. Cloud Spanner очень дорогое решение, созданное для работы с огромным количеством данных. За 1 петабайт данных прийдется отдать ......... 1 645 568 $ ......... в месяц.<\/p>\n
\n![\"\"](\"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-spanner-price.png\")
\n<\/div>\nCloud Big Table<\/h2>\n
Столбцовая NoSQL база данных, которая масштабируется до миллиарда строк и тысяч колонок. Способна хранить петабайты информации.<\/p>\n
Основная фича — наличие интерфейса HBase и нативная поддержка Hadoop. Это позволяет перенести данные с собственного кластера в Big Table без каких либо изменений. Big Table идеально подойдёт для очень быстрой записи и чтения, а также хранения данных типа ключ\/значения, размер которых не превышает 10 Мб.<\/p>\n
Данные внутри базы данных лежат в огромных таблицах. Грубо говоря, таблица в HBase представлена в виде огромного словаря словарей. Таблица состоит из строк, каждая из которых обычно описывает одну сущность, и столбцов, которые содержат отдельные значения для каждой строки. Каждая строка индексируется одним ключом, а столбцы, которые связаны друг с другом, обычно группируются в семейство столбцов.<\/p>\n
\n![\"\"](\"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-big-table.png\")
\n<\/div>\nДля более глубокого ознакомления советую прочитать главу «HBase» из книги «7 баз данных за 7 недель». Также советую ознакомится с официальной документацией<\/a>.<\/p>\n
Cloud Firestore<\/h2>\n
Cloud Firestore — это полностью управляемая,документоориентированная serverless база данных, предназначена для разработки serverless приложений. Структура данных сильно напоминает такую в MongoDB.<\/p>\n
Firestore поддерживает офлайн режим и живую синхронизацию. С помощью этих фич удобно строить приложения, которые предназначены для совместного использования, например, Google Docs или другие похожие варианты.<\/p>\n
А также она пришла на замену предыдущего сервиса — Cloud Datastore. В 2021 году гугл обещает автоматически всех мигрировать с Datastore на Firestore. Это возможно благодаря обратной совместировать с Datastore API.<\/p>\n
Firestore имеет два режива работы:<\/p>\n
- \n
- Datastore mode<\/b>, создан для серверных приложений, совместим с Cloud Datastore. Поддерживает согласованность в конечном счёте.<\/li>\n
- Native mode<\/b>, создан для веб и мобильных платформ. Поддерживает строгую согласованость и все основные фичи Firestore.<\/li>\n<\/ul>\n
Детальнее с режимами можно ознакомится в официальной документации<\/a>.<\/p>\n
Cloud Memorystore<\/h2>\n
Управляемый in-memory сервис, построенный на базе Redis и memcached.<\/p>\n
Сравнение<\/h2>\n
\n![\"\"](\"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-compare.png\")
\n<\/div>\n",
"date_published": "2020-10-14T16:24:00-04:00",
"date_modified": "2023-06-02T20:29:41-04:00",
"tags": [
"cloud",
"google cloud platform",
"бази даних"
],
"image": "https:\/\/www.stefaniuk.website\/pictures\/gcp-db-regional-instance-config.png",
"_date_published_rfc2822": "Wed, 14 Oct 2020 16:24:00 -0400",
"_rss_guid_is_permalink": "false",
"_rss_guid": "241",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-regional-instance-config.png",
"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-spanner-price.png",
"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-big-table.png",
"https:\/\/www.stefaniuk.website\/pictures\/gcp-db-compare.png"
]
}
},
{
"id": "47",
"url": "https:\/\/www.stefaniuk.website\/all\/sharding\/",
"title": "Шардинг",
"content_html": "Шардинг (иногда шардирование) — это другая техника масштабирования работы с данными. Суть его в разделении (партиционирование) базы данных на отдельные части так, чтобы каждую из них можно было вынести на отдельный сервер. Этот процесс зависит от структуры базы данных и выполняется прямо в приложении в отличие от репликации<\/p>\n
Вертикальный шардинг<\/h2>\n
Вертикальный шардинг — это выделение таблицы или группы таблиц на отдельный сервер. Например, в приложении есть такие таблицы:<\/p>\n
- \n
- users<\/i> — данные пользователей<\/li>\n
- photos<\/i> — фотографии пользователей<\/li>\n
- albums<\/i> — альбомы пользователей<\/li>\n<\/ul>\n
Таблицу users Вы оставляете на одном сервере, а таблицы photos<\/i> и albums<\/i> переносите на другой. В таком случае в приложении Вам необходимо будет использовать соответствующее соединение для работы с каждой таблицей<\/p>\n
Горизонтальный шардинг<\/h2>\n
Горизонтальный шардинг — это разделение одной таблицы на разные сервера. Это необходимо использовать для огромных таблиц, которые не умещаются на одном сервере. Разделение таблицы на куски делается по такому принципу:<\/p>\n
- \n
- На нескольких серверах создается одна и та же таблица (только структура, без данных).<\/li>\n
- В приложении выбирается условие, по которому будет определяться нужное соединение (например, четные на один сервер, а нечетные — на другой).<\/li>\n
- Перед каждым обращением к таблице происходит выбор нужного соединения.<\/li>\n<\/ul>\n
Совместное использование<\/h2>\n
Шардинг и репликация часто используются совместно. В нашем примере, мы могли бы использовать по два сервера на каждый шард таблицы<\/p>\n
Key-value базы данных<\/h2>\n
Следует отметить, что большинство Key-value баз данных поддерживает шардинг на уровне платформы. Например, Memcache. В таком случае, Вы просто указываете набор серверов для соединения, а платформа сделает все остальное<\/p>\n
Итог<\/h2>\n
Не следует применять технику шардинга ко всем таблицам. Правильный подход — это поэтапный процесс разделения растущих таблиц. Следует задумываться о горизонтальном шардинге, когда количество записей в одной таблице переходит за пределы от нескольких десятков миллионов до сотен миллионов.<\/p>\n
P.S.<\/h2>\n
Помните, процесс масштабирования данных — это архитектурное решение, оно не связано с конкретной технологией. Не делайте ошибок наших отцов — не переезжайте с известной Вам технологии на новую из-за поддержки или не поддержки шардинга. Проблемы обычно связаны с архитектурой, а не конкретной базой данных<\/p>\n
Ссылки<\/h2>\n
- \n
- Вертикальный шардинг<\/a><\/li>\n
- Шардинг и репликация<\/a><\/li>\n<\/ol>\n", "date_published": "2019-04-04T17:26:34-04:00", "date_modified": "2023-06-02T20:29:59-04:00", "tags": [ "system-design", "бази даних" ], "_date_published_rfc2822": "Thu, 04 Apr 2019 17:26:34 -0400", "_rss_guid_is_permalink": "false", "_rss_guid": "47", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "46", "url": "https:\/\/www.stefaniuk.website\/all\/db-replication\/", "title": "Репликация данных", "content_html": "
Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других. Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.<\/p>\n
Существует два основных подхода при работе с репликацией данных:<\/p>\n
- \n
- Репликация Master-Slave;<\/li>\n
- Репликация Master-Master.<\/li>\n<\/ol>\n
Master-Slave репликация<\/h2>\n
В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы INSERT\/UPDATE\/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных. Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.<\/p>\n
Несколько Слейвов<\/h2>\n
Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.
\nТогда из приложения выбирает случайным образом один из Слейвов для обработки запросов, тем самым распределяя нагрузку на БД.<\/p>\nВыход из строя<\/h2>\n
При выходе из строя Слейва, достаточно просто переключить все приложение на работу с Мастером. После этого восстановить репликацию на Слейве и снова его запустить.
\nЕсли выходит из строя Мастер, нужно переключить все операции (и чтения и записи) на Слейв. Таким образом он станет новым Мастером. После восстановления старого Мастера, настроить на нем реплику, и он станет новым Слейвом.<\/p>\nMaster-Master репликация<\/h2>\n
В этой схеме, любой из серверов может использоваться как для чтения так и для записи.<\/p>\n
«Ручная» репликация<\/h2>\n
Некоторые технологии вообще не имеют встроенной репликации. В таких случаях, следует использовать самостоятельную реализацию репликации. В самом простом случае, приложение будет дублировать все запросы сразу на несколько серверов базы данных.<\/p>\n
Итог<\/h2>\n
Репликация используется в большей мере для резервирования баз данных и в меньшей для масштабирования. Master-Slave репликация удобна для распределения запросов чтения по нескольким серверам. Подход ручной репликации позволит использовать преимущества репликации для технологий, которые ее не поддерживают. Зачастую репликация используется вместе с шардингом при решении вопросов масштабирования.<\/p>\n
Следует отметить, что репликация сама по себе не очень удобный механизм масштабирования. Причиной тому — рассинхронизация данных и задержки в копировании с мастера на слейв. Зато это отличное средство для обеспечения отказоустойчивости. Вы всегда можете переключиться на слейв, если мастер ломается и наоборот. Чаще всего репликация используется совместно с шардингом именно из соображений надежности.<\/p>\n", "date_published": "2019-04-04T17:23:42-04:00", "date_modified": "2023-06-02T20:29:49-04:00", "tags": [ "system-design", "бази даних" ], "_date_published_rfc2822": "Thu, 04 Apr 2019 17:23:42 -0400", "_rss_guid_is_permalink": "false", "_rss_guid": "46", "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } } ], "_e2_version": 4116, "_e2_ua_string": "Aegea 11.2 (v4116)" }
- Шардинг и репликация<\/a><\/li>\n<\/ol>\n", "date_published": "2019-04-04T17:26:34-04:00", "date_modified": "2023-06-02T20:29:59-04:00", "tags": [ "system-design", "бази даних" ], "_date_published_rfc2822": "Thu, 04 Apr 2019 17:26:34 -0400", "_rss_guid_is_permalink": "false", "_rss_guid": "47", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "46", "url": "https:\/\/www.stefaniuk.website\/all\/db-replication\/", "title": "Репликация данных", "content_html": "
- Вертикальный шардинг<\/a><\/li>\n
- photos<\/i> — фотографии пользователей<\/li>\n
- Native mode<\/b>, создан для веб и мобильных платформ. Поддерживает строгую согласованость и все основные фичи Firestore.<\/li>\n<\/ul>\n
- Datastore mode<\/b>, создан для серверных приложений, совместим с Cloud Datastore. Поддерживает согласованность в конечном счёте.<\/li>\n
- read committed<\/b> — решает проблему грязного чтения, когда вычитываем данные во время их обновления. Это может привести к тому что мы получим частично обновленные данные. В таком случае UPDATE операции в транзакции блокируют UPDATE и SELECT операции в других транзакциях. Именно этот уровень изоляции используется по умолчанию в большинстве БД.<\/li>\n