фон

Далее мы будем использовать электронную коммерцию в качестве примера.

бизнес-перспектива

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

техническая перспектива

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

Проблемы с одной базой данных и одной таблицей:

1. Узкое место в производительности：По мере увеличения объема данных,Производительность чтения и запросов к базе данных будет постепенно снижаться. Особенно, когда количество строк данных в таблице достигает миллионов и более.,Даже простые операции запроса могут стать очень медленными.
2. Горячие точки данных：Все операции с данными сосредоточены в одной таблице в одной базе данных.,легко формировать Горячие точки данных, из-за чего некоторые строки данных становятся частым доступом и становятся Узкое место в производительности
3. Проблемы высокой доступности и аварийного восстановления：Трудно добиться высокой доступности и аварийного восстановления с помощью единой базы данных и архитектуры одной таблицы.。Как только база данных выйдет из строя,Это повлияет на все приложение. и,Восстановление данных занимает больше времени,Влияет на нормальную работу бизнеса.
4. Проблемы масштабируемости：По мере развития бизнеса,Объем данных и доступ продолжают расти,Архитектуру одной базы данных и одной таблицы сложно удовлетворить потребностям путем простого расширения. Как горизонтальное расширение (добавление дополнительных серверов), так и вертикальное расширение (обновление существующего серверного оборудования) имеют ограничения.
5. Управление транзакциями и конфликты блокировок：В ситуациях с высоким параллелизмом,Большое количество транзакций и операций с базой данных может привести к проблемам блокировки блокировок.,Влияет на возможности обработки базы данных.
6. Сложности резервного копирования и обслуживания：По мере увеличения объема данных,Сложность и временные затраты на резервное копирование и обслуживание базы данных также значительно возрастут.

Процесс обновления архитектуры

ссылка：Процесс эволюции архитектуры базы данных

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

Процесс миграции

Краткое описание сценария

шаги миграции

1. Возможность реализации чтения и записи новых данных.
2. Реализуйте синхронизацию старых данных с новыми данными (путем мониторинга binlog).
3. Реализуйте синхронизацию новых данных со старыми (путем мониторинга binlog).
4. Начать новые данные в оттенках серого читать
5. После прочтения всего объема новых данных закройте старые. данныеизчитать
6. Начать новые данные в оттенках серого Писать
7. После полного объема новых данных Писать, закройте старые данные Писать.
8. После стабильной работы в сети в течение определенного периода времени отключите синхронизацию старых и новых данных.
9. Архивстарые данные,офлайнстарые данные

До миграции

Миграция

После миграции

Подвести итог

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