Десять вопросов о TiDB: некоторые мысли о проектировании архитектуры

Автор: Хуан Дунсюй

«Я надеюсь, что смогу лучше донести до всех некоторые концепции дизайна TiDB. Я верю, что после того, как все поймут причины этого, они смогут лучше использовать TiDB».

Происхождение TiDB началось с размышлений над вопросом: почему в области баз данных так много ям, которых невозможно избежать? С тех пор, как мы написали первую строку кода в 2015 году, за последние три года мы столкнулись с бесчисленным количеством проблем, думая и делая, пытаясь работать быстро с наименьшими затратами.

Как проект с открытым исходным кодом, TiDB является результатом совместных усилий наших инженеров по инфраструктуре и сообщества.TiDB был выпущен до версии 2.0 и имеет относительно стабильную форму, и большое количество партнеров используют его в производственной среде. Можно ответственно сказать, что любое решение, которое мы принимаем, было тщательно обдумано и отработано на практике, и является результатом внутренних и общественных обсуждений. Возможно, это не лучший вариант, но он должен быть наиболее подходящим для нас на данном этапе, и вы также можете видеть, что TiDB быстро развивается.

Эта статья посвящена ТОП-10 «почему» TiDB. Я надеюсь, что после понимания нашего выбора вы сможете более эффективно использовать TiDB и сделать его более ценным в подходящей среде.

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

1. Почему распределенные системы не панацея

На самом деле ни одна технология не совершенна и не излечивает все болезни, особенно в области хранения.Если ваши данные могут быть установлены в MySQL и нагрузка на сервер не высока, или требования к производительности сложных запросов не высоки, в на самом деле, распределенные базы данных не являются особенно хорошим выбором. Выбор распределенной архитектуры означает дополнительные затраты на обслуживание, и эти затраты нерентабельны для очень малого бизнеса.Даже если вы говорите, что требуется высокая доступность, решение репликации master-slave MySQL + GTID может быть в принципе достаточно.Если это недостаточно, есть также недавно введенная групповая репликация. И сообщество MySQL достаточно велико, чтобы вы могли найти ответы практически на любой распространенный вопрос.

Наше первоначальное намерение при создании TiDB состояло не в том, чтобы заменить MySQL небольшим объемом данных, а в том, чтобы попытаться решить некоторые важные проблемы, которые невозможно решить на основе базы данных на одной машине.

Многие друзья спрашивают меня, какое время подходит для выбора распределенной базы данных? Я думаю, что это индивидуально для каждой компании или каждого бизнеса, я не хочу давать универсальный стандарт для всех (возможно, этого стандарта не существует), но есть некоторые события, которые начинают появляться: например, когда вы вы обнаружите, что ваша база данных прибыла, вы начинаете каждый день ломать голову над резервным копированием данных, миграцией и расширением, и начинаете думать об оптимизации пространства хранения и сложных медленных запросах каждый день, или когда вы начинаете неосознанно исследовать промежуточное программное обеспечение базы данных, или когда человеческая плоть находится в коде При выполнении сегментирования напомните себе в это время, чтобы увидеть, может ли TiDB помочь вам Я считаю, что это должно быть возможно в большинстве случаев.

С другой стороны, выбор TiDB и выбор MySQL не являются универсальными процессами.Чтобы позволить пользователям MySQL максимально снизить стоимость миграции и преобразования, мы создали множество инструментов, позволяющих весь перенос данных и оттенки серого.Выход в Интернет становится гладким, даже без проблем мигрируйте обратно с TiDB, и вы все еще можете продолжать использовать MySQL для некоторых предприятий с небольшим объемом данных.Итак, в начале, если ваш бизнес и объем данных еще невелики, смело используйте MySQL.MySQL по-прежнему хорош, и TiDB ждет вас в будущем.

2. Почему MySQL

