задний план

В случае увеличения объема данных, который влияет на производительность чтения и записи базы данных, мы обычно используем схему подбазы данных и подтаблицы и используем схему newSql, newSql, например TIDB. Итак, зачем вам нужно использовать TiDB? При каких обстоятельствах следует использовать TiDB? В чем проблема решения традиционной подтаблицы подбазы данных? Также будут объяснены некоторые ключевые моменты и подводные камни. Ниже я интерпретирую это в более просторечной форме, как продвижение TiDB.

Поставьте лайк и посмотрите еще раз, обратите внимание на официальный аккаунт: [Ksitigarbha Thinking], чтобы поделиться со всеми дизайном интернет-сцены и схемой проектирования архитектуры. Самородки: Дзидзо КельвинТалант /user/104639…

текущие болевые точки

В настоящее время независимо от того, использует ли таблица подбазы данных собственную схему JDBC+ThreadLocal, промежуточный программный прокси-сервер или форму встроенного кода SDK, то есть использование sharding-jdbc, zdal и mycat, возникают следующие проблемы.

Выбор схемы алгоритма для подбазы данных и подтаблицы
Для последующего обслуживания после подбазы данных и подтаблицы каждый раз, когда вы добавляете узел, вам необходимо подавать заявку на диски и машины.
Вновь добавленный узел необходимо отключить, а затем выполнить миграцию.Время простоя и миграция повлияют на чтение и запись в режиме реального времени для онлайн-пользователей. Ошибка миграции и откат кода. Перед миграцией подождите, пока в mysql не будет сгенерирован бинарный журнал, прежде чем его можно будет мигрировать.
После подбазы данных и подтаблицы проблема согласованности между базами данных заключается в использовании согласованности в конечном итоге, а обслуживание кода утомительно.
Давление хранения данных и объем хранения данных смещены от определенного узла
Эффективность запроса индекса данных: даже если это подбаза данных, если вы хотите перейти к запросу индекса, вам все равно нужно запросить несколько баз данных, чтобы получить результаты, а затем агрегировать их.
Межбазовое левое соединение с другими таблицами не поддерживается.
Нельзя гарантировать уникальность индекса для разных баз данных и таблиц, например серийный номер платежа. Теперь уникальный ключ подбазы данных и подтаблицы контролируется кодом прикладного уровня.
Добавление полей в таблицы проблематично. Каждая таблица должна быть добавлена в каждую библиотеку
Чтобы получить доступ к эластичному поиску, вам нужно проверить несколько библиотек, чтобы получить доступ к узлу эластичного поиска.
Не удается выполнить запрос на разбивку на страницы

Цель

Проанализируйте, как TiDB решает болевые точки

Общая архитектура TiDB

TiDB — это распределенная база данных. На самом деле, по форме это больше похоже на подход Hadoop, распределяющий данные по разным машинам, и есть копии, есть машины, отвечающие за вычисления, а также машины, отвечающие за хранение.

Уровень входа — tidb-server.На рисунке TiDB является точкой входа для клиентского доступа и отвечает за обработку интерфейса запроса.Этот уровень не предъявляет высоких требований к хранилищу, поэтому требует высокой производительности процессора для вычислений.Также записывает ответственность каждого региона. Второй уровень — PD, который отвечает за планирование, например, в форме zookeeper, он отвечает за планирование переноса данных и планирование выборов. Третий уровень — это tikv, также называемый хранилищем, который отвечает за фактическое хранение данных. Среди них tikv состоит из одного или нескольких регионов, а Region — это наименьшая единица хранения, как и значение Region в алгоритме JVM G1. Каждый регион будет разбросан и распределен по каждому тикву.

модель хранения данных

данные строки (метаданные) Таблица будет храниться одним или несколькими регионами. Разные таблицы будут в разных регионах, а не одни и те же таблицы в каждом репозитории, как в традиционных подрепозиториях. Итак, под таблицей, как определить, в каком регионе хранится каждая строка данных? Во-первых, в регионе есть карта, а ключ состоит из идентификатора таблицы table_id и первичного ключа rowid. Такие как:

