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

Оптимизация одной таблицы

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

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

поле

использовать как можно большеTINYINT,SMALLINT,MEDIUM_INTкак целочисленный тип вместоINT, плюс, если неотрицательноUNSIGNED
VARCHARДлина выделяет только то пространство, которое действительно необходимо
Используйте enum или integer вместо строкового типа
использовать как можно большеTIMESTAMPвместоDATETIME
В одной таблице не должно быть слишком много полей, рекомендуется использовать20в пределах
избегать использованияNULLполя, которые трудно запросить оптимизацию и занимают дополнительное место в индексе
хранить в целочисленном видеIP

показатель

Чем больше индексов, тем лучше, они должны создаваться в соответствии с запросом.WHEREиORDER BYСтолбцы, задействованные в команде, индексируются и могут быть проиндексированы в соответствии сEXPLAINчтобы увидеть, используется ли индекс или полное сканирование таблицы
следует по возможности избегатьWHEREполе в предложенииNULLЦенностное суждение, в противном случае движок откажется от использования индекса и выполнит полное сканирование таблицы.
Поля с разреженным распределением значений не подходят для индексации, например поля «пол» только с двумя или тремя значениями
Символьные поля строят только префиксные индексы
Символьные поля лучше не использовать в качестве первичных ключей
Отсутствие внешних ключей, гарантированное программой
попробуй неUNIQUE, связанные программными гарантиями
При использовании индексов с несколькими столбцами следите за порядком и условиями запроса и удаляйте ненужные индексы с одним столбцом.

Запрос SQL

Вы можете найти медленный SQL, включив журнал медленных запросов.
Не выполняйте операции со столбцами:SELECT id WHERE age+1=10, любая операция со столбцом приведет к сканированию таблицы, которая включает в себя обучающие функции базы данных, выражения для расчета и т. д. При запросе переместите операцию как можно дальше вправо от знака равенства.
Оператор sql максимально прост: sql может работать только на одном процессоре; большой оператор можно разделить на маленькие операторы, чтобы сократить время блокировки; большой sql может заблокировать всю библиотеку
Не нужноSELECT *
ORпереписать какIN:ORЭффективность n уровней,INЭффективность на уровне log(n),INРекомендуется контролировать количество в пределах 200
Реализовано в приложении без функций и триггеров
избегать%xxxзапрос
бесполезныйJOIN
Используйте для сравнения один и тот же тип, например «123» и «123», 123 и 123.
попытайся избежатьWHEREиспользуется в статье!=или<>оператора, иначе движок откажется от использования индекса и выполнит полное сканирование таблицы
Для непрерывных значений используйтеBETWEENНе нужноIN:SELECT id FROM t WHERE num BETWEEN 1 AND 5
Не берите всю таблицу для данных списка, используйтеLIMITДля разбиения на страницы номер каждой страницы не должен быть слишком большим

двигатель

В настоящее время широко используетсяMyISAMиInnoDBДва двигателя:

MyISAM

Механизм MyISAM является механизмом по умолчанию для MySQL 5.1 и более ранних версий и включает:

Не поддерживает блокировки строк, блокирует все таблицы, которые необходимо прочитать, при чтении и добавляет монопольные блокировки к таблицам при записи.
Транзакции не поддерживаются
Внешние ключи не поддерживаются
Безопасное восстановление после сбоя не поддерживается
Поддерживает вставку новых записей в таблицу, когда к таблице есть запросы на чтение
служба поддержкиBLOBиTEXTИндекс первых 500 символов , поддерживает полнотекстовое индексирование
Поддерживает отложенное обновление индекса, значительно повышая производительность записи.
Для таблиц, которые не будут изменены, поддержка сжатых таблиц значительно сокращает использование дискового пространства.

InnoDB

InnoDB стал индексом по умолчанию после MySQL 5.5, и его функции:

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

Общий,MyISAMПодходит дляSELECTинтенсивный стол, в то время какInnoDBПодходит дляINSERTиUPDATEинтенсивный стол

