Каждый обеспокоен производительностью своей базы данных и, в частности, запросами к своей базе данных. Независимо от того, насколько быстро работает ваше оборудование или какая база данных, оптимизация запросов по-прежнему дает очень существенные преимущества в производительности. Определение того, какие запросы требуют оптимизации, может быть сложной задачей. У NuoDB есть решение — фактически два полезных решения — оба новые в NuoDB Starlings 1.1 . Во-первых, если вы хотите узнать, какой из ваших завершенных запросов занял слишком много времени, посмотрите таблицу SYSTEM.QUERYSTATS в NuoDB. По умолчанию NuoDB будет хранить десять самых медленных запросов, выполнение которых заняло более десяти секунд. Это, конечно, настраивается. Во-вторых, если вы хотите узнать состояние производительности выполняемых в данный момент запросов, NuoDB предоставляет таблицу SYSTEM.CONNECTIONS.
SYSTEM.QUERYSTATS
Давайте посмотрим на SYSTEM.PROPERTIES для настройки, какие запросы будут регистрироваться в таблице QUERYSTATS.
SQL> select * from SYSTEM.PROPERTIES;
PROPERTY VALUE
--------------- ------
MAX_QUERY_COUNT 10
MIN_QUERY_TIME 10
MAX_QUERY_COUNT в SYSTEM.PROPERTIES сообщает NuoDB максимальное количество запросов для регистрации. MIN_QUERY_TIME — это минимальное время выполнения запроса, чтобы сделать его пригодным для ведения журнала. MIN_QUERY_TIME может быть десятичным значением, поэтому оно может быть выражено с интервалами в секунду. Чтобы динамически изменить одно из этих значений, используйте команду UPDATE в сеансе клиента. SYSTEM.PROPERTIES — это постоянная таблица, доступная для всего хора и от одного сеанса клиента до следующего.
Чтобы найти самые медленные запросы, выполните простой выбор из SYSTEM.QUERYSTATS.
SQL> select * from SYSTEM.QUERYSTATS;
SQLSTRING COUNT RUNTIME USER SCHEMA NUMPARAM PARAMS NODEID NROWS UNIQUEID TIMESTAMP
-------------------------------------- ------ -------- ----- ------- --------- ----------- ------- ------ --------- --------------------------
select * from t where x=?; 1 13010424 CLOUD USER 1 0/string/2 1 1 4 2013-04-23 12:29:53.512637
select s from t2 join t3 on t2.s=t3.s; 1 14013823 CLOUD USER 0 2 1 2 2013-04-23 12:52:54.830913
NB. В приведенной выше таблице вам нужно будет прокрутить вправо, чтобы увидеть все содержимое.
Это даст вам строку SQL для запроса, количество выполнений запроса, время выполнения запроса в микросекундах (здесь преувеличено для примера, к сведению!), Информацию о пользователе, схему и любые параметры, а также как другая информация. TIMESTAMP — время начала запроса. Эта таблица является одной из нескольких «псевдо» таблиц, реализованных в NuoDB. Это временная таблица, создаваемая на лету, каждый раз, когда вы запрашиваете у нее. Его содержимое всегда соответствует моменту времени, когда был выполнен запрос.
Обратите внимание, что NODEID в SYSTEM.QUERYSTATS выше отличается для двух перечисленных запросов. Как правило, это не касается большинства пользователей NuoDB, но говорит о том, что запросы выполняются на отдельных ядрах транзакций NuoDB. Если NODEID был одинаковым для всех медленных запросов, то это могло бы указывать на проблему производительности оборудования, где бы ни размещался этот узел, а не на запрос, требующий оптимизации. Пользователь может выполнить «select * from SYSTEM.NODES» (другая псевдотаблица), чтобы увидеть информацию о каждом узле в хоре. Столбец NODEID в SYSTEM.QUERYSTATS соответствует столбцу NODEID в SYSTEM.NODES, поэтому здесь вы можете узнать IP-адрес и номер порта для TE, на котором выполняется запрос.
Помните, что SYSTEM.QUERYSTATS является переходной таблицей, и когда NuoDB Transaction Engine завершает работу, медленные запросы, выполненные для этого Transaction Engine, больше не будут отображаться в таблице QUERYSTATS.
SYSTEM.CONNECTIONS
NuoDB также предоставляет механизм анализа запросов в реальном времени. SYSTEM.CONNECTIONS — это еще одна псевдо-таблица NuoDB, временная таблица, создаваемая на лету, когда вы запрашиваете ее. Это сообщит обо всех запущенных в данный момент запросах в вашей базе данных. Когда вышеупомянутые запросы из QUERYSTATS все еще выполнялись, они были бы зарегистрированы в таблице CONNECTIONS следующим образом:
SQL> select * from SYSTEM.CONNECTIONS;
SQLSTRING COUNT RUNTIME USER SCHEMA NUMPARAM PARAMS NODEID CONNID OPEN HANDLE NODEID EXECID
-------------------------------------- ------ -------- ----- ------- --------- ----------- ------- ------ ---- ------ ------ --------------------
select * from t where x=?; 1 13010424 CLOUD USER 1 0/string/2 1 2 1 3 1 55340232229718589441
select s from t2 join t3 on t2.s=t3.s; 1 14013823 CLOUD USER 0 2 3 1 1 2 18446744086594453505
NB. В приведенной выше таблице вам нужно будет прокрутить вправо, чтобы увидеть все содержимое.
Это дает ту же информацию, что и в таблице SYSTEM.QUERYSTATS. Он включает в себя CONNID, OPEN и HANDLE, которые в комбинации однозначно идентифицируют каждый оператор SQL и могут использоваться в качестве параметров команды KILL STATEMENT . EXECID — это идентификатор, созданный из CONNID, OPEN и HANDLE, который также предоставляет уникальный способ идентификации вашего оператора SQL и может быть скопирован и вставлен в качестве аргумента в команду KILL STATEMENT.
Все псевдотаблицы могут быть доступны по одному или нескольким столбцам, как и любая другая таблица. Полезный, простой запрос для анализа текущих запущенных запросов:
SQL> select SQLSTRING,RUNTIME from SYSTEM.CONNECTIONS;
SQLSTRING RUNTIME
-------------------------------------- --------
select * from t where x=?; 13010424
select s from t2 join t3 on t2.s=t3.s; 14013823
Больше «псевдо» столов
Выполнение запросов в распределенной среде, подобной нашей, усложняет создание этих псевдотаблиц. Один Transaction Engine получает запрос от клиента, а затем должен отправить сообщения всем остальным узлам в хоре, чтобы получить информацию о выполняющихся там запросах. Он ожидает ответов от каждого узла в хоре и затем отображает результаты клиенту. Возможность запрашивать каждый узел в хоре NuoDB, ждать ответов и сообщать результаты в псевдотаблице — это мощный инструмент, который позволяет нам собирать все виды полезной информации из хора NuoDB. Оставайтесь с нами для более полезных псевдо-таблиц NuoDB!