Как упоминалось выше, дело не в том, что MySQL плох и мы должны заменить его, но выбор экосистемы, совместимой с MySQL, является для нас наиболее близким выбором к реальному пользовательскому сценарию:

1. Сообщество MySQL достаточно велико и имеет особенно хорошую массовую базу.В качестве новой базы данных, если пользователям необходимо изучить новый набор грамматики, сопровождаемый тяжелой бизнес-миграцией, это очень неблагоприятно для холодного старта новых проектов.

2. MySQL накопил большое количество тестовых случаев за долгое время, и тестовые примеры различных сторонних фреймворков и инструментов, опирающихся на MySQL, являются для нас очень важным ресурсом тестирования, особенно в первые дни, как вы докажете, что ваша база данных правильно, MySQL's Testing - наша линейка.

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

С другой стороны, с тех пор, как MySQL была приобретена Oracle, в последние годы как производительность, так и стабильность неуклонно улучшались, и даже в некоторых сценариях у нее появилась возможность заменить Oracle.С точки зрения основной тенденции развития, очень здорово, поэтому рост вместе с этим здоровым сообществом также является для нас бизнес-стратегией.

3. Почему уровень SQL и уровень хранения разделены в конструкции TiDB?

Очевидной причиной является простота эксплуатации и обслуживания. Многие люди считают это место немного нелогичным: не усложнит ли развертывание еще один компонент?

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

Другая более глубокая причина — стоимость. Хранилище и SQL зависят от разных вычислительных ресурсов. Хранилище зависит от операций ввода-вывода, а для вычислений требуется более высокая производительность ЦП и памяти. Нет необходимости настраивать диски, такие как PCIe/NVMe/Optane, и они не обязательно эквивалентны. вместе это не способствует планированию ресурсов. Для TiDB целью является поддержка HTAP, то есть OLTP и OLAP должны выполняться в рамках одной системы. Очевидно, что разные рабочие нагрузки имеют разные требования к физическим ресурсам даже для уровня SQL.Запросы OLAP больше относятся к типу предпочтения пропускной способности и длинным запросам, и некоторые запросы будут занимать много памяти, в то время как OLTP предназначен для коротких, плоских и быстрых запросов. и OPS (операций в секунду), уровень SQL в TiDB не имеет состояния, поэтому вы можете направлять разные рабочие нагрузки на разные физические ресурсы для достижения изоляции.В том же предложении он дружелюбен к планировщику, и обновление периода планирования не требует обновления всего кластера.

С другой стороны, базовое хранилище использует KV для абстрагирования данных и является более гибким вариантом.

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

С точки зрения разработки гибкость, вызванная этим разделением, также отражается в возможности выбирать разные языки программирования для разработки. Для слоя вычислений без состояния мы выбираем язык с высокой эффективностью разработки, такой как Go, а для проекта уровня хранения TiKV он ближе к нижнему слою системы и более чувствителен к производительности, поэтому выбираем Rust, если все Компоненты Трудно выполнять такую ​​многоязыковую разработку по запросу, если они все связаны вместе.Для команды разработчиков профессиональные люди также могут заниматься профессиональными делами, а разработчики механизмов хранения и разработчики оптимизаторов SQL могут разрабатывать параллельно. Кроме того, для распределенных систем почти все коммуникации осуществляются по протоколу RPC, поэтому более явное многоуровневое распределение является естественным и недорогим выбором.

В-четвертых, почему бы не повторно использовать слой SQL MySQL, а переписать его самостоятельно.

В этом мы очень отличаемся от многих наших друзей. Многие существующие решения, такие как Aurora, основаны непосредственно на исходном коде MySQL, сохраняют слой SQL и реализуют расширение путем замены механизма хранения ниже.Это решение имеет несколько преимуществ: бремя разработки в начале, а во-вторых, он действительно может достичь 100% совместимости с приложениями MySQL для пользователей.

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

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

5. Зачем использовать RocksDB и Etcd Raft