Параметры настройки системы

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

sysbench: модульный, кроссплатформенный и многопоточный инструмент для тестирования производительности.
iibench-mysql: основанный на Java индекс MySQL/Percona/MariaDB для инструмента тестирования производительности вставки.
tpcc-mysql: инструмент тестирования TPC-C, разработанный Percona.

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

backlog: Значение невыполненной работы указывает, сколько запросов может храниться в стеке в течение короткого периода времени, прежде чем MySQL временно перестанет отвечать на новые запросы. То есть, если данные о соединении MySql достигают maxconnections, новый запрос будет храниться в стеке, чтобы дождаться соединения для освобождения ресурсов.Число стека - это невыполненная работа.Если количество ожидающих соединений превышает back_log, не будут предоставлены ресурсы соединения. Может быть увеличено с 50 до 500 по умолчанию.
wait_timeout: время простоя соединения с базой данных, бездействующие соединения будут занимать ресурсы памяти. Может быть уменьшено с 8 часов по умолчанию до получаса.
maxuserconnection: максимальное количество подключений, по умолчанию 0, верхнего предела нет, лучше установить разумный верхний предел
thread_concurrency: количество одновременных потоков, удвоенное количество ядер ЦП.
skipnameresolve: отключить разрешение DNS для внешних подключений, устраняя время разрешения DNS, но требует, чтобы все удаленные хосты были доступны по IP.
keybuffersize: размер кэша индексного блока. Увеличение скорости обработки индекса окажет наибольшее влияние на производительность таблиц MyISAM. Для памяти около 4G можно установить 256M или 384M, запросивshow status like'key_read%', лучше всего убедиться, что key_reads / key_read_requests ниже 0,1%
innodbbufferpool_size: Кэшировать блоки данных и индексные блоки, которые оказывают наибольшее влияние на производительность таблицы InnoDB. по запросуshow status like'Innodb_buffer_pool_read%', гарантировано (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests Чем выше, тем лучше
innodbadditionalmempoolsize: механизм хранения InnoDB, используемый для хранения информации словаря данных и некоторого объема памяти внутренней структуры данных, когда много объектов базы данных при соответствующих корректировках размера параметров, чтобы гарантировать, что все данные могут быть сохранены в повышении эффективности доступа к памяти, когда слишком мало времени, MySQL будет записывать информацию о предупреждении в базу данных журнала ошибок, тогда вам нужно настроить размер этого параметра
innodblogbuffer_size: буфер, используемый журналом транзакций механизма хранения InnoDB.Вообще говоря, не рекомендуется превышать 32 МБ
querycachesize: кэшировать ResultSet в MySQL, который представляет собой набор результатов выполнения инструкции SQL, поэтому его можно использовать только дляselectутверждение. Любое изменение данных в таблице приведет к тому, что все ссылки на эту таблицу будут сохранены.selectзаявление вQuery CacheНедопустимые кэшированные данные в . Итак, когда наши данные меняются очень часто, используйтеQuery CacheЭто может быть более чем стоит. Отрегулируйте в соответствии с частотой совпадений (Qcache_hits / (Qcache_hits + Qcache_inserts) * 100)), как правило, не рекомендуется делать слишком большой, 256 МБ может быть почти таким же, и большие статические данные конфигурации можно настроить соответствующим образом. командаshow status like'Qcache_%'Посмотреть текущую системуQuery Catchиспользовать размер
readbuffersize: размер буфера чтения MySql. Запрос на последовательное сканирование таблицы выделит буфер чтения, а MySql выделит для него буфер памяти. Если запрос последовательного сканирования к таблице очень частый, его производительность можно повысить, увеличив значение этой переменной и размер буфера памяти.
sortbuffersize: размер буфера, используемый MySql для выполнения сортировки. Если вы хотите увеличитьORDER BYскорость, во-первых, чтобы увидеть, можете ли вы заставить MySQL использовать индекс вместо дополнительной стадии сортировки. Если нет, попробуйте увеличить размер переменной sortbuffersize.
readrndbuffer_size: Размер произвольного буфера чтения MySql. Когда строки считываются в любом порядке (например, в порядке сортировки), выделяется буфер случайного чтения. При выполнении запроса на сортировку MySql сначала сканирует буфер, чтобы избежать поиска на диске и повысить скорость запроса.Если вам нужно отсортировать большой объем данных, вы можете соответственно увеличить значение. Однако MySql будет освобождать буферное пространство для каждого клиентского соединения, поэтому вы должны попытаться установить это значение соответствующим образом, чтобы избежать чрезмерных накладных расходов памяти.
record_buffer: Каждый поток, выполняющий последовательное сканирование, выделяет буфер этого размера для каждой сканируемой таблицы. Если вы выполняете много последовательных сканирований, вы можете увеличить это значение.
threadcachesize: сохраняет потоки, которые в настоящее время не связаны с соединениями, но готовы обслуживать новые соединения позже, что может быстро отвечать на запросы потоков на соединения без создания новых.
tablecache: похож на threadcache_size, но используется для кэширования файлов таблиц, мало влияет на InnoDB, в основном используется в MyISAM.

