Эволюция технологий подбаз данных и подтаблиц и лучшие практики

Нажмите «Нулевая изобретательность» выше и выберите «Лучший публичный аккаунт».

Технические статьи доставлены в кратчайшие сроки!

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

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

• пользовательская таблица

• форма заказа

• расходомер транзакций

Возьмем, к примеру, пользователей Alipay — 800 миллионов, пользователей WeChat — 1 миллиард. Таблица заказов еще более преувеличена: например, в Meituan Takeaway ежедневно делаются десятки миллионов заказов. Общая сумма исторических заказов Taobao должна составлять десятки миллиардов или даже сотни миллиардов.Эти массивные данные далеки от часов, которые могут выдержать. Фактически, одна таблица MySQL может хранить 1 миллиард данных, но производительность в настоящее время относительно низкая.В отрасли принято, что емкость одной таблицы MySQL составляет менее 1 кВт, что является лучшим состоянием, потому что высота его индексного дерева BTREE составляет от 3 до 5.

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

1. перегородка;

2. подтаблица подбиблиотеки;

3. NoSQL/НьюSQL;

Примечание: схема слияния только подбазы данных, или только подтаблицы, или подтаблицы подтаблицы единообразно считается схемой подбиблиотеки и подтаблицы, потому что подбаза данных или подтаблица — это просто специальная подтаблица. -база данных и подтаблица. NoSQL более репрезентативен для MongoDB, например. NewSQL является более представительным для TiDB.

Why Not NoSQL/NewSQL?

Прежде всего, почему бы не выбрать третью схему NoSQL/NewSQL, я считаю, что РСУБД имеет следующие преимущества: - экологическое совершенство РСУБД - абсолютно стабильна РСУБД - транзакционные характеристики РСУБД;

Будучи новорожденным, NoSQL/NewSQL не может сравниться с СУБД, когда надежность является нашим главным критерием. РСУБД разрабатывалась десятилетиями, пока есть программное обеспечение, это лучший выбор для основного хранилища.

В настоящее время основными данными большинства компаний являются:В основном на основе хранилища РСУБД, дополненного хранилищем NoSQL/NewSQL.! В интернет-компаниях доминирует MySQL, а в государственных предприятиях и банках и других компаниях с хорошими деньгами доминирует Oracle/DB2! Какой бы потрясающей ни была реклама NoSQL/NewSQL, ее позиционирование крупными компаниями теперь является дополнением к СУБД, а не заменой ей!

Почему не раздел?

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

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

На самом деле это решение неплохое, оно экранирует детали шардирования от пользователей, даже если в условии запроса нет столбца шардирования, оно может работать нормально (только на этот раз производительность средняя). Однако его недостатки очевидны: многие ресурсы ограничены одной машиной, например, количество подключений, пропускная способность сети и т. д.! Хотя каждый раздел может храниться независимо, общая запись многораздельной таблицы является примером MySQL. В результате его возможности параллелизма очень общие и далеки от удовлетворения высоких требований к параллелизму в Интернете!

Что касается некоторых других недостатков, упомянутых в Интернете, таких как: нельзя использовать внешние ключи и не поддерживается полнотекстовое индексирование. Я не считаю это недостатком, если в проекте 21 века до сих пор используются внешние ключи и полнотекстовая индексация базы данных, мне лень жаловаться!

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

1. Данные не массивны (количество разделов ограничено, объем хранилища ограничен);

2. Требования параллелизма не высоки;

Почему подтаблица подбиблиотеки?

Последнее, что нужно представить, — это текущий общий метод обработки массивных данных в интернет-индустрии:Подбиблиотека и подтаблица.

Хотя все принимают решение для подбаз данных и подтаблиц для обработки массивных основных данных, промежуточного программного обеспечения, которое объединяет реки и озера, не существует.Автор перечисляет некоторые известные промежуточное ПО для подбаз данных и подтаблиц:

• Али TDDL, DRDS и cobar,

• sharding-jdbc сообщества открытого исходного кода (3.x переименован в sharding-sphere);

• MyCAT для организаций гражданского общества;

• 360 Атлас;

• зебра Мейтуана;

Примечание. Чжан Лян, автор sharding-jdbc, раньше работал в Dangdang, а теперь работает в JD Finance. Но авторские права на sharding-jdbc принадлежат сообществу открытого исходного кода, а не компании и не лично Чжан Ляна!

Другие компании, такие как NetEase, 58, Jingdong и другие компании, имеют промежуточное программное обеспечение собственной разработки. Словом, сражаясь друг с другом, можно сказать, что расцветают сто цветов.

