14.2.9.5. Запись Приложений для InnoDB memcached Интерфейс

Как правило, при записи приложения для InnoDB интерфейс memcached включает определенную степень перезаписи или адаптации существующего кода, который использует MySQL или memcached API:

Вместо многих memcached серверов, работающих на маломощных машинах, у Вас есть то же самое число memcached серверов как серверы MySQL, работая на относительно мощных машинах с существенной памятью на диске и памятью. Вы могли бы снова использовать некоторый существующий код, который работает с memcached API, но некоторая адаптация, вероятно, необходима из-за различной конфигурации сервера.
Данные, хранившие через этот интерфейс, все входит VARCHAR, TEXT, или BLOB столбцы, и должны быть преобразованы, чтобы сделать числовые операции. Можно сделать преобразование на стороне приложения, или при использовании CAST() функция в запросах.
Происходя из среды базы данных, Вы могли бы привыкнуть к таблицам SQL общего назначения со многими столбцами. Таблицы, к которым получает доступ memcached, кодируют, вероятно, имеют только некоторых или даже только единственный столбец, содержащий значения данных.
Вы могли бы адаптировать части своего приложения, которые делают запросы единственной строки, вставляет, обновляет, или удаляет, чтобы сжать больше производительности из критических разделов кода. Оба запроса (читают) и DML (запись), операции могут быть существенно быстрее когда выполняющийся через интерфейс memcached. Ускорение для записей обычно больше чем ускорение для чтений, таким образом, Вы могли бы сосредоточиться на том, чтобы адаптировать код, который выполняет журналирование или записывает интерактивные варианты на веб-сайте.

Следующие разделы исследуют эти аспекты более подробно.

14.2.9.5.1. Адаптация Схемы MySQL Existing для memcachedApplication

Полагайте, что эти аспекты memcached приложений, адаптируя существующую схему MySQL или приложение используют интерфейс memcached:

ключи memcached не могут содержать пробелы или новые строки, потому что те символы используются в качестве разделителей в протоколе ASCII. Если Вы используете справочные значения, которые содержат пробелы, преобразовывают или хешируют их в значения без пробелов перед использованием их как ключи в звонках add(), set(), get() и так далее. Хотя теоретически те символы позволяются в ключах в программах, которые используют протокол двоичной синхронной передачи данных, следует всегда ограничивать символы, используемые в ключах, чтобы гарантировать совместимость широким диапазоном клиентов.
Если у Вас есть короткий числовой столбец первичного ключа в InnoDB таблица, можно использовать это в качестве уникального ключа поиска для memcached, преобразовывая целое число в строковое значение. Если memcached сервер используется больше чем для одного приложения, или с больше чем одним InnoDB таблица, полагайте, что изменение имени удостоверяется, что это уникально. Например, Вы могли бы предварительно ожидать имя таблицы, или имя базы данных и имя таблицы, перед числовым значением.
Невозможно использовать разделенную таблицу для данных, запрошенных или хранивших через интерфейс memcached.
memcached протокол раздает числовые значения как строки. Сохранить числовые значения в базовом InnoDB таблица, например чтобы реализовать счетчики, которые могут использоваться в функциях SQL такой как SUM() или AVG():
- Использовать VARCHAR столбцы достаточно со многими символами, чтобы содержать все цифры самого большого ожидаемого числа (и дополнительные символы если приспособлено для знака минус, десятичной точки, или обоих).
- В любом запросе, который выполняет арифметику, используя значения столбцов, используйте CAST() функционируйте, чтобы преобразовать от строки до целого числа или другого числового типа. Например:
```
-- Alphabetic entries are returned as zero.select cast(c2 as unsigned integer) from demo_test;-- Since there could be numeric values of 0, can't disqualify them.-- Test the string values to find the ones that are integers, and average only those.select avg(cast(c2 as unsigned integer)) from demo_test  where c2 between '0' and '9999999999';-- Views let you hide the complexity of queries. The results are already converted;-- no need to repeat conversion functions and WHERE clauses each time.create view numbers as select c1 key, cast(c2 as unsigned integer) val  from demo_test where c2 between '0' and '9999999999';select sum(val) from numbers;
```
  Отметьте, что любые алфавитные значения в наборе результатов превращаются в 0 звонком CAST(). При использовании функций такой как AVG() это зависит от числа строк в наборе результатов, включает WHERE пункты, чтобы отфильтровать любые нечисловые значения.