обновить оборудование

Масштабирование, это не так много, чтобы сказать, в зависимости от того, является ли MySQL интенсивным процессором или интенсивным вводом-выводом, производительность MySQL может быть значительно улучшена за счет увеличения ЦП и памяти и использования SSD.

разделение чтения-записи

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

тайник

Кэширование может происходить на следующих уровнях:

MySQL Internals: настройки описаны в параметрах настройки системы.
Уровень доступа к данным: например, MyBatis кэширует операторы SQL, а Hibernate может быть точен до одной записи.Кэшированные здесь объекты в основном являются постоянными объектами PersistenceObject.
Уровень службы приложений: здесь вы можете добиться более точного управления и большего количества стратегий реализации для кэша с помощью средств программирования, объект, кэшированный здесь, является объектом передачи данных DataTransferObject (DTO).
Веб-уровень: кэширование веб-страниц
Браузерный клиент: кэш на стороне клиента

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

Сквозная запись: после того, как данные записываются в базу данных, кеш одновременно обновляется для поддержания согласованности между базой данных и кешем. Именно так работают большинство современных сред кэширования приложений, таких как Spring Cache. Эта реализация очень простая, хорошая синхронизация, но средняя эффективность.
Обратная запись: когда есть данные для записи в базу данных, обновляется только кэш, а затем кэшированные данные синхронизируются с базой данных пакетами асинхронно. Эта реализация более сложная, требует большей логики приложения и может привести к рассинхронизации базы данных с кешем, но эффективность очень высока.

секционирование таблицы

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

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

Оператор SQL пользователя должен быть оптимизирован для таблицы разделов, а столбец условия раздела должен быть включен в условие SQL, чтобы запрос можно было разместить на небольшом количестве разделов, иначе будут сканироваться все разделы.EXPLAIN PARTITIONSпросмотреть статью Оператор SQL попадет на эти разделы, чтобы выполнить оптимизацию SQL, как показано на следующем рисунке, 5 записей попадают на два раздела:

Преимущества секционирования заключаются в следующем:

Одна таблица может хранить больше данных
Данные многораздельной таблицы легче поддерживать.Большой объем данных можно удалить пакетами, очистив весь раздел, или можно добавить новые разделы для поддержки вновь вставленных данных. Кроме того, независимый раздел можно оптимизировать, проверить, отремонтировать и т. д.
Некоторые запросы можно определить из условий запроса, чтобы они попадали только в несколько разделов, и скорость будет очень высокой.
Данные таблицы разделов также могут быть распределены по разным физическим устройствам, что позволяет эффективно использовать несколько аппаратных устройств.
Секционированные таблицы можно использовать, чтобы избежать некоторых особых узких мест, таких как монопольный доступ к одному индексу InnoDB, файловая система ext3. Конфликт за блокировку инода
Может создавать резервные копии и восстанавливать отдельные разделы

