Недавно студия запустила проект Из-за проблемы спроса дизайн базы данных стал приближаться к системе электронной коммерции среднего размера. Также воспользуйтесь этой возможностью, чтобы узнать о стратегиях оптимизации баз данных.
Оригинальный адрес:blog.CSDN.net/color u юго-восток/…
Стратегия оптимизации базы данных
С популяризацией Интернета и развитием индустрии электронной коммерции большая платформа электронной коммерции вызовет огромную нагрузку на базу данных. Чтобы поддерживать стабильность и масштабируемость системы, а также повысить производительность веб-сайта за счет сегментации данных, предпочтительным методом для архитекторов стало горизонтальное масштабирование уровня данных.
-
水平切分数据库: это может снизить нагрузку на одну машину и свести к минимуму потери, вызванные простоем. -
负载均衡策略: это может снизить нагрузку на доступ к одной машине и уменьшить вероятность простоя. -
集群方案: Решена проблема, связанная с невозможностью доступа к одноточечной базе данных из-за простоя базы данных. -
读写分离策略: максимизирует объем доступа и параллелизма чтения данных в приложении.
Фундаментальный
сегментация данных
数据切分(шардинг) да水平扩展(Scale Out или горизонтальное расширение).
Основная цель шардинга
Преодолейте ограничение возможностей ввода-вывода одноузлового сервера базы данных и решите проблему масштабируемости базы данных.
Стратегия реализации шардинга
Реализация Sharding заключается в горизонтальном разделении данных на разные базы данных или таблицы с помощью ряда стратегий сегментации. В процессе запроса с помощью определенной стратегии маршрутизации найдите конкретную базу данных или таблицу, которую необходимо запросить, и выполните операцию запроса.
Например:
собиралисьarticleстол разделен,articleЕсть два основных поля,article_idа такжеuser_id. Мы можем принять следующую стратегию сегментации:user_idДанные с 1 по 10000 записываются в DB1, данные с 10001 по 20000 записываются в DB2 и т. д. Это сегментация базы данных.
Конечно, мы меняем стратегию нарезки, т.е. от заданногоuser_idДля запроса конкретных записей этот процесс называетсяDB路由.
Как разделить данные
Сегментация данных может быть物理上, то есть ряд стратегий сегментации выполняется для данных и распределяется по разным серверам БД.DB路由Правила обращаются к соответствующей базе данных. Это снижает давление нагрузки на одну машину.
Сегментация данных также может быть数据库内, выполнить серию стратегий сегментации данных и распределить данные по разным таблицам в базе данных, напримерarticleразделен наarticle_001,article_002, несколько подтаблиц объединяются по горизонтали, образуя логически законченныйarticleТаблица, цель этого на самом деле очень проста. Например, такие какarticleВ таблице 5000w фрагментов данных. В это время нам нужно добавить (вставить) новый фрагмент данных в эту таблицу. После завершения вставки база данных переиндексирует эту таблицу. Системные накладные расходы на индексирование 5000w строк данных не могут быть проигнорированы. Но, наоборот, если мы разделим эту таблицу на 100 таблиц, изarticle_001до того какarticle_100, 5000w строк данных усредняются, в каждой подтаблице всего 500000 строк данных.В это время, когда мы вставляем данные в таблицу только с 50w строками данных, время построения индекса уменьшится на порядок величины, которая значительно улучшена.Эффективность выполнения БД увеличивает параллелизм БД. Конечно, преимущества разбиения таблиц неизвестны, но есть и много очевидных преимуществ, таких как операции блокировки, такие как операции записи.
Видно, что:Подбиблиотеки снижают нагрузку на одноточечные машины, подтаблицы повышают эффективность операций с данными..
Далее кратко разберемся с методами и правилами подбиблиотеки:
по-прежнему использовать предыдущийarticleпример таблицы
-
Раздел сегмента номера
user_id1~1000 в DB1, 1001~2000 в DB2 и т. д.- Преимущества: Возможна частичная миграция
- Недостаток: неравномерное распределение данных
-
хеш по модулю раздела
правильно
user_idХэш, а затем используйте число, соответствующее конкретной БД. Например, если есть 4 базы данных, это будетuser_id%4, результат равен 0 для DB1, результат равен 1 для DB2 и так далее. Это обеспечивает равномерное распределение данных.- Плюсы: равномерно распределенные данные
- Недостатки: миграция данных проблематична, данные не распределяются по производительности машины
-
Сохраните конфигурацию базы данных в репозитории аутентификации
Это создание базы данных, которая отдельно сохраняет отношение сопоставления между user_id и базой данных.Каждый раз, когда вы обращаетесь к базе данных, вы должны сначала запросить базу данных, чтобы получить конкретную информацию о базе данных, а затем вы можете выполнить необходимые нам операции запроса.
- Плюсы: Гибкость, индивидуальные отношения
- Недостатки: Перед каждым запросом требуется еще один запрос, и производительность сильно снижается.
Схема распределенных данных
-
Предоставляет правила базы данных и правила маршрутизации (RouteRule для краткости RR)
-
Внедрить концепцию кластера (группы) для обеспечения высокой доступности данных
-
Внедрить политику балансировки нагрузки (LoadBalancePolicy для краткости LB).
-
Внедрить механизм обнаружения доступности узлов кластера для периодического определения доступности одноточечных машин, чтобы обеспечить правильную реализацию стратегии LB и обеспечить высокую стабильность системы.
-
Внедрите разделение чтения/записи, чтобы повысить скорость запросов данных.
кластер
Только дизайн уровня данных подбазы данных и подтаблицы не идеален.Когда мы принимаем схему сегментации базы данных, то есть есть N машин для формирования полной БД. Если одна машина выйдет из строя, только одна n часть данных БД будет недоступна. Это приемлемо для нас. По крайней мере, это намного лучше, чем ситуация до разделения. Дело не в том, что вся БД не может быть доступна. .
В общих приложениях недоступность данных, вызванная таким сбоем машины, допустима Предположим, наша система представляет собой веб-сайт электронной коммерции с высокой степенью параллелизма? Экономические потери, вызванные простоем одноузловой машины, очень серьезны. То есть с нашим решением все еще есть проблемы, а отказоустойчивость не выдерживает проверки.
Проблемы всегда имеют решения. мы представляем集群понятие, которое я называю здесьGroup, это,Для каждого узла подбазы данных мы вводим несколько компьютеров, и данные, сохраняемые на каждом компьютере, одинаковы. Как правило, эти несколько компьютеров распределяют нагрузку. В случае простоя балансировщик нагрузки распределяет нагрузку на время простоя.. Таким образом решается проблема отказоустойчивости.
Как показано на рисунке выше, весь слой данных имеетGroup1,Group2,Group3Она состоит из трех кластеров.Эти три кластера являются результатом горизонтальной сегментации данных.Конечно, эти три кластера также образуют БД, содержащую полные данные.
Каждая группа включает 1 Мастера (конечно, Мастеров может быть несколько) и Ведомых N. Данные этих Мастеров и Ведомых согласованы. Если один из ведомых устройств в группе 1 выходит из строя, то остаются еще два ведомых устройства, которые можно использовать.Такая модель никогда не вызовет проблемы, связанной с невозможностью доступа к определенной части данных, если только все машины во всей группе не будут отключены.
До введения кластера наш процесс запроса был примерно следующим:
- Запросите уровень данных и передайте необходимые отличительные поля подбазы данных (обычно user_id)
- Уровень данных направляет к определенной базе данных в соответствии с отличительным полем и выполняет операции с данными в этой определенной базе данных.
После введения кластера правила и политики на наших маршрутизаторах могут быть направлены только на определенныеGroup, то есть его можно направить только в виртуальную группу, эта группане конкретный физический сервер. Следующая задача, которую необходимо выполнить, — найти конкретный физический сервер БД для конкретных операций с данными.
балансировщик нагрузки
Исходя из потребностей этой ссылки, мы представили负载均衡器Согласно концепции (LB), балансировщик нагрузки должен найти определенный сервер БД.
Конкретные правила заключаются в следующем: Балансировщик нагрузки будет анализировать характеристики чтения и записи текущего SQL.Если это операция записи или операция, требующая высокой производительности в реальном времени, он напрямую разделит нагрузку запроса наMaster, если это операция чтения, используется стратегия балансировки нагрузки для выделенияSlave.
Основным направлением исследований нашего балансировщика нагрузки является стратегия распределения нагрузки.Обычно балансировка нагрузки включает в себя случайную балансировку нагрузки и взвешенную балансировку нагрузки. Случайная балансировка нагрузки хорошо изучена, то есть из NSlaveслучайно выбрать одинSlave. Такая случайная балансировка нагрузки не учитывает производительность машины, по умолчанию для каждой машины используется одинаковая производительность. Если это реальная ситуация, то это понятно. Что, если это не так? каждыйSlaveОчень ненаучно использовать случайную балансировку нагрузки вне зависимости от производительности, когда физическая производительность и конфигурация разных машин различны, что приведет к ненужной высокой нагрузке на машины с низкой производительностью и даже к простоям. производительность сервера базы данных не может в полной мере использовать свою физическую производительность. Исходя из этого соображения, мы ввели взвешенную балансировку нагрузки, то есть через определенный интерфейс в нашей системе мы можем назначить вес каждому серверу БД, а затем запускать LB согласно пропорции веса в кластере. процент нагрузки отдается серверу БД. Конечно, введение такой концепции, несомненно, повысит сложность и ремонтопригодность системы. Будут приобретения и потери, и нам не сбежать.
Проверка доступности узлов кластера
С подбиблиотекой, кластером и балансировщиком нагрузки все будет хорошо? Все далеко не так просто, как мы думали. Хотя с этими вещами мы можем в основном гарантировать, что наш уровень данных может выдержать большое давление, но такая конструкция не может полностью избежать вреда простоя базы данных. еслиGroup1серединаslave2Если машина не работает, то ЛБ системы нельзя узнать, что на самом деле очень опасно, потому что ЛБ не знает, она будет думать, чтоslave2доступен, так что он все равно дастslave2распределять нагрузку. Таким образом, проблема выходит наружу, и у клиента, естественно, возникает ошибка или исключение, что операция с данными завершается неудачно.
Как решить такую проблему? мы представляем集群节点的可用性探测机制или механизм передачи данных для обеспечения доступности. Чем отличаются эти два механизма? Прежде всего, давайте поговорим о механизме обнаружения.Как следует из названия, даже если обнаружение является моим клиентом уровня данных, он время от времени будет пытаться сделать доступной каждую базу данных в кластере.Принцип реализации заключается в попытке чтобы связать, или попытаться получить доступ к порту базы данных, что можно сделать.
Что такое механизм передачи данных? На самом деле, эту проблему следует обсуждать в реальном сценарии приложения.Как правило, если база данных БД приложения не работает, я считаю, что администратор базы данных должен знать об этом.В это время администратор базы данных вручную проталкивает текущее состояние базы данных через Клиенту, то есть прикладной стороне уровня распределенных данных, в это время обновляется список состояний локальной БД. И скажите LB, что этот узел базы данных нельзя использовать, пожалуйста, не назначайте ему нагрузку. Один из них представляет собой активный механизм мониторинга, а другой — механизм пассивного информирования. Оба имеют свои сильные стороны. Но оба могут добиться одинакового эффекта. Таким образом, только что предполагаемая проблема не возникнет, а даже если и возникнет, вероятность ее возникновения будет сведена к минимуму.
упоминается в тексте вышеMasterа такжеSlave, мы не делали много подробных объяснений. ОдинGroupна 1Masterи нSlaveсочинение. Зачем это делать? вMasterОтвечает за загрузку операций записи, то есть все операции записиMasterвключено, а чтение амортизируется доSlaveПродолжил. Таким образом, эффективность чтения может быть значительно улучшена. В общих интернет-приложениях после некоторых обзоров данных делается вывод, что соотношение чтения/записи составляет около 10:1, что означает, что большое количество операций с данными сосредоточено в операциях чтения, поэтому у нас есть несколькоSlaveпричина.
Но зачем разделять чтение и запись? Разработчики, знакомые с БД, знают, что операции записи включают блокировки, будь то блокировки строк, таблиц или блоков, которые снижают эффективность выполнения системы. Наше разделение заключается в том, чтобы сосредоточить операции записи на одном узле, а операции чтения выполняются на других N узлах, что эффективно повышает эффективность чтения и обеспечивает высокую доступность системы с другой стороны.