У многих инженеров есть сердце для создания колес (игрушек), и у нас тоже, но создание продукта промышленного уровня - это совершенно другое.В текущей среде для создания новой базы данных можно приблизительно выбрать базовую структуру данных Всего два: 1. B+Tree, 2. LSM-Tree.

Но для B+Tree каждая запись должна производить запись на диск как минимум дважды: 1. В журнал 2. При сбросе грязных страниц, даже если ваша запись может изменить только один байт, этот байт также увеличит запись на одну страницу. (размер страницы InnoDB по умолчанию в MySQL составляет 16 КБ.) Хотя LSM-дерево также имеет проблему расширения записи, преимущество заключается в том, что LSM-дерево превращает все случайные записи в последовательные записи (соответствующее B +дерево может не быть непрерывным между страницы при сбросе грязных страниц). С другой стороны, LSMTree более дружелюбен к сжатию, а формат хранения данных намного компактнее, чем B+Tree. Facebook опубликовал несколько статей о MyRocks, сравнивая их MySQL с InnoDB и MyRocks (механизм хранения MySQL от Facebook, основанный на RocksDB). пространства. Так что LSM-Tree — наш выбор.

Отправной точкой выбора RocksDB является то, что за RocksDB стоит большое и активное сообщество, в то же время RocksDB имеет масштабное приложение в Facebook, а интерфейс RocksDB достаточно общий, и по сравнению с оригинальным LevelDB, он предоставляет множество параметров, которые можно целенаправленно регулировать. С углублением понимания и использования RocksDB мы стали одним из крупнейших пользователей и участников в сообществе RocksDB. Кроме того, по мере увеличения числа пользователей RocksDB проект будет становиться все лучше и лучше. Чем стабильнее он , видно, что многие улучшения, основанные на LSM-Tree в академическом мире, разрабатываются на основе RocksDB.Другие производители оборудования, особенно производители устройств хранения, будут оптимизировать для конкретных механизмов хранения, и RocksDB также является одним из их первых вариантов.

И наоборот, преимущества и проблемы самостоятельной разработки движка хранения одинаково очевидны: во-первых, цикл от разработки до продукта будет очень долгим, а обеспечение стабильности и качества промышленного уровня — дело непростое, требующее большого количества рабочей силы и материальные ресурсы. Преимущество заключается в том, что вы можете настроить дизайн и оптимизацию для своей рабочей нагрузки.Из-за естественной горизонтальной масштабируемости распределенных систем ограниченное повышение производительности одной машины незначительно по сравнению с пропускной способностью всего кластера, и выделяется ограниченное количество энергии. к высокой доступности и масштабируемости — более экономичный вариант. С другой стороны, как LSM-Tree, RocksDB намного проще в реализации, чем B+Tree промышленного уровня (для сравнения обратитесь к InnoDB), и это также лучший выбор с точки зрения простоты понимания и обслуживания. Конечно, по мере того, как наше понимание хранилища становится все глубже и глубже, мы обнаруживаем, что многие оптимизации, специфичные для базы данных, трудно реализовать в RocksDB.В настоящее время нам необходимо перепроектировать новый специализированный движок, точно так же, как процессор может также выполнять обработку изображений, но Гораздо меньше, чем графические процессоры, и графические процессоры не так хороши, как выделенные TPU для машинного обучения.

Причины выбора Etcd Raft аналогичны. Давайте поговорим о том, почему именно Raft: когда начинался проект TiDB, у нас действительно была путаница между MultiPaxos и Raft, и тогда мы пришли к выводу, что выбрали Raft. Общая реализация алгоритма Рафта более инженерная.Из статьи видно, что в статье описана даже структура RPC.Этот алгоритм очень удобен для промышленной реализации, и в то время в отрасли уже были алгоритм, проверенный большим количеством пользователей.Реализация Etcd с открытым исходным кодом называется Etcd. И что делает Etcd более привлекательным для нас, так это его отношение к тестированию.Etcd очень хорошо абстрагирует все интерфейсы конечного автомата, которые в принципе можно отделить от API операционной системы, что значительно снижает сложность написания юнит-тестов, и при В то же время многие точки подключения предназначены для выполнения таких операций, как внедрение ошибок, и видно, что разработчик придает большое значение тестированию.