Но так много промежуточного программного обеспечения подтаблиц подбаз данных можно свести к двум типам:

• КЛИЕНТСКИЙ режим;

• ПРОКСИ-режим;

Режим CLIENT представляет TDDL Али и sharding-jdbc сообщества с открытым исходным кодом (версия 3.x sharding-jdbc, то есть sharding-sphere уже поддерживает режим прокси). Архитектура выглядит следующим образом:

Модель PROXY представляет кобар Али и MyCAT НПО. Архитектура выглядит следующим образом:

Однако, будь то режим КЛИЕНТА или режим ПРОКСИ. Несколько основных шагов одинаковы:Разбор SQL, перезапись, маршрутизация, выполнение, слияние результатов.

Автор предпочитает режим КЛИЕНТ, который имеет простую архитектуру, меньшую потерю производительности и низкие затраты на эксплуатацию и обслуживание.

Затем возьмите несколько общих больших таблиц в качестве примеров, чтобы проиллюстрировать, как реализованы подбаза данных и подтаблица!

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

Вот несколько основных идей обработки для подбазы данных и подтаблицы:

1. Выберите только один столбец сегментирования для подтаблицы подбазы данных;

2. Несколько столбцов сегментирования, несколько подбаз данных и подтаблиц;

3. сегментация столбца подтаблицы базы данных + es;

---

Возьмите несколько реальных таблиц в качестве примеров, чтобы проиллюстрировать, как создавать подбиблиотеки и подтаблицы.

форма заказа

Несколько основных полей таблицы заказов обычно выглядят следующим образом:

Взяв в качестве примера систему заказов Alibaba (см. «Путь трансформации корпоративной ИТ-архитектуры: стратегическая мысль и реализация архитектуры Alibaba в Среднем Тайване»), он выбирает три столбца в качестве трех независимых столбцов сегментирования, а именно: order_id, user_id и торговец_код. user_id и Merchant_code — это идентификатор покупателя и идентификатор продавца, потому что трафик запросов покупателей и продавцов в системе заказов Али относительно велик, а запрос предъявляет высокие требования к реальному времени. Для подбазы данных и подтаблицы на основе order_id должно быть больше запросов на основе order_id.

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

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

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

---

Резервный полномасштабный ПК Резервная таблица соотношений

1. сравнение скорости: избыточная полная шкала работает быстрее, а избыточную реляционную таблицу необходимо запрашивать дважды.Даже если вводится кеш, остается еще одна дополнительная сетевая нагрузка;

2. стоимость хранения: избыточная полномасштабная таблица требует в несколько раз больше ресурсов для хранения, чем избыточная реляционная таблица;

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

Резюме: Выбор избыточной полномасштабной таблицы или индексной таблицы взаимосвязей является архитектурным компромиссом. Преимущества и недостатки этих двух вариантов очевидны. Таблица заказов Али является избыточной полномасштабной таблицей.

пользовательская таблица

Основные поля пользовательской таблицы обычно следующие:

В обычных сценариях входа пользователя вы можете войти через номер мобильного_номер, адрес электронной почты или имя пользователя. Однако некоторые API, связанные с пользователем, также содержат user_id, поэтому может потребоваться выполнить сегментирование базы данных и таблиц в соответствии с этими 4 столбцами, то есть все 4 столбца являются столбцами сегментирования.

Таблица счетов

Основные поля таблицы account обычно следующие:

API, связанный с таблицей учетных записей, обычно имеет номер account_no, поэтому account_no можно использовать в качестве столбца сегментирования.

сложный запрос

Вышеупомянутое — это все выполнения SQL со столбцом сегментирования в условии. Однако всегда есть некоторые условия запроса, которые не содержат столбца сегментирования, и в то же время мы не можем создать неограниченную избыточную базу данных и таблицы для этих запросов с небольшим объемом запросов. Так как же в этих условиях работать с SQL без сегментирования столбца? Возьмем, к примеру, sharding-jdbc, сколько существует подбаз данных и подтаблиц, необходимо одновременно маршрутизировать до скольких подбаз данных и подтаблиц для выполнения, а затем объединить результаты. Для получения подробной информации о том, как выполнять слияние, вы можете ознакомиться с серией статей автора sharding-jdbc, в которой анализируется исходный код для объяснения принципа слияния.

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

Более того, нечеткий условный запрос в этих операционных системах или фильтрация последних десяти условий. В этом случае непросто создать индекс даже для одной таблицы, не говоря уже о подбазе данных и подтаблице. Так что делать? В этот раз пригодится знаменитый elasticsearch, а именно es. Резервировать все данные подбазы данных и подтаблицы в es и передавать эти сложные запросы в es для обработки.

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

