Серия Database (пять) из MySQL в масштабируемости

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

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

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

      Здесь наиболее популярная база данных MySQL в качестве примера для обсуждения масштабируемости.

 

База данных продольное

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

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

Почему вскоре достигли узкого места?               

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

      Во-вторых, цена достигла узкого места. В первом случае, вы можете легко увеличить скорость доступа к системе и улучшить машину (VM) или конфигурацию. Легко начать улучшаться, но после улучшения к стандартной цене машины не обычная компания может принять дерегулирование. (О памяти 256GB сердечника 32)

Таким образом, в этом случае, как улучшить масштабируемость этого?           

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

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

 

масштабируемость базы данных Mysql

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

Подчиненная                                            

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

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

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

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

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

      В мастер-ведомый, он может быть мульти-мастер из нескольких мульти-мастер из них в соответствии с реальной дорожной ситуации. Следует отметить, что мульти-мастер времени, чтобы гарантировать, что задержка данных, вызванные инвазивными.

раздел данных                                               

      从mysql5.1开始，支持表级别的数据分区。此数据分区无需在应用代码做任何修改，只需要在mysql中配置即可。此分区方式是物理级别的分区，它会把同一个表通过指定的算法分离存储到不同位置，最终达到提高表的量级的目的。更深一层说，一个表的数据通过物理分区分离到数个不同的物理区域，每个分区都是独立的。表分区有4种方式，与下面讨论的分表算法一致。

分库分表                                   

      再进一步，就是分库分表了。先讨论一下分库。

      分库很简单，把不同的表分到不同的库，或者把相同的表不同的数据分到不同的库。

第一，不同的表分到不同的库。

      把主库里的表分离出来，分到各个不同业务逻辑上的库。例如主库上分别有：user表、权限表、订单表、购物车表。把库物理分离表，分成用户库：user表、权限表。购物车库：订单表、购物车表。这种分离根据业务拆分很简便，代码修改很少，但是单个表的数据量大时会到瓶颈。如下图展示。

第二，相同的表不同的数据分到不同的库。

      这种与分表挂钩，即把数据分离到不同的库，不同库的表都一致。例如主库上分别有：user表、权限表、订单表、购物车表。现在分两个库：库A与库B。库AB的表与主库一致，但数据分离。如库A保存北京用户的数据，库B保存广州用户的数据。如下图展示。

 

分表详解

      上述讲述分库的两种方式时，第二种方式涉及到分表。分表的算法为：中间表、求余取模、范围方式、一致性hash。

中间表方式                             

      首先插入数据时，在中间库中保存此条数据id与数据库的映射关系，再插入到对应的库中。如插入用户信息，数据有：用户id、用户名称。首先把数据插入到对应的数据库，如插入到主库A，数据有：用户id、用户名称。然后把数据插入到中间表中，数据有：用户id、数据库ip、数据库名称。

      那么在查询时，首先根据用户id查询中间表得到数据库相关信息（数据库A），再查询相应的数据库A得到用户数据：用户名称。如下图展示。

      这种方式好处在于容易分表。如果加库修改中间映射表即可。缺点在于多了一次数据库的读写操作。

求余取模方式                             

      求余取模即根据分区键（或主键等），对分区键进行统一的求余，余数为对应的数据库。这种方式也是使用得最广的方式，因为简单，并且一般企业一开始数据库数量会定好，长时间无需添加库。

      如目前有4台数据库，那么被除数时4。对分区键进行hash取整（如果s是整数则无需取hash），余数是0则在数据库A，余数是1则在数据库B，余数是2则在数据库C，余数是3则在数据库D。如下图所示。

      这种方式的有点在于简单，读写数据只需求余取模即可，较中间表方式性能较高。但是如果需要添加数据库的话，比较麻烦，需要迁移数据。

      例如如果要添加数据库，只能是4的整数倍。现在是4，那么被除数变成8，数据库也变成8台。如下图所示。

      切分后，还需要迁移数据。如

0%4=0，1%4=1，2%4=2，3%4=3，4%4=0，5%4=1，6%4=2，7%4=3。

0%8=0，1%8=1，2%8=2，3%8=3，4%8=4，5%8=5，6%8=6，7%8=7。

      所以，需要把余数处以8等于4-7之间的，迁移到对应的库E-F。

范围方式                                         

      范围方式是最好理解的方式。范围方式即取得分区键，对分区键进行范围处理，如果指定到某个范围区域，则数据指向到对应得数据库。如范围1-1000W到数据库A，范围1001W-2000W到数据库B，范围2001W-3000W到数据库C。如下图所示。

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

Консистенция путь хэш                             

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

      Последовательность определяется узел сервера хеш-значение хэш-алгоритма, который расположен по окружности 0 ~ 232. Затем определяется с использованием хеш-значение данных, сохраненных в той же манере, и отображается на той же окружности. По часовой стрелке до ближайшего сервера, то данные, хранящиеся на сервере.

      Например, база данных А, В, С. 1,2,3,4 круг данных падают через хэш-алгоритм. Данные хранятся в часовом ближайшем сервере. Данные, сохраненные на сервере 1, 5 A, 2 данных, хранящиеся в сервере B, и они хранятся в 3,4 сервере C. Как показано на фиг.

      При добавлении сервера D, затем видеть добавил к кругу, где сервер с помощью алгоритмов. Если есть данные между сервером А до С, часть А хранится в сервере необходимости быть перенесены на сервер D. Как показано ниже, данные, которые должны быть перенесены на сервер 5 D.

 

резюме

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

 

Нет, я могу сосредоточиться на людях, многие годы опыта оригинальной статьи для всех, чтобы поделиться.