Также гугл гарантирует доступность базы данных на уровне 99,95%. Дополнительно получаем автоматическую репликацию и бекапы.<\/p>\n
Ограничения<\/b><\/p>\n Spanner — реляционная база данных, разработка Google. Spanner позиционирует себя как горизонтально масштабируемая база данных, способна хранить петабайты информации, гарантирует строгую согласованность данных. А также доступность 99.999%.<\/p>\n По своей природе Cloud Spanner это распределённая база данных с автоматическим шардированием и репликацией, которые скрыты под капотом. Чтобы создать БД, нужно выбрать локацию (region или multi-region) и количество нод. Количество нод влияет на размер данных, которые кластер способен хранить и его доступность. Каждая нода может обслуживать до 2 Тб данных.<\/p>\n Пример кластера, который состоит из 4 нод. Каждая зона содержит полную копию базы данных и 4 процесса, которые обслуживают эти данные.<\/p>\n Гугл советует иметь минимум 3 ноды для прода. Но есть один нюанс — цена. Cloud Spanner очень дорогое решение, созданное для работы с огромным количеством данных. За 1 петабайт данных прийдется отдать ......... 1 645 568 $ ......... в месяц.<\/p>\n Столбцовая NoSQL база данных, которая масштабируется до миллиарда строк и тысяч колонок. Способна хранить петабайты информации.<\/p>\n Основная фича — наличие интерфейса HBase и нативная поддержка Hadoop. Это позволяет перенести данные с собственного кластера в Big Table без каких либо изменений. Big Table идеально подойдёт для очень быстрой записи и чтения, а также хранения данных типа ключ\/значения, размер которых не превышает 10 Мб.<\/p>\n Данные внутри базы данных лежат в огромных таблицах. Грубо говоря, таблица в HBase представлена в виде огромного словаря словарей. Таблица состоит из строк, каждая из которых обычно описывает одну сущность, и столбцов, которые содержат отдельные значения для каждой строки. Каждая строка индексируется одним ключом, а столбцы, которые связаны друг с другом, обычно группируются в семейство столбцов.<\/p>\n Для более глубокого ознакомления советую прочитать главу «HBase» из книги «7 баз данных за 7 недель». Также советую ознакомится с официальной документацией<\/a>.<\/p>\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 Детальнее с режимами можно ознакомится в официальной документации<\/a>.<\/p>\n Управляемый in-memory сервис, построенный на базе Redis и memcached.<\/p>\n Шардинг (иногда шардирование) — это другая техника масштабирования работы с данными. Суть его в разделении (партиционирование) базы данных на отдельные части так, чтобы каждую из них можно было вынести на отдельный сервер. Этот процесс зависит от структуры базы данных и выполняется прямо в приложении в отличие от репликации<\/p>\n Вертикальный шардинг — это выделение таблицы или группы таблиц на отдельный сервер. Например, в приложении есть такие таблицы:<\/p>\n Таблицу users Вы оставляете на одном сервере, а таблицы photos<\/i> и albums<\/i> переносите на другой. В таком случае в приложении Вам необходимо будет использовать соответствующее соединение для работы с каждой таблицей<\/p>\n Горизонтальный шардинг — это разделение одной таблицы на разные сервера. Это необходимо использовать для огромных таблиц, которые не умещаются на одном сервере. Разделение таблицы на куски делается по такому принципу:<\/p>\n Шардинг и репликация часто используются совместно. В нашем примере, мы могли бы использовать по два сервера на каждый шард таблицы<\/p>\n Следует отметить, что большинство Key-value баз данных поддерживает шардинг на уровне платформы. Например, Memcache. В таком случае, Вы просто указываете набор серверов для соединения, а платформа сделает все остальное<\/p>\n Не следует применять технику шардинга ко всем таблицам. Правильный подход — это поэтапный процесс разделения растущих таблиц. Следует задумываться о горизонтальном шардинге, когда количество записей в одной таблице переходит за пределы от нескольких десятков миллионов до сотен миллионов.<\/p>\n Помните, процесс масштабирования данных — это архитектурное решение, оно не связано с конкретной технологией. Не делайте ошибок наших отцов — не переезжайте с известной Вам технологии на новую из-за поддержки или не поддержки шардинга. Проблемы обычно связаны с архитектурой, а не конкретной базой данных<\/p>\n Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других. Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.<\/p>\n Существует два основных подхода при работе с репликацией данных:<\/p>\n В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы INSERT\/UPDATE\/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных. Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.<\/p>\n Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером. При выходе из строя Слейва, достаточно просто переключить все приложение на работу с Мастером. После этого восстановить репликацию на Слейве и снова его запустить. В этой схеме, любой из серверов может использоваться как для чтения так и для записи.<\/p>\n Некоторые технологии вообще не имеют встроенной репликации. В таких случаях, следует использовать самостоятельную реализацию репликации. В самом простом случае, приложение будет дублировать все запросы сразу на несколько серверов базы данных.<\/p>\n Репликация используется в большей мере для резервирования баз данных и в меньшей для масштабирования. Master-Slave репликация удобна для распределения запросов чтения по нескольким серверам. Подход ручной репликации позволит использовать преимущества репликации для технологий, которые ее не поддерживают. Зачастую репликация используется вместе с шардингом при решении вопросов масштабирования.<\/p>\n Следует отметить, что репликация сама по себе не очень удобный механизм масштабирования. Причиной тому — рассинхронизация данных и задержки в копировании с мастера на слейв. Зато это отличное средство для обеспечения отказоустойчивости. Вы всегда можете переключиться на слейв, если мастер ломается и наоборот. Чаще всего репликация используется совместно с шардингом именно из соображений надежности.<\/p>\n",
"date_published": "2019-04-05T02:23:42+05:00",
"date_modified": "2023-06-03T05:29:49+05:00",
"tags": [
"system-design",
"бази даних"
],
"author": {
"name": "Bohdan Stefaniuk",
"url": "https:\/\/stefaniuk.website\/",
"avatar": "https:\/\/stefaniuk.website\/pictures\/userpic\/userpic@2x.jpg?1565716580"
},
"_date_published_rfc2822": "Fri, 05 Apr 2019 02:23:42 +0500",
"_rss_guid_is_permalink": "false",
"_rss_guid": "119853",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": null,
"og_images": []
}
}
],
"_e2_version": 4079,
"_e2_ua_string": "Aegea 11.0 (v4079e)"
}\n
Cloud Spanner<\/h2>\n
![\"\"](\"https:\/\/stefaniuk.website\/pictures\/gcp-db-regional-instance-config.png\")
\n<\/div>\n![\"\"](\"https:\/\/stefaniuk.website\/pictures\/gcp-db-spanner-price.png\")
\n<\/div>\nCloud Big Table<\/h2>\n
![\"\"](\"https:\/\/stefaniuk.website\/pictures\/gcp-db-big-table.png\")
\n<\/div>\nCloud Firestore<\/h2>\n
\n
Cloud Memorystore<\/h2>\n
Сравнение<\/h2>\n
![\"\"](\"https:\/\/stefaniuk.website\/pictures\/gcp-db-compare.png\")
\n<\/div>\n",
"date_published": "2020-10-15T01:24:00+05:00",
"date_modified": "2023-06-03T05:29:41+05:00",
"tags": [
"cloud",
"google cloud platform",
"бази даних"
],
"author": {
"name": "Bohdan Stefaniuk",
"url": "https:\/\/stefaniuk.website\/",
"avatar": "https:\/\/stefaniuk.website\/pictures\/userpic\/userpic@2x.jpg?1565716580"
},
"_date_published_rfc2822": "Thu, 15 Oct 2020 01:24:00 +0500",
"_rss_guid_is_permalink": "false",
"_rss_guid": "119852",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": null,
"og_images": []
}
},
{
"id": "119854",
"url": "https:\/\/stefaniuk.website\/all\/sharding\/",
"title": "Шардинг",
"content_html": "Вертикальный шардинг<\/h2>\n
\n
Горизонтальный шардинг<\/h2>\n
\n
Совместное использование<\/h2>\n
Key-value базы данных<\/h2>\n
Итог<\/h2>\n
P.S.<\/h2>\n
Ссылки<\/h2>\n
\n
\n
Master-Slave репликация<\/h2>\n
Несколько Слейвов<\/h2>\n
\nТогда из приложения выбирает случайным образом один из Слейвов для обработки запросов, тем самым распределяя нагрузку на БД.<\/p>\nВыход из строя<\/h2>\n
\nЕсли выходит из строя Мастер, нужно переключить все операции (и чтения и записи) на Слейв. Таким образом он станет новым Мастером. После восстановления старого Мастера, настроить на нем реплику, и он станет новым Слейвом.<\/p>\nMaster-Master репликация<\/h2>\n
«Ручная» репликация<\/h2>\n
Итог<\/h2>\n