Итак, на примере таблицы заказов вся структура выглядит следующим образом:

Конкретный анализ конкретной ситуации: Лучше не использовать несколько столбцов шардинга, когда это не крайний случай, и стоимость высока. Автор пользовательской таблицы, упомянутой выше, не рекомендует ее использовать. Поскольку большой особенностью пользовательской таблицы является то, что ее верхний предел определен, даже если 7 миллиардов человек в мире - все ваши пользователи, объем данных невелик, поэтому автор рекомендует использовать один столбец сегментирования + режим es для упрощения. структура.

Краткое описание es+HBase

Необходимо заранее пояснить, что комбинация solr+HBase может чаще встречаться в сообществе.В целях соблюдения согласованности в этой статье все схемы полнотекстового индексирования выбраны как es. Что касается плюсов и минусов es+HBase и solr+HBase, или плюсов и минусов es и solr, то это не та категория, которую нужно обсуждать в этой статье, да и смысла обсуждать особо нет . es и solr — два очень хороших и сопоставимых промежуточных ПО. В последние годы es стал более популярным:

Если отбросить в сторону весь исторический багаж в процессе выбора и обсудить преимущества и недостатки только es+HBase и solr+HBase, очевидно, что последний — лучший выбор. Solr+HBase обладает высокой степенью интеграции.После введения службы индексов нас больше всего беспокоит, а также самая важная проблема согласованности индексов.Solr+HBase уже имеет очень зрелое решение одно за другим.Lily HBase Indexer.

дальнейшее чтение

HBase-версия ApsaraDB для Alibaba Cloud также использует solr для реализации полнотекстового индексирования. Заинтересованные студенты могут щелкнуть ссылку, чтобы узнать больше: https://help.aliyun.com/product/49055.html?spm=5176.124785.631202. con1.603452c0cz7bj2.

принцип es+HBase

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

Как правило, основные таблицы, которым требуются подбиблиотеки и подтаблицы, такие как таблица заказов и таблица баллов, будут иметь десятки столбцов или даже сотни столбцов (при условии, что столбцов 50), но вся таблица может реально необходимо участвовать в условной индексации. Может быть меньше 10 условий (при условии, что есть 10 столбцов). В это время данные всех полей из 50 столбцов полностью индексируются в es, что сильно нагружает es-кластер, и восстановление после сбоя es-шарда займет много времени.

В это время можно подумать о снижении нагрузки на es, чтобы ограниченные ресурсы es-кластера могли максимально сохранить наиболее ценные данные, наиболее нужные при условном поиске, то есть только те поля, которые могут участвовать в условный поиск индексируется в es, так что весь es кластер находится под давлением Уменьшается до 1/5 от исходного (50 полей в основной таблице, только 10 полей участвуют в условии), а полные данные 50 поля хранятся в HBase, что является классической схемой комбинации es+HBase, т.е.Сценарии для индексирования и изоляции хранилища данных.

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

Взаимодействие между ними, вероятно, будет таким: сначала перейти к es-запросу, чтобы получить значение rowkey, которое соответствует условиям фильтрации в соответствии с условиями, введенными пользователем, а затем использовать значение rowkey для запроса HBase, время последнего запроса Шаг можно почти не учитывать, потому что это HBase. Лучшая сцена, схема взаимодействия выглядит следующим образом:

Расширение возможностей извлечения HBase

Изображение изHBase Technology Community-HBase Application Practice Session-HBase for Solr

Суммировать

Наконец, несколько решений резюмируются следующим образом (столбец сегментирования называется sc):

-	один СБН	несколько сбн	sc+es	sc+es+HBase
Применимая сцена	Один	в общем	более обширный	очень широкий
своевременность запроса	своевременный	своевременный	более своевременно	более своевременно
вместительность	в общем	в общем	больше	массивный
стоимость кода	очень маленький	больше	в общем	в общем
архитектурная сложность	Простой	в общем	трудный	очень сложно

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

Сделав так много вещей, позже еще предстоит проделать много работы, например, согласованность синхронизации данных, и после работы в течение определенного периода времени объем данных некоторых таблиц будет постепенно достигать узкого места одной таблицы. таблица Холодная миграция данных. Одним словом, подтаблица подбазы данных представляет собой очень сложную системную инженерию. Обработка любых массивных данных — дело непростое, так что будьте готовы к бою!

END

Если вы чувствуете себя вознагражденным после прочтения, пожалуйста, подпишитесь и добавьте официальную учетную запись [Ingenuity Zero], чтобы узнать больше захватывающей истории! ! !