Ограничения и недостатки разделения:

Таблица может иметь не более 1024 разделов.
Если в поле раздела есть столбцы первичного ключа или уникального индекса, то должны быть включены все столбцы первичного ключа и столбцы уникального индекса.
Разделенная таблица не может использовать ограничения внешнего ключа
Значения NULL делают недействительной фильтрацию разделов
Все разделы должны использовать один и тот же механизм хранения

Тип перегородки:

RANGE Partitioning: назначает несколько строк разделу на основе значений столбцов, принадлежащих заданному непрерывному диапазону.
Разбиение СПИСКА: аналогично разбиению по ДИАПАЗОНУ, за исключением того, что разбиение СПИСКА выбирает на основе значения столбца, совпадающего со значением в наборе дискретных значений.
Разделение HASH: разделение, которое выбирает на основе возвращаемого значения определяемого пользователем выражения, вычисляемого с использованием значений столбцов строк, которые должны быть вставлены в таблицу. Эта функция может содержать любое допустимое в MySQL выражение, которое возвращает неотрицательное целочисленное значение.
Разбиение по ключу: Подобно разбиению по HASH, разница в том, что разделение по ключу поддерживает только вычисление одного или нескольких столбцов, а сервер MySQL предоставляет свою собственную хеш-функцию. Один или несколько столбцов должны содержать целочисленные значения.

Сценарии, подходящие для разделения:

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

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

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

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

вертикальное разделение

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

Например, исходная таблица пользователей:

После вертикального разделения это:

Преимущества вертикального разделения:

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

слабость это:

Первичный ключ является избыточным, и необходимо управлять избыточными столбцами.
Вызывает операцию JOIN присоединения к таблице (увеличение нагрузки на ЦП) может снизить нагрузку на базу данных за счет присоединения на бизнес-сервере.
Еще есть проблема, что объем данных в одной таблице слишком велик (требуется горизонтальное разбиение)
Комплексная обработка транзакций

разделить по горизонтали

Обзор

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

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

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

На практике часто используется комбинация вертикального и горизонтального разделения, то есть Users_A_M и Users_N_Z разбиваются на Users и UserExtras, поэтому всего имеется четыре таблицы.

Преимущества горизонтального разделения:

Нет узких мест в производительности больших данных одной базы данных и высокого параллелизма.
Меньше изменений на стороне приложения
Улучшена стабильность системы и грузоподъемность.

слабость это:

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

Принцип фрагментации

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

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

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

решение

Из-за сложной логики, связанной с горизонтальным разделением, в настоящее время существует множество зрелых решений. Эти схемы делятся на две большие категории:

Клиентская архитектура
Архитектура агентства

Клиентская архитектура

Путем изменения уровня доступа к данным, такого как JDBC, источник данных и MyBatis, несколько источников данных управляются посредством конфигурации, напрямую подключенной к базе данных, а интеграция фрагментации данных выполняется в модуле, который обычно представлен в виде Баночный пакет.

Вот пример клиентской архитектуры:

Видно, что реализация фрагментации идет вместе с сервером приложений, что достигается модификацией слоя Spring JDBC.

Преимущества клиентской архитектуры:

Приложение напрямую подключено к базе данных, чтобы снизить риск простоя, вызванного зависимостью периферийных систем.
Низкая стоимость интеграции и отсутствие дополнительных компонентов O&M

слабость это:

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

Архитектура агентства

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

Вот пример архитектуры прокси:

Чтобы перенаправить трафик и предотвратить появление отдельных точек, прокси-компоненты обычно существуют в виде кластеров, и для управления ими могут потребоваться сервисные компоненты, такие как Zookeeper.

Преимущества прокси-архитектуры:

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

слабость это:

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

Сравнение каждого плана

