5 стратегий работы с высокими нагрузками в MySQL

Thank you for reading this post, don't forget to subscribe!

MySQL — про­ве­рен­ная и очень мощ­ная тех­но­ло­гия. В том чис­ле и для постро­е­ния систем с боль­шой нагруз­кой. Даже Facebook исполь­зу­ет Mysql для управ­ле­ния огром­ны­ми объ­е­ма­ми дан­ных. Рас­смот­рим основ­ные стра­те­гии для постро­е­ния нагру­жен­ных систем на осно­ве MySQL.

Оптимизация и индексы

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

Индек­сы — это эффек­тив­ный меха­низм пере­не­сти нагруз­ку с про­цес­со­ра на жест­кий диск в пра­виль­ных пропорциях.

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

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

Под­строй­ка стан­дарт­ных пара­мет­ров даст суще­ствен­ный при­рост в уско­ре­нии не толь­ко опе­ра­ций чте­ния, а и записи.

Кэширование

Очень попу­ляр­ным мето­дом опти­ми­за­ции про­из­во­ди­тель­но­сти явля­ет­ся кэширование.

Внутренний кэш Mysql

Перед тем как исполь­зо­вать внеш­нее реше­ние, поду­май­те, сто­ит ли исполь­зо­вать внут­рен­ний кэш Mysql. Его име­ет смысл вклю­чать в тех слу­ча­ях, когда Mysql рабо­та­ет с очень боль­шим коли­че­ством чте­ний (SELECT), но не очень боль­шим (как мини­мум в 10 раз мень­ше) запи­сей (INSERTDELETE и UPDATE).

Луч­ше не вклю­чать внут­рен­ний кэш Mysql в сре­дах с боль­шим коли­че­ством записей/обновлений.

Настрой­ка кэша выпол­ня­ет­ся с помо­щью пара­мет­ра mysql_query_cache_size.

Внешние решения

Более гиб­ким реше­ни­ем явля­ет­ся исполь­зо­ва­ние внеш­них инстру­мен­тов кэши­ро­ва­ния, вро­де Memcache либо Redis. Суще­ству­ет целый ряд тех­ник кэши­ро­ва­ния дан­ных в приложениях.

Одна­ко, будь­те осто­рож­ны. Кэши­ро­ва­ние — это часто не реше­ние про­бле­мы, а ее откла­ды­ва­ние. Мед­лен­ный запрос ста­но­вит­ся еще мед­лен­нее, а его вли­я­ние (при сбро­се кэша) менее прогнозируемым.

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

Репликация

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

С дру­гой сто­ро­ны, репли­ка как раз поз­во­ля­ет обес­пе­чить высо­кую доступ­ность. Один из под­хо­дов выгля­дит так:

  • Исполь­зо­вать master-slave репли­ка­цию для каж­до­го сер­ве­ра БД.
  • При­ло­же­ние все­гда рабо­та­ет толь­ко с мастером.
  • Если мастер выхо­дит из строя, при­ло­же­ние пере­клю­ча­ет­ся на слейв.
  • Мы в это вре­мя под­ни­ма­ем сло­ман­ный сер­вер и пре­вра­ща­ем его в слейв ( как это пра­виль­но сделать).

Таким обра­зом, в новой схе­ме мастер и слейв поме­ня­лись места­ми, а при­ло­же­ние (т.е. его поль­зо­ва­те­ли) не заме­ти­ло ника­ких проблем.

Репли­ка­цию сто­ит исполь­зо­вать толь­ко как меха­низм резер­ви­ро­ва­ния. Не для мас­шта­би­ро­ва­ния под нагрузки.

Шардинг

Шар­динг — это прин­цип мас­шта­би­ро­ва­ния базы дан­ных, когда дан­ные раз­де­ля­ют­ся по раз­ным сер­ве­рам. В нашем рас­по­ря­же­нии есть два подхода:

Вертикальный шардинг

Его сто­ит исполь­зо­вать в первую оче­редь. Это про­стое рас­пре­де­ле­ние таб­лиц по сер­ве­рам. Напри­мер, вы поме­ща­е­те таб­ли­цу users на одном сер­ве­ре, а таб­ли­цу orders на дру­гом. В этом слу­чае, груп­пы таб­лиц, по кото­рым выпол­ня­ют­ся JOIN, долж­ны нахо­дит­ся на одном сервере.

Горизонтальный шардинг

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

Шар­динг — един­ствен­ный под­ход для мас­шта­би­ро­ва­ния дей­стви­тель­но боль­ших данных.

Другие задачи

Сле­ду­ет отме­тить, что суще­ству­ют зада­чи, с кото­рым MySQL справ­ля­ет­ся крайне пло­хо. Один из при­ме­ров — выбор­ки уни­каль­ных зна­че­ний в раз­ных диа­па­зо­нах. Либо пол­но­тек­сто­вый поиск.

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

MySQL — мощ­ное, но не уни­вер­саль­ное реше­ние. Redis, Elastic и дру­гие тех­но­ло­гии помо­гут решить допол­ни­тель­ные задачи.

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