t[table_id]_r[row_id]

Значение карты — это реальные данные каждой строки данных в таблице.

данные индекса Данные индекса будут храниться в другом регионе, и каждый раз при построении индекса будет существовать регион, соответствующий этому индексу. Ключ его Карты состоит из table_id, index_id и кодировки значения индексного столбца. Такие как:

t[table_id]_i[index_id][index_value]

Значением является rowid, поэтому этот rowid можно использовать для поиска местоположения данных таблицы выше. Так же, как запрос mysql по индексу, он сначала найдет запись индекса, а затем найдет кластеризованный индекс первичного ключа, чтобы получить логику реальных данных.

сегментация данных

Какой регион находится, зависит от ключа, чтобы вычислить, к какому региону он относится. Он отличается от согласованной схемы алгоритма хеширования подбазы данных и подтаблицы на основе определенного поля. Области TiDB, отвечающие за реальные данные строки, разделены диапазоном первичного ключа. При наличии индекса регион, отвечающий за индекс, будет разделен в соответствии с диапазоном поля индекса. На основе расчета ключа будет получено число, а затем несколько интервалов будут разделены в соответствии с диапазоном, и каждый интервал управляется регионом.

Например: идентификатор строки первичного ключа данных таблицы попадает в 3 региона. [0,10000) [10001,20000) [20001, 30000)

Этот диапазон требует, чтобы это правило было определено до того, как данные будут введены в таблицу.

Поскольку регион будет распределен по всем TiKV, будет несколько серверов для хранения данных, поэтому для решения проблемы будет использоваться несколько процессоров и дисков.Болевая точка 5 Стресс при хранении, тоже решилПроблема 1, какая схема алгоритма используется для подтаблицы подбазы данных, вам нужно только определить диапазон первичного ключа.

О том, как расшириться, поговорим позже.

Повышение эффективности индексации

Существующие проблемы: Индексы традиционной подбазы данных и подтаблицы находятся в каждом экземпляре MySQL и следуют за таблицей. Правила для подбазы данных и подтаблицы обычно основаны на пользовательском поле идентификатора пользователя в таблице или поле с высокой композицией, чтобы сделать ключ подбазы данных или таблицы, один и тот же идентификатор пользователя попадет в ту же базу данных или таблицу. .

Однако в приведенном выше случае поле индекса в таблице считается кодом, а code="aaa" может попасть в разные библиотеки из-за разных идентификаторов пользователей. После запроса полной библиотеки и таблицы повторите агрегирование, что приведет к in Увеличить потребление запроса ЦП, а также потребление рукопожатия TCP-соединения.

Решение TiDB: Однако в TiKV есть регион, специально используемый для хранения индексов. Ключ его структуры данных определяется идентификатором таблицы + идентификатором индекса + идентификатором значения индекса. Значение является первичным ключом строки данных rowid, а регион управляет диапазоном ключей, поэтому один и тот же индекс. Одно и то же значение будет в регионе, поэтому лучше быстро найти регион с тем же значением индекса, получить соответствующий идентификатор строки, а затем быстрее найти фактические данные таблицы в регионе, где таблица данные хранятся в соответствии с rowid. Нет необходимости выполнять поиск по индексу всей базы данных, потому что механизм поиска по индексу MySQL заключается в том, чтобы сначала найти значение индекса, затем найти первичный ключ кластера и вернуть всю строку данных, тем самым повышая производительность.

Этот подход немного похож на инвертированный индекс эластичного поиска, который сначала находит исходное положение данных в соответствии со значением. здесьРешите проблему 6, чтобы уменьшить нагрузку на запросы индекса..

Особенности TIDB

1. Обеспечьте оптимистическую модель транзакции и пессимистическую модель транзакции.