Рамка	Режиссер	Модель архитектуры	База данных поддержки	Филиальная библиотека	подтаблица	разделение чтения-записи	внешние зависимости	Это с открытым исходным кодом	язык реализации	Поддерживаемые языки	Звезды GitHub
MySQL Fabric	Официальный MySQL	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	да	python	неограниченный	35
Cobar	Алибаба	Архитектура агентства	MySQL	имеют	никто	никто	никто	да	Java	неограниченный	1287
Cobar Client	Алибаба	Клиентская архитектура	MySQL	имеют	никто	никто	никто	да	Java	Java	344
TDDL	Таобао	Клиентская архитектура	неограниченный	имеют	имеют	имеют	Diamond	Только часть с открытым исходным кодом	Java	Java	519
Atlas	Киху 360	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	да	C	неограниченный	1941
Heisenberg	Медведь Байду Фото	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	да	Java	неограниченный	197
TribeDB	личный	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	да	NodeJS	неограниченный	126
Sharding JDBC	Данданг	Клиентская архитектура	MySQL	имеют	имеют	имеют	никто	да	Java	Java	1144
Shark	личный	Клиентская архитектура	MySQL	имеют	имеют	никто	никто	да	Java	Java	84
KingShard	личный	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	да	Golang	неограниченный	1836
OneProxy	гражданское программное обеспечение	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	нет	неизвестный	неограниченный	неизвестный
MyCat	Сообщество	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	да	Java	неограниченный	1270
Vitess	Youtube	Архитектура агентства	MySQL	имеют	имеют	имеют	никто	да	Golang	неограниченный	3636
Mixer	личный	Архитектура агентства	MySQL	имеют	имеют	никто	никто	да	Golang	неограниченный	472
JetPants	Tumblr	Клиентская архитектура	MySQL	имеют	имеют	никто	никто	да	Ruby	Ruby	957
HibernateShard	Hibernate	Клиентская архитектура	неограниченный	имеют	имеют	никто	никто	да	Java	Java	57
MybatisShard	MakerSoft	Клиентская архитектура	неограниченный	имеют	имеют	никто	никто	да	Java	Java	119
Gizzard	Twitter	Архитектура агентства	неограниченный	имеют	имеют	никто	никто	да	Java	неограниченный	2087

С таким количеством вариантов, как выбрать? Можно рассмотреть следующие идеи:

Определите, следует ли использовать прокси-сервер или архитектуру на стороне клиента. Малые и средние или относительно простые сценарии, как правило, выбирают клиентскую архитектуру, сложные сценарии или крупномасштабные системы, как правило, выбирают прокси-архитектуру.
Соблюдаются ли конкретные функции, такие как необходимость пересечения узловORDER BY, то приоритет, поддерживающий эту функцию
Не считайте продукты, которые не обновлялись в течение года, указывая на то, что развитие находится в застое, даже без сопровождения и технической поддержки.
Лучше всего выбирать производителя в порядке крупная компания -> сообщество -> маленькая компания -> индивидуальное лицо.
Выберите хорошую репутацию, такую как звезды GitHub, количество и качество пользователей и отзывы пользователей.
Открытый исходный код является приоритетом, часто у проекта есть особые потребности и может потребоваться изменение исходного кода.

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

Архитектура клиента: ShardingJDBC
Прокси-архитектура: MyCat или Atlas

MySQL-совместимая и горизонтально масштабируемая база данных

Есть также несколько баз данных с открытым исходным кодом, совместимых с протоколом MySQL, например:

TiDB
Cubrid

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

Облако Alibaba PetaData
Alibaba Cloud OceanBase
Облачная DCDB Tencent

NoSQL

Шардинг на MySQL — это танец в кандалах, ведь многие большие таблицы сами по себе не подходят для MySQL. Спрос на СУБД невелик и не требует ACID.Вы можете рассмотреть возможность миграции этих таблиц на NoSQL, чтобы полностью решить проблему горизонтального масштабирования, например:

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