17.3.5.2. MySQL Cluster Interconnects и Performance

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

Есть четыре метода доступа:

Доступ первичного ключа. Это - доступ записи через ее первичный ключ. В самом простом случае только к одной записи получают доступ за один раз, что означает, что полная стоимость установки многих сообщений TCP/IP и многих затрат для контекстного переключения переносится этим единственным запросом. В случае, куда многократные доступы первичного ключа отправляются в одном пакете, те доступы совместно используют стоимость установки необходимых сообщений TCP/IP и контекстных переключений. Если сообщения TCP/IP для различных мест назначения, дополнительные сообщения TCP/IP должны быть установлены.
Доступ уникального ключа. Доступы уникального ключа подобны доступам первичного ключа, за исключением того, что доступ уникального ключа выполняется как чтение на индексировать таблице, сопровождаемой доступом первичного ключа на таблице. Однако, только один запрос отправляется от MySQL Server, и чтение индексировать таблицы обрабатывается ndbd. Такие запросы также извлекают выгоду из пакетной обработки.
Полное сканирование таблицы. Когда не индексирует, существуют для поиска на таблице, полное сканирование таблицы выполняется. Это отправляется как единственный запрос процессу ndbd, который тогда делит сканирование таблицы на ряд параллельных сканирований на всем кластере ndbd процессы. В будущих версиях MySQL Cluster узел SQL будет в состоянии фильтровать некоторые из этих сканирований.
Упорядоченное использование сканирования диапазона индексирует. То, когда упорядоченный индексирует, используется, это выполняет сканирование тем же самым способом как полное сканирование таблицы, за исключением того, что это сканирует только те записи, которые находятся в диапазоне, используемом запросом, переданным сервером MySQL (узел SQL). Все разделы сканируются параллельно, когда все связанные индексируют атрибуты, включают все атрибуты в ключ разделения.

Со сравнительными тестами, разработанными внутренне MySQL для того, чтобы протестировать простые и обработанные в пакетном режиме доступы первичного и уникального ключа, мы нашли, что использование сокетов SCI улучшает производительность приблизительно на 100 % по TCP/IP, кроме в редких экземплярах, когда коммуникационная производительность не является проблемой. Это может произойти, когда фильтры сканирования составляют большую часть времени обработки или когда очень большие пакеты доступов первичного ключа достигаются. В этом случае обработка ЦП в процессах ndbd становится довольно значительной частью издержек.

Используя транспортер SCI вместо SCI Сокеты имеет только интерес к передаче между процессами ndbd. Используя SCI транспортер имеет также только интереса, если ЦП может быть выделен процессу ndbd, потому что транспортер SCI гарантирует, что этот процесс никогда не будет засыпать. Также важно гарантировать, что приоритет процесса ndbd устанавливается таким способом, которым процесс не теряет приоритет из-за выполнения в течение длительного периода времени, как может быть сделан, блокируя процессы к ЦП в Linux 2.6. Если такая конфигурация будет возможна, то процесс ndbd извлечет выгоду на 10-70 % по сравнению с использованием сокетов SCI. (Более крупные числа будут замечены, выполняя обновления и вероятно на параллельных операциях сканирования также.)

Есть несколько других оптимизированных реализаций сокета для компьютерных кластеров, включая Myrinet, Гигабитный Ethernet, Infiniband и ЧЕРЕЗ интерфейс. Однако, мы до сих пор тестировали MySQL Cluster только с сокетами SCI. См. Раздел 17.3.5.1, "Конфигурируя MySQL Cluster, чтобы использовать Сокеты SCI,", для информации о том, как установить сокеты SCI, используя обычный TCP/IP для MySQL Cluster.