До версии 3.0.8 существовала только оптимистичная модель транзакций, и транзакция совершалась 2PC дважды. Если включить пессимистическую модель транзакций, она будет больше похожа на гибкую транзакцию sharding-jdbc, которая имеет функцию повтора, но при многократном повторении (256 раз) сбой все равно будет потерян.

1.1 Анализ преимуществ и недостатков

Транзакции TiDB имеют следующие преимущества:

Принцип реализации прост и понятен.
Межузловые транзакции реализуются на основе одноэкземплярных транзакций.
Управление замками обеспечивает децентрализацию. Но транзакции TiDB также имеют следующие недостатки:
Двухфазная фиксация увеличивает сетевое взаимодействие.
Требуется централизованная служба управления версиями.
Когда объем транзакционных данных слишком велик, легко резко увеличить объем памяти.

1.2 Повтор транзакции

При использовании модели оптимистичных транзакций транзакции могут легко не зафиксироваться в сценариях с высоким уровнем конфликтов. Однако MySQL внутри использует пессимистическую модель транзакций и выполняет обнаружение конфликтов в процессе выполнения операторов SQL, поэтому при отправке исключений не возникает. Чтобы быть совместимым с пессимистичным поведением транзакций MySQL, TiDB предоставляет механизм повторных попыток. Эта повторная попытка является пессимистичной транзакцией.

Приведенное выше решениеБолевая точка 4, вам не нужно поддерживать код для окончательной согласованности транзакций, обрабатываемых между базами данных самостоятельно, таких как перевод от пользователя А к пользователю Б, а также ситуации между продавцами и покупателями и транзакций, когда у продавцов больше дохода. Хотя повторная попытка несколько раз все равно не удастся, эта часть обрабатывается TiDB. Если предыдущая система транзакций между базами данных имела обработку фреймворка, то нет необходимости в методе sdk, таком как sharding-jdbc, полагаться на повторную попытку программы, когда программа работает, в противном случае, если наша программа не работает, а машина повторная попытка, он исчезнет.

2. Автоматическое расширение

2.1 Разделение по регионам

Регион – это наименьшая единица хранения. Когда данные достигают определенного объема в регионе, он начинает разделяться (по умолчанию это более 1/16 объема существующего региона). Примечание: диапазон деления ключа таблицы данных должен быть установлен заранее.TiKV динамически делится в соответствии с размером региона.

вот решениеБолевая точка 2 должна обращаться за ресурсами каждый раз, больше не работают и не поддерживают перенос данных перед подключением к сети,Проблема 3. Время простоя во время миграции влияет на генерацию пользователей.

Поскольку TiDB как промежуточное ПО не несет никаких бизнес-атрибутов, такие поля, как идентификатор пользователя, нельзя использовать в качестве ключей для правил сегментирования и пользовательских алгоритмов.Использование первичных ключей является наиболее распространенным выбором. (На самом деле, я думаю, было бы лучше, если бы TiDB мог это сделать)

2.2 Добавление узлов хранения

Добавление нового узла или разделение региона может вызвать миграцию региона, которая автоматически выполняется TiDB. Больше нет необходимости взламывать код или использовать промежуточное программное обеспечение для логики подтаблиц подбазы данных и переноса данных, онлайн-упражнений и передачи всего процесса эксплуатации и обслуживания (ручной сброс).
И нет необходимости останавливать службу кода, и не нужно ждать, пока не будет выполнен новый SQL перед миграцией, это миграция данных в режиме реального времени во время работы.

вот это решеноБолезненная точка 3 — время простоя при переносе данных, болевая точка 5 — нехватка места для хранения.

3. Аварийное восстановление реплики

Каждый регион отвечает за поддержание непрерывной части данных в кластере (в среднем около 96 МБ в конфигурации по умолчанию), и каждые данные будут храниться в нескольких копиях в разных хранилищах (конфигурация по умолчанию — 3 копии), и каждая копия называется сверстником. Несколько одноранговых узлов в одном и том же регионе синхронизируют данные через протокол плота, поэтому одноранговые узлы также используются для ссылки на элементы в экземпляре плота.

