Приквел:
В конце 2013 года я отвечал за исследовательские заметки по дизайну промежуточного программного обеспечения базы данных, доставал их, делился ими со всеми и прослушивал их.
1. Что такое ТДДЛ
-
TDDL этоTaobao Distribute Data LАйер для краткости
-
Taobao — клиентский промежуточный продукт для работы с базами данных.
-
Судя по спецификации JDBC, сервера нет, и он существует в виде client-jar.
Голос за кадром: Существует промежуточное программное обеспечение базы данных на основе сервера и на основе клиента. TDDL принадлежит к последнему, а cobar — это служба среднего уровня, использующая протокол mysql и принадлежащая к первому.
Во-вторых, TDDL не поддерживает SQL.
-
Все виды объединений не поддерживаются
-
Многотабличный запрос не поддерживается
-
между/и не поддерживается
-
не поддерживает нет (кроме не нравится)
-
комментарий не поддерживается, то есть комментарии
-
не поддерживает обновление
-
Функция set после включения в группу не поддерживается
-
Принудительный индекс не поддерживается
-
Большинство функций, уникальных для mysql, не поддерживаются.
Голос за кадром: ПО промежуточного слоя распределенной базы данных и объединение трудно поддерживать Заявленная Cobar поддержка объединения ограничена и неэффективна.
В-третьих, какой SQL поддерживает TDDL?
-
Поддержка базового синтаксиса CURD
-
поддержка как
-
Поддержка квалификации имени таблицы, т.е. "table_name.column"
-
Поддержите лайк/не лайк
-
Лимит поддержки, то есть синтаксис подкачки mysql
-
поддержка в
-
Поддерживаются вложенные запросы.Поскольку несколько таблиц не поддерживаются, поддерживаются только вложенные запросы для одной таблицы.
Голос за кадром: промежуточное ПО для распределенной базы данных, поддерживаемый синтаксис очень ограничен, но для приложений с большими данными/высоким параллелизмом, подключенных к Интернету, этого достаточно, сервисный уровень должен делать больше.
В-четвертых, другие характеристики TDDL
-
Поддержка оракула и mysql
-
Поддержка активного/резервного динамического переключения
-
Поддерживает взвешенное разделение чтения и записи
-
Поддержка подбиблиотеки и подтаблицы
-
Поддержка генерации первичного ключа: Oracle использует последовательность для генерации, mysql необходимо создать таблицу для генерации идентификатора
-
Поддерживает транзакции с одной базой данных, но не поддерживает транзакции с базой данных quaku.
-
Поддержка многостраничных запросов к нескольким базам данных, но производительность будет снижаться при перелистывании страницы.
Голос за кадром: Как видите, TDDL не поддерживает многие вещи, так почему же он до сих пор так популярен? Основные болевые точки, которые он решает, - это «распределение», «подтаблица подбазы данных» и так далее.
После добавления промежуточного программного обеспечения для решения «распределенной» и «подтаблицы подбазы данных» функция SQL будет ограничена.Однако мы должны учитывать: ЦП и MEM MYSQL очень ценны, мы должны преобразовать MYSQL из сложных вычислений (транзакций , JOIN, самозапрос, хранимые процедуры, представления, определяемые пользователем функции,) освобождаются от выпуска, и эти вычисления переносятся на сервисный уровень.
Конечно, некоторые серверные системы или системы поддержки имеют небольшой объем данных или небольшое количество запросов, и нет необходимости в «распределении».Для упрощения бизнес-логики пишутся некоторые сложные операторы SQL и функции MYSQL.Системы такого типа не распространяются.Нельзя заставить эти системы отказаться от удобства и использовать промежуточное ПО для потенциальных пользователей промежуточного ПО баз данных.
Пять, иерархия TDDL
TDDL — это клиентский jar, и его структура разделена на три уровня:
|
уровень |
инструкция |
разное |
|
matrix |
Под ним можно понимать весь источник данных, состоящий из нескольких групп. |
|
|
group |
Его можно понимать как группу, которая состоит из нескольких атомов |
|
|
atom |
Его можно понимать как базу данных, которая может быть библиотекой для чтения или библиотекой для записи. |
В соответствии с приведенной выше легендой: уровень данных матрицы разделен на две группы, каждая группа состоит из первичных и вторичных атомов.
матричный слой
-
Ядро — это механизм правил
-
Реализовать подтаблицу подбазы данных
-
Основной путь: разбор sql => расчет механизма правил (маршрутизация) => выполнение => результаты слияния
групповой слой
-
разделение чтения-записи
-
Расчет веса
-
Переключатель предусилителя записи
-
Чтение переключателя HA
-
Динамически добавлять подчиненные (атомные) узлы
атомный слой
-
абстрагирование единой базы данных;
-
ip /port /user /passwd /connection Динамическая модификация, динамический источник данных jboss
-
количество потоков: попробуйте режим перехвата, чтобы защитить потоки бизнес-обработки
-
Динамически блокировать выполнение определенных sql
-
Статистика и лимиты времени выполнения
Весь процесс выполнения SQL
-
BEGIN(sql+args), ввод sql и параметры
-
разбор sql
-
расчет правила
-
подстановка имени таблицы
-
Выберите groupDS для выполнения sql
-
Выберите atomDS на основе весов
-
Выполнить sql в atomDS со стратегией повтора
-
Управление чтением и записью, управление параллелизмом, выполнение sql, возврат результатов
-
Объединить наборы результатов
-
END(ResultSet), выходом является набор результатов
Голос за кадром: Я чувствую, что сложность заключается в анализе SQL.
Шесть, лучшие практики TDDL
-
Максимально используйте 1 в правиле «1 ко многим» для разбиения данных (ключ доступа), например, «пользователь» — это простая и удобная в использовании широта.
-
Задача покупателя-продавца «многие ко многим», использование избыточных данных путем инкрементной репликации данных и запросов
-
Используйте избыточность структуры таблицы, чтобы уменьшить количество сетевых поездок, и как покупатели, так и продавцы сохраняют все данные
Голос за кадром: Здесь я расширяю этот сценарий использования.
Если взять в качестве примера покупателей и продавцов электронной коммерции, бизнес-сторона имеет потребности как покупателя, так и продавца, но обычно для передачи данных можно использовать только одну широту.Библиотека, как можно реализовать запросы продавца?
Как показано на рисунке выше: Запрос всех заказов и продуктов, приобретенных покупателями, может быть непосредственно связан с определенной подбазой данных, но для запроса всех продуктов, проданных продавцами, бизнес-сторона должна пройти через все базы данных покупателей, а затем выполнить запрос к набору результатов, объединенный для удовлетворения потребностей.
Так называемая «инкрементная репликация данных», «избыточность структуры таблиц» и «сокращение времени работы сети» означают, что все данные хранятся в двух избыточных копиях в двух измерениях покупателей и продавцов, как показано на следующем рисунке:
Используя механизм асинхронной очереди сообщений, данные постепенно копируются в другое измерение. При запросе продавец может напрямую найти соответствующую подбазу данных.
Этот подход имеет потенциальные проблемы с несогласованностью данных.
Продолжая с лучшими практиками tddl:
-
Использование автономных ресурсов: автономная транзакция, автономное соединение
-
модель храненияПопробуйте сделать следующее:
- Ходите как можно больше памяти
- Соберите данные, которые бизнес хочет физически запрашивать, как можно больше вместе.
- Сокращение времени работы в сети за счет избыточности данных
- Разумный параллелизм для улучшения времени отклика
- узкое место чтенияРешить, добавив раб (атом)
- написать узкое местоРешается сегментацией + маршрутизация
Голос за кадром: По сравнению с ядром ПО промежуточного слоя базы данных лучшие практики и модели хранения имеют для нас большее значение.
7. Будущее TDDL?
-
kv является самым основным компонентом всего доступа к данным
-
Делайте меньше для узлов хранения и больше для бизнес-кода
-
Чтобы повысить скорость запросов, есть только один способ работать с избыточными данными.
-
Подобно структурированному языку запросов, очень удобен для запросов
Голос за кадром: Подтекст в том, что в условиях высокой параллелизма больших данных SQL не является общей тенденцией, а отсутствие SQL и настраиваемые протоколы + хранилище являются будущим направлением?
Заметки об исследованиях в конце 2013 г., в тексте"Закадровый голос" был моей аннотацией в то время, я надеюсь, что у всех есть предварительное представление о TDDL.Если у вас есть какие-либо вопросы, добро пожаловать в общение.
Статьи по Теме:
"Заметки об исследовании промежуточного программного обеспечения базы данных》