Если InnoDB столбец, который Вы используете в качестве ключа, может быть более длинным чем 250 байтов, хешировать его к значению, которое составляет меньше чем 250 байтов.
Чтобы использовать существующую таблицу с интерфейсом memcached, определите запись для этого в innodb_memcache.containers таблица. Чтобы сделать это таблицей значение по умолчанию для всех запросов переданный через memcached, определите значение default в name столбец, затем перезапустите сервер MySQL, чтобы произвести то изменение, вступают в силу. Если Вы используете многократные таблицы для различных классов memcached данных, установите многократные записи в innodb_memcache.containers таблица с name значения Вашего выбора, затем выпустите запрос memcached формы get @@name или set @@name в пределах приложения, чтобы переключить таблицу, используемую для последующих запросов через memcached API.

Для примера использования таблицы кроме предопределенного test.demo_test таблица, см. Пример 14.5, "Определение Таблицы и Столбца, Отображающегося для InnoDB + memcached Приложение". Для необходимого расположения и значения столбцов в такой таблице, см. Раздел 14.2.9.7, "Внутренности InnoDB memcached Плагин".
Использовать многократные значения столбцов MySQL с memcached парами ключ/значение, в innodb_memcache.containers запись, связанная с таблицей MySQL, определите в value_columns поле несколько имен столбцов, разделенных запятой, точкой с запятой, пространством, или символами канала; например, col1,col2,col3 или col1|col2|col3.

Свяжите значения столбцов в единственную строку, используя символ канала в качестве разделителя, прежде, чем передать ту строку к memcached add или set вызовы. Строка распаковывается автоматически в различные столбцы. Каждый get вызовите возвраты единственная строка со значениями столбцов, также разграниченными символом разделителя канала. Вы распаковываете те значения, используя соответствующий синтаксис в зависимости от Вашего языка приложения.

Пример 14.5. Определение Таблицы и Столбца, Отображающегося для InnoDB + memcachedApplication

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

Во-первых, мы устанавливаем таблицу, чтобы содержать некоторые данные страны: совокупность, область в метрических модулях, и 'R' или 'L' указание, управляют ли люди справа или слева.

use test;CREATE TABLE `multicol` (  `country` varchar(128) NOT NULL DEFAULT '',  `population` varchar(10) DEFAULT NULL,  `area_sq_km` varchar(9) DEFAULT NULL,  `drive_side` varchar(1) DEFAULT NULL,  `c3` int(11) DEFAULT NULL,  `c4` bigint(20) unsigned DEFAULT NULL,  `c5` int(11) DEFAULT NULL,  PRIMARY KEY (`country`),) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Теперь мы делаем дескриптор для этой таблицы так, чтобы InnoDB плагин memcached знает, как получить доступ к нему:

Демонстрационная запись в CONTAINERS у таблицы есть a name столбец 'aaa'; мы устанавливаем другой идентификатор 'bbb'. Если бы мы сделали единственную основную таблицу для всех memcached приложений, чтобы использовать, то мы сделали бы ID 'default' и пропустите @@ запросы, чтобы переключить таблицы.
Мы определяем test.multicol таблица. Имя схемы сохранено в одном столбце, и имя таблицы сохранено в другом столбце.
Ключевой столбец будет нашим уникальным country значение. Тот столбец был определен как первичный ключ, когда мы составляли таблицу выше, таким образом, мы также определяем имя индекса 'PRIMARY' здесь.
Вместо единственного столбца, чтобы содержать составное значение данных, мы разделим данные среди трех столбцов таблицы, таким образом, мы определим список разделенных запятой значений тех столбцов, которые будут использоваться, храня или получая значения.
И для флагов, истеките, и значения CAS, мы определяем соответствующие столбцы, основанные на настройках от демонстрационной таблицы demo.test. Эти значения являются обычно не существенными в приложениях, используя InnoDB плагин memcached, потому что MySQL сохраняет данные синхронизируемыми и нет никакой потребности волноваться об истечении данных или быть устарелым.

insert into innodb_memcache.containers  (name,db_schema,db_table,key_columns,value_columns,flags,cas_column,  expire_time_column,unique_idx_name_on_key)values  ('bbb','test','multicol','country','population,area_sq_km,drive_side',  'c3','c4','c5','PRIMARY');commit;