Вместо того, чтобы повторно внедрять Raft самостоятельно, используйте сообщество, чтобы расти вместе. Теперь мы также активно участвуем в сообществе Etcd. Некоторые основные функции, такие как Learner и другие новые функции, разработаны и добавлены в Etcd нами. В то же время мы постоянно исправляем ошибки для Etcd.

Основная причина неполного повторного использования Etcd заключается в том, что язык разработки нашего механизма хранения использует Rust, а Etcd написан на Go.Одна из работ, которые нам нужно сделать, это переписать их Raft на языке Rust.Для этого мы первый шаг — пересадить юнит-тесты и интеграционные тесты Etcd (да, это тоже очень важная причина выбора Etcd, в качестве референса есть набор тестов), чтобы не разрушить корректность процесса пересадки. С другой стороны, как упоминалось выше, в отличие от Etcd, TiKV Raft использует модель Multi-Raft.В одном кластере будет большое количество независимых групп Raft.Настоящая сложность заключается в том, как обеспечить безопасность и динамическое разделение, перемещение и слияние. несколько групп Raft, я в своемэта статьяПроцесс описан внутри.

6. Почему существуют такие требования к конфигурации оборудования?

На самом деле у нас очень высокие требования к аппаратному обеспечению производственной среды.Для узлов хранения как раз требуются SSD или NVMe или Optane.Кроме того,требования к использованию ЦП и памяти тоже очень высокие.В то же время , для крупномасштабных кластеров сеть также будет иметь некоторые требования (см. нашу официальную документацию для рекомендуемой конфигурацииСвязанные главы), одной из важных причин является то, что мы выбрали реализацию RocksDB в самом низу.Для LSM Tree из-за естественных характеристик амплификации записи спрос на пропускную способность диска будет соответственно выше, тем более у RocksDB аналогичная параллельная Compression и т.д. , характеристика. Кроме того, конфигурация большинства механических дисков имеет тенденцию размещать диски большей емкости на одной машине (по сравнению с SSD), но соответствующая память обычно не больше, например, механический диск 24T + память 64G, дисковое хранилище. Объем данных кажется Чтобы быть больше, но большое количество случайных чтений будет преобразовано в чтение с диска.В настоящее время механические диски склонны к узким местам ввода-вывода.С другой стороны, они не очень удобны для аварийного восстановления и миграции данных.

Кроме того, различные компоненты TiDB в настоящее время используют gRPC в качестве фреймворка RPC, а gRPC является зависимостью.HTTP2В качестве базового протокола будут некоторые дополнительные накладные расходы ЦП по сравнению со многими простыми реализациями RPC. То, как TiKV использует RocksDB внутри, будет сопровождаться большим количеством сканирований префиксов, что означает большое количество бинарных поисков и сравнений строк, Это также сильно отличается от многих традиционных автономных хранилищ данных, которые будут интенсивно использовать ЦП. операция. Что касается уровня SQL в TiDB, то SQL — это приложение, требующее больших вычислительных ресурсов, и само собой разумеется, что оно также имеет определенные требования к памяти. Поскольку SQL TiDB является полной реализацией SQL, его выразительность и многие промежуточные программы не одного порядка.Некоторые операторы, такие как Hashjoin, будут открывать большой объем памяти для выполнения соединения, поэтому, если ваша логика запроса сравнивает Complex, или когда подтаблица соединения относительно велика (частичный бизнес-анализ OLAP в реальном времени), потребность в памяти также относительно высока.Мы не похожи на оптимизатор автономной базы данных.Например, если заказ не храниться в памяти, он выродится в На диске, наша философия заключается в использовании как можно большего объема памяти. Если аппаратных ресурсов недостаточно, своевременно уведомите пользователя отказом от выполнения и отказом, ведь иногда полумертвая система бывает еще страшнее.

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

