Spec-Zone .ru
спецификации, руководства, описания, API
|
Как правило, при записи приложения для InnoDB
интерфейс memcached включает определенную степень перезаписи или адаптации
существующего кода, который использует MySQL или memcached API:
Вместо многих memcached серверов, работающих на маломощных машинах, у Вас есть то же самое число memcached серверов как серверы MySQL, работая на относительно мощных машинах с существенной памятью на диске и памятью. Вы могли бы снова использовать некоторый существующий код, который работает с memcached API, но некоторая адаптация, вероятно, необходима из-за различной конфигурации сервера.
Данные, хранившие через этот интерфейс, все входит VARCHAR
, TEXT
, или BLOB
столбцы, и должны быть преобразованы, чтобы сделать числовые
операции. Можно сделать преобразование на стороне приложения, или при использовании CAST()
функция в запросах.
Происходя из среды базы данных, Вы могли бы привыкнуть к таблицам SQL общего назначения со многими столбцами. Таблицы, к которым получает доступ memcached, кодируют, вероятно, имеют только некоторых или даже только единственный столбец, содержащий значения данных.
Вы могли бы адаптировать части своего приложения, которые делают запросы единственной строки, вставляет, обновляет, или удаляет, чтобы сжать больше производительности из критических разделов кода. Оба запроса (читают) и DML (запись), операции могут быть существенно быстрее когда выполняющийся через интерфейс memcached. Ускорение для записей обычно больше чем ускорение для чтений, таким образом, Вы могли бы сосредоточиться на том, чтобы адаптировать код, который выполняет журналирование или записывает интерактивные варианты на веб-сайте.
Следующие разделы исследуют эти аспекты более подробно.
Полагайте, что эти аспекты 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 @@
в пределах приложения, чтобы переключить
таблицу, используемую для последующих запросов через memcached API. name
Для примера использования таблицы кроме предопределенного 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)
Рассмотрите эти аспекты MySQL и InnoDB
таблицы, адаптируя существующее memcached приложение, чтобы использовать интеграцию MySQL:
Если у Вас есть значения ключа дольше чем несколько байтов, Вы могли бы счесть
более эффективным использовать числовой столбец автоприращения для первичного
ключа в InnoDB
таблица, и создает уникальное вторичное
устройство, индексируют на столбце, содержащем memcached значения ключа. Это то, потому что InnoDB
выполняет лучше всего для крупномасштабных вставок, если
значения первичного ключа добавляются в сортированном порядке (как они с автоинкрементными
значениями), и значения первичного ключа дублируются в каждом вторичном устройстве, индексируют,
который может занять ненужное место, когда первичный ключ является длинным строковым значением.
Если Вы храните несколько различных классов информации в memcached,
Вы могли бы установить отдельное InnoDB
таблица для каждого вида
данных. Определите дополнительные табличные идентификаторы в innodb_memcache.containers
таблица, и использование нотация @@
сохранить или получить элементы от различных таблиц. Физически деление элементов позволяет Вам
настраивать характеристики каждой таблицы для лучшего использования пространства,
производительности, и надежности. Например, Вы могли бы включить сжатию
для таблицы, которая содержит сообщения в блоге, но не для того, который содержит изображения
миниатюры. Вы могли бы поддерживать одну таблицу более часто чем другой, потому что она содержит
критические данные. Вы могли бы создать дополнительное вторичное
устройство, индексирует на таблицах, которые часто используются, чтобы генерировать отчеты
через SQL. table_id
.key
Предпочтительно, установите устойчивое множество табличных определений для
использования с memcached, соединяют интерфейсом и
оставляют их на месте постоянно. Изменения к containers
таблица
вступает в силу в следующий раз, когда таблица запрашивается. Записи в той таблице обрабатываются
при запуске, и консультируются всякий раз, когда нераспознанный табличный ID требуют @@
нотация. Таким образом новые записи видимы, как только Вы
пытаетесь использовать связанный табличный ID, но изменяется на существующие записи, требуют
перезапуска сервера прежде, чем они вступят в силу.
Когда Вы используете политику кэширования значения по умолчанию innodb_only
, Ваши звонки add()
, set()
, incr()
, и так далее может следовать,
но все еще инициировать отладочные сообщения такой как while expecting
'STORED', got unexpected response 'NOT_STORED
. Это то, потому что в innodb_only
конфигурация, новые и обновленные значения отправляются
непосредственно InnoDB
таблица, не будучи сохраненным в кэш-памяти.
Поскольку использование InnoDB
в комбинации с memcached
включает запись, что все данные к диску, или сразу или когда-то позже, понимают, что необработанная
производительность, как ожидают, будет несколько ниже чем использование memcached
отдельно. Фокусируйте свои настраивающие цели для InnoDB
плагин memcached при достижении более высокой производительности
чем эквивалентные операции SQL.
Сравнительные тесты предполагают, что оба запроса и операции DML (вставляет, обновления, и удаляет), быстрее проходят через интерфейс memcached чем с традиционным SQL. Операции DML обычно видят большее ускорение. Таким образом типы приложений, которые Вы могли бы адаптировать, чтобы использовать интерфейс memcached сначала, являются теми, которые интенсивны записью. Вы могли бы также использовать MySQL в качестве хранилища данных для типов интенсивных записью приложений, которые прежде использовали некоторый быстрый, легкий механизм, где надежность не была приоритетом.
Типы запросов, которые больше всего подходят для простого 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 Утилиты Командной строки" для деталей.
В отличие от этого с традиционным 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
такой как 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)
Сравнительные тесты предполагают что 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
операций как в предыдущем шаге. Удаляет все строки в таблице.
Можно получить доступ к таблице 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 на
таблице.