Вот демонстрационная программа Python, показывающая, как мы получили бы доступ к этой таблице из программы:

Никакая авторизация базы данных не необходима, так как все манипулирование данными делается через интерфейс memcached. Все, что мы должны знать, является номером порта, который memcached демон слушает на локальной системе.
Мы загружаем демонстрационные значения для нескольких произвольных стран. (Область и совокупность фигурируют из Википедии.)
Заставить программу использовать multicol таблица, мы вызываем switch_table() функция, которая делает макет GET или SET использование запроса @@ нотация. Имя в запросе bbb, который является значением, мы сохранили в innodb_memcache.containers.name. (В реальном приложении мы использовали бы более описательное имя. Этот пример только иллюстрирует, что Вы определяете табличный идентификатор, не имя таблицы, с GET @@... запрос.
Служебные функции, чтобы вставить и запросить данные демонстрируют, как мы могли бы превратить структуру данных Python в разделенные от канала значения для того, чтобы передаться к MySQL с ADD или SET запросы, и распаковывают разделенные от канала значения, возвращенные GET запросы. Эта дополнительная обработка только требуется, когда отображение единственного memcached оценивает многократным столбцам таблицы MySQL.

import sys, osimport memcachedef connect_to_memcached():  memc = memcache.Client(['127.0.0.1:11211'], debug=0);  print "Connected to memcached."  return memcdef banner(message):  print  print "=" * len(message)  print message  print "=" * len(message)country_data = [("Canada","34820000","9984670","R"),("USA","314242000","9826675","R"),("Ireland","6399152","84421","L"),("UK","62262000","243610","L"),("Mexico","113910608","1972550","R"),("Denmark","5543453","43094","R"),("Norway","5002942","385252","R"),("UAE","8264070","83600","R"),("India","1210193422","3287263","L"),("China","1347350000","9640821","R"),]def switch_table(memc,table):  key = "@@" + table  print "Switching default table to '" + table + "' by issuing GET for '" + key + "'."  result = memc.get(key)def insert_country_data(memc):  banner("Inserting initial data via memcached interface")  for item in country_data:    country = item[0]    population = item[1]    area = item[2]    drive_side = item[3]    key = country    value = "|".join([population,area,drive_side])    print "Key = " + key    print "Value = " + value    if memc.add(key,value):      print "Added new key, value pair."    else:      print "Updating value for existing key."      memc.set(key,value)def query_country_data(memc):  banner("Retrieving data for all keys (country names)")  for item in country_data:    key = item[0]    result = memc.get(key)    print "Here is the result retrieved from the database for key " + key + ":"    print result    (m_population, m_area, m_drive_side) = result.split("|")    print "Unpacked population value: " + m_population    print "Unpacked area value      : " + m_area    print "Unpacked drive side value: " + m_drive_sideif __name__ == '__main__':  memc = connect_to_memcached()  switch_table(memc,"bbb")  insert_country_data(memc)  query_country_data(memc)  sys.exit(0)

Вот некоторые SQL-запросы, чтобы иллюстрировать состояние данных MySQL после того, как сценарий выполняется, и покажите, как Вы могли получить доступ к тем же самым данным непосредственно через SQL, или из приложения, записанного на любом языке, используя соответствующий MySQL Connector или API.

Табличный дескриптор 'bbb' на месте, разрешая нам переключиться на multicol таблица, выпуская запрос memcached GET @bbb:

mysql: use innodb_memcache;Database changedmysql: select * from containers;+------+-----------+-----------+-------------+----------------------------------+-------+------------+--------------------+------------------------+| name | db_schema | db_table  | key_columns | value_columns                    | flags | cas_column | expire_time_column | unique_idx_name_on_key |+------+-----------+-----------+-------------+----------------------------------+-------+------------+--------------------+------------------------+| aaa  | test      | demo_test | c1          | c2                               | c3    | c4         | c5                 | PRIMARY                || bbb  | test      | multicol  | country     | population,area_sq_km,drive_side | c3    | c4         | c5                 | PRIMARY                |+------+-----------+-----------+-------------+----------------------------------+-------+------------+--------------------+------------------------+2 rows in set (0.01 sec)

После выполнения сценария данные находятся в multicol таблица, доступная для традиционных запросов MySQL или операторов DML:

mysql: use test;Database changedmysql: select * from multicol;+---------+------------+------------+------------+------+------+------+| country | population | area_sq_km | drive_side | c3   | c4   | c5   |+---------+------------+------------+------------+------+------+------+| Canada  | 34820000   | 9984670    | R          |    0 |   11 |    0 || China   | 1347350000 | 9640821    | R          |    0 |   20 |    0 || Denmark | 5543453    | 43094      | R          |    0 |   16 |    0 || India   | 1210193422 | 3287263    | L          |    0 |   19 |    0 || Ireland | 6399152    | 84421      | L          |    0 |   13 |    0 || Mexico  | 113910608  | 1972550    | R          |    0 |   15 |    0 || Norway  | 5002942    | 385252     | R          |    0 |   17 |    0 || UAE     | 8264070    | 83600      | R          |    0 |   18 |    0 || UK      | 62262000   | 243610     | L          |    0 |   14 |    0 || USA     | 314242000  | 9826675    | R          |    0 |   12 |    0 |+---------+------------+------------+------------+------+------+------+10 rows in set (0.00 sec)mysql: desc multicol;+------------+---------------------+------+-----+---------+-------+| Field      | Type                | Null | Key | Default | Extra |+------------+---------------------+------+-----+---------+-------+| country    | varchar(128)        | NO   | PRI |         |       || population | varchar(10)         | YES  |     | NULL    |       || area_sq_km | varchar(9)          | YES  |     | NULL    |       || drive_side | varchar(1)          | YES  |     | NULL    |       || c3         | int(11)             | YES  |     | NULL    |       || c4         | bigint(20) unsigned | YES  |     | NULL    |       || c5         | int(11)             | YES  |     | NULL    |       |+------------+---------------------+------+-----+---------+-------+7 rows in set (0.01 sec)

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

Мы можем представить доклады посредством SQL-запросов, делая вычисления и тесты через любые столбцы, не только country ключевой столбец. (Поскольку эти примеры используют данные только из нескольких стран, числа в целях иллюстрации только.) Здесь, мы находим среднюю совокупность стран, где люди управляют справа, и средний размер стран, имена которых запускаются с "U":

mysql: select avg(population) from multicol where drive_side = 'R';+-------------------+| avg(population)   |+-------------------+| 261304724.7142857 |+-------------------+1 row in set (0.00 sec)mysql: select sum(area_sq_km) from multicol where country like 'U%';+-----------------+| sum(area_sq_km) |+-----------------+|        10153885 |+-----------------+1 row in set (0.00 sec)

Поскольку population и area_sq_km столбцы хранят символьные данные, а не числовые данные со строгим контролем типов, функции такой как avg() и sum() работа, преобразовывая каждое значение в число сначала. Этот подход не работает на операторы такой как < или >: например, сравнивая символьно-ориентированные значения, 9 > 1000, который не является Вами, ожидают от пункта такой как ORDER BY population DESC. Для самой точной обработки типа выполните запросы против представлений, которые бросают числовые столбцы к соответствующим типам. Этот метод позволяет Вам выходить очень простой SELECT * запросы от Ваших приложений базы данных, гарантируя, что весь бросок, фильтрация, и упорядочивание корректны. Здесь, мы делаем представление, которое может быть запрошено, чтобы найти лучшие 3 страны в порядке убывания совокупности с результатами, всегда отражающими последние данные от multicol таблица, и с совокупностью и областью всегда фигурирует обработанный как числа:

mysql: create view populous_countries as  select    country,    cast(population as unsigned integer) population,    cast(area_sq_km as unsigned integer) area_sq_km,    drive_side from multicol  order by cast(population as unsigned integer) desc  limit 3;Query OK, 0 rows affected (0.01 sec)mysql: select * from populous_countries;+---------+------------+------------+------------+| country | population | area_sq_km | drive_side |+---------+------------+------------+------------+| China   | 1347350000 |    9640821 | R          || India   | 1210193422 |    3287263 | L          || USA     |  314242000 |    9826675 | R          |+---------+------------+------------+------------+3 rows in set (0.00 sec)mysql: desc populous_countries;+------------+---------------------+------+-----+---------+-------+| Field      | Type                | Null | Key | Default | Extra |+------------+---------------------+------+-----+---------+-------+| country    | varchar(128)        | NO   |     |         |       || population | bigint(10) unsigned | YES  |     | NULL    |       || area_sq_km | int(9) unsigned     | YES  |     | NULL    |       || drive_side | varchar(1)          | YES  |     | NULL    |       |+------------+---------------------+------+-----+---------+-------+4 rows in set (0.02 sec)

14.2.9.5.2. Адаптация Существующего memcached Приложения для theIntegrated memcached Демон

Рассмотрите эти аспекты MySQL и InnoDB таблицы, адаптируя существующее memcached приложение, чтобы использовать интеграцию MySQL:

Если у Вас есть значения ключа дольше чем несколько байтов, Вы могли бы счесть более эффективным использовать числовой столбец автоприращения для первичного ключа в InnoDB таблица, и создает уникальное вторичное устройство, индексируют на столбце, содержащем memcached значения ключа. Это то, потому что InnoDB выполняет лучше всего для крупномасштабных вставок, если значения первичного ключа добавляются в сортированном порядке (как они с автоинкрементными значениями), и значения первичного ключа дублируются в каждом вторичном устройстве, индексируют, который может занять ненужное место, когда первичный ключ является длинным строковым значением.
Если Вы храните несколько различных классов информации в memcached, Вы могли бы установить отдельное InnoDB таблица для каждого вида данных. Определите дополнительные табличные идентификаторы в innodb_memcache.containers таблица, и использование нотация @@table_id.key сохранить или получить элементы от различных таблиц. Физически деление элементов позволяет Вам настраивать характеристики каждой таблицы для лучшего использования пространства, производительности, и надежности. Например, Вы могли бы включить сжатию для таблицы, которая содержит сообщения в блоге, но не для того, который содержит изображения миниатюры. Вы могли бы поддерживать одну таблицу более часто чем другой, потому что она содержит критические данные. Вы могли бы создать дополнительное вторичное устройство, индексирует на таблицах, которые часто используются, чтобы генерировать отчеты через SQL.
Предпочтительно, установите устойчивое множество табличных определений для использования с memcached, соединяют интерфейсом и оставляют их на месте постоянно. Изменения к containers таблица вступает в силу в следующий раз, когда таблица запрашивается. Записи в той таблице обрабатываются при запуске, и консультируются всякий раз, когда нераспознанный табличный ID требуют @@ нотация. Таким образом новые записи видимы, как только Вы пытаетесь использовать связанный табличный ID, но изменяется на существующие записи, требуют перезапуска сервера прежде, чем они вступят в силу.
Когда Вы используете политику кэширования значения по умолчанию innodb_only, Ваши звонки add(), set(), incr(), и так далее может следовать, но все еще инициировать отладочные сообщения такой как while expecting 'STORED', got unexpected response 'NOT_STORED. Это то, потому что в innodb_only конфигурация, новые и обновленные значения отправляются непосредственно InnoDB таблица, не будучи сохраненным в кэш-памяти.

14.2.9.5.3. Настройка Производительности InnoDB memcached Плагин

Поскольку использование InnoDB в комбинации с memcached включает запись, что все данные к диску, или сразу или когда-то позже, понимают, что необработанная производительность, как ожидают, будет несколько ниже чем использование memcached отдельно. Фокусируйте свои настраивающие цели для InnoDB плагин memcached при достижении более высокой производительности чем эквивалентные операции SQL.

Сравнительные тесты предполагают, что оба запроса и операции DML (вставляет, обновления, и удаляет), быстрее проходят через интерфейс memcached чем с традиционным SQL. Операции DML обычно видят большее ускорение. Таким образом типы приложений, которые Вы могли бы адаптировать, чтобы использовать интерфейс memcached сначала, являются теми, которые интенсивны записью. Вы могли бы также использовать MySQL в качестве хранилища данных для типов интенсивных записью приложений, которые прежде использовали некоторый быстрый, легкий механизм, где надежность не была приоритетом.

Адаптация SQL-запросов

Типы запросов, которые больше всего подходят для простого GET стиль запроса - те с единственным пунктом, или рядом AND условия, в WHERE пункт:

SQL:select col from tbl where key = 'key_value';memcached:GET key_valueSQL:select col from tbl where col1 = val1 and col2 = val2 and col3 = val3;memcached:# Since you must always know these 3 values to look up the key,# combine them into a unique string and use that as the key# for all ADD, SET, and GET operations.key_value = val1 + ":" + val2 + ":" + val3GET key_valueSQL:select 'key exists!' from tbl  where exists (select col1 from tbl where key = 'key_value') limit 1;memcached:# Test for existence of key by asking for its value and checking if the call succeeds,# ignoring the value itself. For existence checking, you typically only store a very# short value such as "1".GET key_value

Использование в своих интересах Системной памяти

Для лучшей производительности развернитесь InnoDB плагин memcached на машинах, которые конфигурируются как типичные серверы баз данных: в частности с большинством системной RAM, посвященной InnoDB пул буферов через innodb_buffer_pool_size параметр конфигурации. Для систем с пулами буферов мультигигабайта рассмотрите повышение значения innodb_buffer_pool_instances параметр конфигурации для максимальной пропускной способности, когда большинство операций включает данные, уже кэшируемые в памяти.

Сокращение Избыточного ввода-вывода

InnoDB имеет много настроек, которые позволяют Вам выбирать баланс между высокой надежностью в случае катастрофического отказа, и количеством издержек ввода-вывода во время высоких рабочих нагрузок записи. Например, рассмотрите установку параметров конфигурации innodb_doublewrite=0 и innodb_flush_log_at_trx_commit=2. Определите эксплуатационные качества с различными настройками для innodb_flush_method опция. Если двоичный журнал не включается для сервера, используйте установку innodb_support_xa=0.

Для других способов уменьшить или настроить ввод-вывод для табличных операций, см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

Сокращение Транзакционных Издержек

Значение по умолчанию 1 для параметров конфигурации daemon_memcached_r_batch_size и daemon_memcached_w_batch_size предназначается для максимальной надежности результатов и безопасности хранивших или обновленных данных.

В зависимости от типа приложения Вы могли бы увеличиться один или обе из этих настроек, чтобы уменьшить издержки частых операций фиксации. На занятой системе Вы могли бы увеличиться daemon_memcached_r_batch_size, знание, которое изменяется на данные, сделанные через SQL, не могло бы стать видимым к memcached сразу (то есть, до N больше get операции были обработаны). Обрабатывая данные, где каждая операция записи должна быть достоверно сохранена, Вы уехали бы daemon_memcached_w_batch_size набор к 1. Вы могли бы увеличить это, обрабатывая большие количества обновлений, предназначенных, чтобы только использоваться для статистического анализа, где это не является критическим если последнее N обновления теряются в случае катастрофического отказа.

Например, вообразите систему, которая контролирует трафик, пересекающий занятый мост, записывая приблизительно 100 000 механизмов каждый день. Если приложение просто считает различные типы механизмов, чтобы проанализировать образцы трафика, оно могло бы измениться daemon_memcached_w_batch_size от 1 к 100, сокращение издержек ввода-вывода для операций фиксации на 99 %. В случае неожиданного отключения электричества мог быть потерян только максимум 100 записей, который мог бы быть приемлемым пределом погрешности. Если бы вместо этого приложение делало автоматизированный междугородный набор для каждого автомобиля, то это сохранило бы daemon_memcached_w_batch_size набор к 1 гарантировать, что каждая междугородная запись была сразу сохранена на диск.

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

memslap команда, которая является частью регулярного memcached распределения, но не включенная с сервером MySQL, может быть полезной для сравнительного тестирования различных конфигураций. Это может также использоваться, чтобы генерировать демонстрационные пары ключ/значение, которые можно использовать в своем собственном сравнительном тестировании. См. Раздел 15.6.3.3.6, "libmemcached Утилиты Командной строки" для деталей.

14.2.9.5.4. Управление Транзакционным Поведением InnoDB memcached Плагин

В отличие от этого с традиционным memcached, с InnoDB + комбинация memcached, которой можно управлять, насколько "длительный" значения данных, произведенные посредством звонков add, set, incr, и так далее. Поскольку MySQL помещает высокий приоритет в длительность и непротиворечивость данных, по умолчанию все данные, записанные через интерфейс memcached, всегда хранятся к диску, и призывают get всегда возвращайте новое значение из диска. Хотя эта настройка по умолчанию не дает максимально возможную необработанную производительность, это все еще очень быстро по сравнению с традиционным интерфейсом SQL для InnoDB таблицы.

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

Частота Фиксаций

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

Когда memcached работа вызывает вставку, обновление, или удалите в базовом InnoDB таблица, то изменение могло бы посвятить себя базовой таблице немедленно (если daemon_memcached_w_batch_size=1) или некоторое время спустя (если то значение параметра конфигурации больше чем 1). В любом случае не может откатываться изменение. Если Вы увеличиваете значение daemon_memcached_w_batch_size=1 чтобы избежать высоких издержек ввода-вывода в течение напряженного времени, фиксации могли стать очень нечастыми, когда рабочая нагрузка уменьшается. Как мера по безопасности, фоновый поток автоматически фиксирует изменения, произведенные через memcached API равномерно. Интервалом управляют innodb_api_bk_commit_interval параметром конфигурации, и по умолчанию составляют 5 секунд.

Когда memcached работа вызывает вставку или обновление в базовом InnoDB таблица, измененные данные сразу видимы к другим запросам memcached, потому что новое значение остается в кэш-памяти, даже если это еще не фиксируется на стороне MySQL.

Изоляция транзакции

Когда memcached работа такой как get или incr вызывает запрос или работу DML в базовом InnoDB таблица, можно управлять, видит ли она очень последние данные, записанные таблице, только данные, которые фиксировались, или другие изменения уровня изоляции транзакции. Вы управляете этой функцией через innodb_api_trx_level параметр конфигурации. Числовые значения, определенные с этой опцией, соответствуют знакомым именам уровня изоляции такой как REPEATABLE READ. См. описание innodb_api_trx_level опция для полного списка.

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

Разрешение или Отвергание DDL

По умолчанию можно выполнить операции DDL такой как ALTER TABLE на таблицах, используемых InnoDB плагин memcached. Чтобы избежать потенциального замедления, когда эти таблицы используются для приложений высокой пропускной способности, можно отключить операции DDL на этих таблицах, включая innodb_api_enable_mdl параметр конфигурации при запуске. Эта опция является менее соответствующей, когда Вы получаете доступ к тем же самым базовым таблицам и через интерфейс memcached и через SQL, потому что это блокирует CREATE INDEX операторы на таблицах, которые могли быть важными для конфигурирования системы, чтобы выполнить запросы создания отчетов.

Данные, хранившие на Диске, в Памяти, или Обоих

Таблица innodb_memcache.cache_policies определяет, хранить ли данные, записанные через memcached на диске (innodb_only, значение по умолчанию); хранить данные в памяти только, как в традиционном memcached (cache-only); или оба (caching).

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

Кэширующаяся политика может быть установлена независимо для get, set (включая incr и decr), delete, и flush операции. Например:

Вы могли бы позволить get и set операции, чтобы запросить или обновить таблицу и memcached кэш-память одновременно (через caching установка), делая delete, flush, или оба работают только на копии в памяти (через cache_only установка). Тот путь, удаляя или сбрасывая элемент только истекает это от кэша, и последнее значение возвращается из InnoDB представьте в виде таблицы в следующий раз, когда элемент требуют.

mysql> desc innodb_memcache.cache_policies;+---------------+-------------------------------------------------------+------+-----+---------+-------+| Field         | Type                                                  | Null | Key | Default | Extra |+---------------+-------------------------------------------------------+------+-----+---------+-------+| policy_name   | varchar(40)                                           | NO   | PRI | NULL    |       || get_policy    | enum('innodb_only','cache_only','caching','disabled') | NO   |     | NULL    |       || set_policy    | enum('innodb_only','cache_only','caching','disabled') | NO   |     | NULL    |       || delete_policy | enum('innodb_only','cache_only','caching','disabled') | NO   |     | NULL    |       || flush_policy  | enum('innodb_only','cache_only','caching','disabled') | NO   |     | NULL    |       |+---------------+-------------------------------------------------------+------+-----+---------+-------+mysql> select * from innodb_memcache.cache_policies;+--------------+-------------+-------------+---------------+--------------+| policy_name  | get_policy  | set_policy  | delete_policy | flush_policy |+--------------+-------------+-------------+---------------+--------------+| cache_policy | innodb_only | innodb_only | innodb_only   | innodb_only  |+--------------+-------------+-------------+---------------+--------------+mysql> update innodb_memcache.cache_policies set set_policy = 'caching'    -> where policy_name = 'cache_policy';

cache_policies значения только читаются при запуске, и тесно интегрируются с работой memcached плагина. После изменения любого из значений в этой таблице удалите плагин и переустановите это:

mysql> uninstall plugin daemon_memcached;Query OK, 0 rows affected (2.00 sec)mysql> install plugin daemon_memcached soname "libmemcached.so";Query OK, 0 rows affected (0.00 sec)

14.2.9.5.5. Адаптация Операторов DML к memcached Операциям

Сравнительные тесты предполагают что InnoDB плагин memcached убыстряется, операции DML (вставляет, обновляет, и удаляет), больше, чем он ускоряет запросы. Вы могли бы фокусировать свои усилия по начальному развитию на интенсивных записью приложениях, которые являются I/O-bound, и ищут возможности использовать MySQL для новых видов интенсивных записью приложений.

```
INSERT INTO t1 (key,val) VALUES (some_key,some_value);SELECT val FROM t1 WHERE key = some_key;UPDATE t1 SET val = new_value WHERE key = some_key;UPDATE t1 SET val = val + x WHERE key = some_key;DELETE FROM t1 WHERE key = some_key;
```
Единственная строка операторы DML является большинством прямых видов операторов, чтобы превратиться memcached операции: INSERT становится add, UPDATE становится set, incr или decr, и DELETE становится delete. Когда выпущено через интерфейс memcached, эти операции, как гарантируют, будут влиять только на 1 строку потому что key уникально в пределах таблицы.

В предыдущих примерах SQL, t1 обращается к таблице, в настоящий момент используясь InnoDB плагин memcached, основанный на параметрах конфигурации в innodb_memcache.containers таблица, key обращается к столбцу, перечисленному под key_columns, и val обращается к столбцу, перечисленному под value_columns.
```
TRUNCATE TABLE t1;DELETE FROM t1;
```
Соответствует flush_all работа, когда t1 конфигурируется как таблица для memcached операций как в предыдущем шаге. Удаляет все строки в таблице.

14.2.9.5.6. Выполнение DML и Операторов DDL на Базовом`InnoDB` Таблица

Можно получить доступ к таблице InnoDB (по умолчанию, test.demo_test) через стандартные интерфейсы SQL. Однако, есть некоторые ограничения:

Когда запрос таблица через SQL, к которому также получают доступ через интерфейс memcached, помните, что memcached операции могут быть сконфигурированы, чтобы периодически фиксироваться, а не после каждой операции записи. Этим поведением управляют daemon_memcached_w_batch_size опция. Если эта опция устанавливается в значение, больше чем 1, использовать READ UNCOMMITTED запросы, чтобы найти только вставленные строки:
```
mysql> set session TRANSACTION ISOLATION LEVEL read uncommitted;Query OK, 0 rows affected (0.00 sec)mysql> select * from demo_test;+------+------+------+------+-----------+------+------+------+------+------+------+| cx   | cy   | c1   | cz   | c2        | ca   | CB   | c3   | cu   | c4   | C5   |+------+------+------+------+-----------+------+------+------+------+------+------+| NULL | NULL | a11  | NULL | 123456789 | NULL | NULL |   10 | NULL |    3 | NULL |+------+------+------+------+-----------+------+------+------+------+------+------+1 row in set (0.00 sec)
```
Чтобы изменить таблицу через SQL, к которому также получают доступ через интерфейс memcached, помните, что memcached операции могут быть сконфигурированы, чтобы быть, периодически запускают новую транзакцию, а не для каждой операции чтения. Этим поведением управляют daemon_memcached_r_batch_size опция. Если эта опция устанавливается в значение, больше чем 1...
InnoDB таблица является заблокированным IS (совместно использованное намерение) или IX (монопольный намеренный) для всех операций в транзакции. Если Вы увеличиваетесь daemon_memcached_r_batch_size и daemon_memcached_w_batch_size существенно от их значения по умолчанию 1, таблица наиболее вероятно преднамеренно блокируется между каждой работой, препятствуя тому Вам выполнить операторы DDL на таблице.