7. Зачем использовать стратегию сегментирования на основе диапазона, а не на основе хэша

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

• После динамического добавления узлов необходимо учитывать перераспределение данных, и здесь необходимо выполнить динамическую миграцию данных;

• Статическое сегментирование не подходит для планирования в реальном времени в соответствии с рабочей нагрузкой.Например, если есть точки доступа к данным, система должна иметь возможность быстро переносить данные, чтобы точки доступа можно было распределить между различными поставщиками физических услуг.

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

Кроме того, существует горячая проблема, связанная с частым чтением и записью небольших таблиц. Причина этого в том, что на нижнем уровне наименьшая единица планирования данных в TiDB — это регион, то есть сегмент пар ключ-значение, отсортированный в порядке байтов (размер по умолчанию — 96 Мб). , общий размер даже 96M. Нет, доступ все еще очень частый.Согласно текущему механизму, если ручной Split не принудительно, независимо от того, где система планирования планирует этот кусок данных, горячие точки появятся в новом месте, поэтому эта проблема практически неразрешима. Поэтому при наличии аналогичного паттерна доступа рекомендуется общую маленькую таблицу помещать в кеш памяти типа Redis, насколько это возможно, или даже напрямую в память бизнес-сервиса (маленького и так).

8. Почему производительность (латентность) — не единственный критерий оценки

Многие друзья спрашивали меня, может ли TiDB заменить Redis? Я могу понять всеобщую любовь к Redis и TiDB, но, к сожалению, TiDB не является службой кэширования, она поддерживает строго согласованные транзакции между строками и реализует постоянное хранилище на энергонезависимых устройствах, за что приходится платить.

Короче говоря, накладные расходы ввода-вывода на запись на диск (WAL, постоянство), высокая доступность множественных копий и гарантированно распределенные транзакции неизбежно принесут в жертву задержку, не говоря уже о синхронизации между центрами обработки данных. очень низкая задержка (уровень менее миллисекунды) должна быть кэширована на стороне бизнеса. Позиционирование TiDB заключается в предоставлении масштабируемого источника правды для бизнеса.Даже если кеш бизнес-уровня выйдет из строя, все еще есть место, где могут быть предоставлены строго согласованные данные, и бизнесу не нужно заботиться о проблемах с емкостью. . **С другой стороны, более значимым показателем для измерения распределенной системы является пропускная способность. Я упоминал об этом моменте во многих статьях. Чтобы улучшить параллелизм, если пропускная способность системы может увеличиваться линейно с количеством задержка имеет смысл только в том случае, если она стабильна, и только в этом случае могут быть бесконечные возможности для улучшения. ** В реальной среде некоторые пользователи в одном кластере TiDB использовали миллионы запросов в секунду, что практически невозможно достичь в архитектуре с одним компьютером. Кроме того, в последние годы развитие аппаратного обеспечения было очень быстрым, особенно инновации, связанные с вводом-выводом, такие как популярность твердотельных накопителей NVMe, и новые носители данных, такие как энергонезависимая память, которая только что была коммерциализирована. Много раз мы ломаем голову на программном уровне или даже жертвуем элегантностью кода в обмен на небольшой прирост производительности, очень вероятно, что смена диска может принести двойное улучшение.

В нашей компании есть поговорка: сделайте это правильно, прежде чем сделать это быстро. Позиция корректности и надежности стоит выше производительности, ведь говорить о производительности на нестабильной системе бессмысленно.

9. Почему эластичное масштабирование так важно?