Так если данных 100млн, то на диск упадет 300млн данных, хоть диск и расходуется, но надежность повышается.

Стоимость TIDB

Официально рекомендуется развернуть не менее 3 TiKV, 3 PD и 2 TiDB.
TiDB должен иметь возможность использовать большое количество потоков, PD нужен более мощный процессор, а TiKV — более мощный SSD и процессор.
На форуме увидел, что используемая память у всех 100G, а диск 2T SSD. Поскольку каждая строка данных имеет в общей сложности 3 копии, она занимает много места на диске. Следовательно, система требует больших затрат для использования набора TiDB.
Однако это требуется только для одной системы, когда в проекте несколько систем, это будет потреблять больше ресурсов. И по мере увеличения данных ресурсов будет все больше и больше.

сцены, которые будут использоваться

Когда объем данных достигает определенного уровня, необходимо уменьшить давление запросов, иначе пула соединений не хватает. Потому что по официальной рекомендации необходимо иметь 2 tidb-сервера, как минимум два PD и три tikv, а tikv должны быть твердотельными накопителями SSD. Следовательно, при такой стоимости не все проекты будут использоваться, и компания может не захотеть тратить стоимость на ее использование. В некоторых случаях, когда объем данных невелик, рекомендуется использовать mysql, а затем синхронизировать данные с TiDB после увеличения объема данных.
После того, как база данных и таблицы были разделены, если вы хотите вместо этого использовать TiDB, вы также можете объединить их, вам нужно использовать миграцию данных TiDB.
Сначала используйте его в проекте архитектурной группы компании, затем используйте его в проекте, который не является основным бизнесом, и, наконец, распространите его на основной проект.
Начальная стоимость высока, а эксперименты требуют затрат, потому что официально рекомендуемый метод развертывания требует наличия нескольких хороших машин.

Меры предосторожности и подводные камни

Рекомендуется использовать 3.0.4, 3.0.8 или 4.0.0 (сейчас 2 апреля 2020 г.), а версию 2.0 не рекомендуется, иначе возникнет проблема несовместимости обновлений, которую необходимо решить.
При добавлении узла для расширения или при разделении региона SQL одновременно выполняет вставку или обновление данных. не найти соответствующую позицию. Но будет форма повторной попытки окончательно отправить данные.
Заранее задайте правила диапазона шардирования Региона маршрутизации, иначе при импорте данных данные будут падать на одну ноду. Если ваши предыдущие данные первичного ключа были получены алгоритмом снежинки, вам необходимо самостоятельно найти максимальное и минимальное значения для расчета диапазона и вручную задать правила диапазона.
TiDB не поддерживает SELECT LOCK IN SHARE MODE. При выполнении этого оператора эффект такой же, как и без блокировки, и он не будет блокировать чтение и запись других транзакций.
Не используйте Syncer для синхронизации данных или миграции на TiDB, потому что если вы используете Syncer для синхронизации, когда база данных и таблицы разделены, это вызовет проблемы в публикации. Рекомендуется миграция данных TiDB
TiDB не может изменить тип поля

Суммировать

Фактически, с помощью вышеуказанных функций затраты на разработку, эксплуатацию и обслуживание подбазы данных и подтаблиц могут быть снижены, главным образом потому, что подбаза данных и подтаблицы должны быть перенесены, когда они достигнут определенного объема, и это часто необходимо отслеживать, достигнут ли объем миграции. Это имеет наибольшее влияние, когда вам нужно обновить код или конфигурацию и остановить бизнес. Хотя завершение подбазы данных и подтаблицы, по-видимому, решает некоторые проблемы, остается еще много последующих действий.TiDB решает вышеуказанные проблемы за нас, так что мы можем сосредоточиться на ведении бизнеса.

Добро пожаловать на внимание, статья на один шаг быстрее

Мой публичный номер: Кшитигарбха думает

Самородки: Дзидзо Кельвин

Краткая книга: Кельвин Кельвин

Моя одежда: Дзидзо Кельвинgitee.com/kelvin-cai