На ранней стадии бизнеса, когда объем данных невелик, а бизнес-трафик и нагрузка невелики, практически любая база данных может быть обработана, но во многих случаях нельзя ожидать взрывного роста бизнеса, особенно некоторые приложения на стороне ToC. Ранние пользователи Твиттера, должно быть, ненавидели случайных крупных китов (сервис недоступен). Недавно появилось приложение Zuji, которое стало популярным на какое-то время за последние два года. За короткий период времени объем бизнеса объем данных резко увеличился, и база данных почти во всех этих случаях является основным узким местом. Многие интернет-базы баз данных и молодые архитекторы недооценивают скрытые затраты на рефакторинг бизнес-кода, и очень важно быстро получить функции и требования на ранних стадиях бизнеса. Представьте, что бизнес быстро растет, а сервер каждый день перестает обслуживать из-за перегрузки базы данных.Администратор базы данных говорит вам, что нет возможности сделать это.Сначала пусть перепишете свой бизнес в виде базы данных и таблицы, и добавить ключи сегментирования повсюду в коде.Отказ от всех многомерных ассоциативных запросов, не связанных с сегментированием, и связанных с ними строго согласованных транзакций между сегментами, а затем копирование нескольких копий данных... В настоящее время реальное время равняется деньгам, и это заключается не в том, чтобы писать бизнес-код и функциональный код при принятии решения о жизни и смерти этой компании. На самом деле очень плохо быть вынужденным проводить рефакторинг из-за ограничений инфраструктуры. Если на данный момент есть план, позволяющий линейно расширять пропускную способность базы данных без модификации бизнес-кода практически без затрат (безмозглые плюс машины на самом деле самые дешевые), самое главное — стремиться к развитию бизнеса. Я считаю, что этот выбор совсем не сложен.

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

Недавно я был впечатлен и горжусь двумя примерами пользователей. Один из них — Mobike, а другой — Zhuanzhuan. Первый из них является одним из первых пользователей TiDB, и они сами начали использовать его, когда данные быстро росли. TiDB, в процессе быстрое развитие, не потерял свою цепочку из-за проблем с базой данных; последняя является типичной быстрорастущей интернет-компанией, компанией All-in TiDB, этот ранний выбор технологии значительно освободил производительность развития бизнеса, так что бизнес может писать бизнес кодируйте более свободно, вместо того, чтобы зацикливаться на бесконечном выборе ключей сегментирования, разделении чтения-записи и т. д., чтобы конкурировать с базой данных.

Предоставление более гибких, удобных и недорогих интеллектуальных базовых услуг хранения для развития бизнеса является нашей отправной точкой и точкой опоры для TiDB Распределенные / высокодоступные / удобные и гибкие программные интерфейсы / интеллектуальные и беззаботные, эти общие направления также соответствуют Будущие основные технологические тенденции. Для таких менеджеров, как генеральные директора, технические директора и архитекторы, решая насущные проблемы, следовать большому техническому направлению, не закапывать ямы для будущего изменчивого бизнеса и развивать компанию как можно быстрее, это основной вопрос мышления.

10. Как ссылаться на варианты использования в отрасли в соответствии с вашей реальной ситуацией

TiDB — это база данных общего назначения, и она даже надеется стать более универсальной, чем обычные базы данных. TiDB — это продукт базы данных, который долгое время пытался интегрировать границы между OLTP и OLAP. HTAP из лабораторий и бумаг в реальность. Одна из проблем, с которыми сталкивается такое базовое программное обеспечение общего назначения, заключается в том, что нам трудно направлять пользователей в вертикальных отраслях, чтобы они хорошо использовали TiDB в первые дни, В конце концов, каждая область имеет свои собственные сценарии использования и характеристики. команды разработчиков TiDB из интернет-индустрии, поэтому мы, естественно, лучше знакомы с архитектурой и сценариями в интернет-сфере, но мы не являемся экспертами в таких отраслях, как финансы, игры, электронная коммерция и традиционное производство, но сейчас уже есть много отраслевых экспертов и разработчиков, которые могут хорошо использовать TiDB в своих областях.

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