Улучшить производительность вставки в секунду SQLite?

оптимизация SQLite сложно. Производительность объемной вставки приложения C может варьироваться от 85 вставок в секунду до более 96 000 вставок в секунду!

Справочная информация: мы используем SQLite как часть настольного приложения. У нас есть большие объемы данных конфигурации, хранящихся в XML-файлах, которые анализируются и загружаются в базу данных SQLite для дальнейшей обработки при инициализации приложения. SQLite не подходит для этой ситуации, потому что это быстро, это не требует специальной настройки, и база данных хранится на диске в виде одного файла.

обоснование: Первоначально я был разочарован выступлением, которое я видел. оказывается, что производительность SQLite может значительно отличаться (как для массовых вставок, так и для выбора) в зависимости от того, как настроена база данных и как вы используете API. Это был не тривиальный вопрос, чтобы выяснить, какие все варианты и методы были, поэтому я подумал разумно создать эту запись сообщества wiki, чтобы поделиться результатами с читателями переполнения стека, чтобы избавить других от проблем тех же исследований.

Эксперимент: вместо того, чтобы просто говорить о советах по производительности в общем смысле (т. е. "использовать транзакцию!"), я подумал, что лучше написать код C и на самом деле мера влияние различных вариантов. Начнем с простого. данные:

• текстовый файл с разделителями табуляции 28 МБ (приблизительно 865 000 записей)полный транзитный график для города Торонто
• моя тестовая машина-это 3.60 GHz P4 под управлением Windows XP.
• код компилируется с помощью Visual C++ 2005 как "релиз" с "полной оптимизацией" (/Ox) и Favor Fast Code (/Ot).
• я использую SQLite "Amalgamation", скомпилированный непосредственно в мое тестовое приложение. Этот Версия SQLite у меня немного старше (3.6.7), но я подозреваю, что эти результаты будут сопоставимы с последней версией (пожалуйста, оставьте комментарий, если вы думаете иначе).

давайте напишем код!

Код: простая программа C, которая читает текстовый файл строка за строкой, разбивает строку на значения, а затем вставляет данные в базу данных SQLite. В этой "базовой" версии кода создается база данных, но мы не будем вставлять данные:

/*************************************************************
    Baseline code to experiment with SQLite performance.

    Input data is a 28 MB TAB-delimited text file of the
    complete Toronto Transit System schedule/route info
    from http://www.toronto.ca/open/datasets/ttc-routes/

**************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <string.h>
#include "sqlite3.h"

#define INPUTDATA "C:TTC_schedule_scheduleitem_10-27-2009.txt"
#define DATABASE "c:TTC_schedule_scheduleitem_10-27-2009.sqlite"
#define TABLE "CREATE TABLE IF NOT EXISTS TTC (id INTEGER PRIMARY KEY, Route_ID TEXT, Branch_Code TEXT, Version INTEGER, Stop INTEGER, Vehicle_Index INTEGER, Day Integer, Time TEXT)"
#define BUFFER_SIZE 256

int main(int argc, char **argv) {

    sqlite3 * db;
    sqlite3_stmt * stmt;
    char * sErrMsg = 0;
    char * tail = 0;
    int nRetCode;
    int n = 0;

    clock_t cStartClock;

    FILE * pFile;
    char sInputBuf [BUFFER_SIZE] = "";

    char * sRT = 0;  /* Route */
    char * sBR = 0;  /* Branch */
    char * sVR = 0;  /* Version */
    char * sST = 0;  /* Stop Number */
    char * sVI = 0;  /* Vehicle */
    char * sDT = 0;  /* Date */
    char * sTM = 0;  /* Time */

    char sSQL [BUFFER_SIZE] = "";

    /*********************************************/
    /* Open the Database and create the Schema */
    sqlite3_open(DATABASE, &db);
    sqlite3_exec(db, TABLE, NULL, NULL, &sErrMsg);

    /*********************************************/
    /* Open input file and import into Database*/
    cStartClock = clock();

    pFile = fopen (INPUTDATA,"r");
    while (!feof(pFile)) {

        fgets (sInputBuf, BUFFER_SIZE, pFile);

        sRT = strtok (sInputBuf, "t");     /* Get Route */
        sBR = strtok (NULL, "t");            /* Get Branch */
        sVR = strtok (NULL, "t");            /* Get Version */
        sST = strtok (NULL, "t");            /* Get Stop Number */
        sVI = strtok (NULL, "t");            /* Get Vehicle */
        sDT = strtok (NULL, "t");            /* Get Date */
        sTM = strtok (NULL, "t");            /* Get Time */

        /* ACTUAL INSERT WILL GO HERE */

        n++;
    }
    fclose (pFile);

    printf("Imported %d records in %4.2f secondsn", n, (clock() - cStartClock) / (double)CLOCKS_PER_SEC);

    sqlite3_close(db);
    return 0;
}

"Управления"

запуск кода как есть фактически не выполняет никаких операций с базой данных, но это даст нам представление о том, насколько быстры операции ввода-вывода файлов raw C и обработки строк.

импортированные записи 864913 в 0.94 секунды!--23-->

великолепно! Мы можем делать 920,000 вставок в секунду, при условии, что мы на самом деле не делаем никаких вставок :-)

"Худший Сценарий"

мы собираемся создать строку SQL, используя значения, считанные из файла, и вызвать эту операцию SQL с помощью sqlite3_exec:

sprintf(sSQL, "INSERT INTO TTC VALUES (NULL, '%s', '%s', '%s', '%s', '%s', '%s', '%s')", sRT, sBR, sVR, sST, sVI, sDT, sTM);
sqlite3_exec(db, sSQL, NULL, NULL, &sErrMsg);

это будет медленно, потому что SQL будет скомпилирован в код VDBE для каждой вставки, и каждая вставка будет происходить в своей собственной транзакции. как медленно?

импортированные записи 864913 в 9933.61 секунды!--23-->

хлоп! 2 часа 45 минут! Вот только 85 вставок в секунду.

С помощью операции

по умолчанию SQLite будет оценивать каждый оператор INSERT / UPDATE в уникальной транзакции. При выполнении большого количества вставок рекомендуется обернуть операцию в транзакцию:

sqlite3_exec(db, "BEGIN TRANSACTION", NULL, NULL, &sErrMsg);

pFile = fopen (INPUTDATA,"r");
while (!feof(pFile)) {

    ...

}
fclose (pFile);

sqlite3_exec(db, "END TRANSACTION", NULL, NULL, &sErrMsg);

импортированные записи 864913 в 38.03 секунды!--23-->

что лучше. Просто упаковка всех наших вставок в одной транзакции улучшила нашу производительность до 23,000 вставок в секунду.

используя подготовленное заявление

использование транзакции было огромным улучшением, но перекомпиляция оператора SQL для каждой вставки не имеет смысла, если мы используем один и тот же SQL снова и снова. Давайте использовать sqlite3_prepare_v2 чтобы скомпилировать наш оператор SQL один раз, а затем привязать наши параметры к этому оператору, используя sqlite3_bind_text:

/* Open input file and import into the database */
cStartClock = clock();

sprintf(sSQL, "INSERT INTO TTC VALUES (NULL, @RT, @BR, @VR, @ST, @VI, @DT, @TM)");
sqlite3_prepare_v2(db,  sSQL, BUFFER_SIZE, &stmt, &tail);

sqlite3_exec(db, "BEGIN TRANSACTION", NULL, NULL, &sErrMsg);

pFile = fopen (INPUTDATA,"r");
while (!feof(pFile)) {

    fgets (sInputBuf, BUFFER_SIZE, pFile);

    sRT = strtok (sInputBuf, "t");   /* Get Route */
    sBR = strtok (NULL, "t");        /* Get Branch */
    sVR = strtok (NULL, "t");        /* Get Version */
    sST = strtok (NULL, "t");        /* Get Stop Number */
    sVI = strtok (NULL, "t");        /* Get Vehicle */
    sDT = strtok (NULL, "t");        /* Get Date */
    sTM = strtok (NULL, "t");        /* Get Time */

    sqlite3_bind_text(stmt, 1, sRT, -1, SQLITE_TRANSIENT);
    sqlite3_bind_text(stmt, 2, sBR, -1, SQLITE_TRANSIENT);
    sqlite3_bind_text(stmt, 3, sVR, -1, SQLITE_TRANSIENT);
    sqlite3_bind_text(stmt, 4, sST, -1, SQLITE_TRANSIENT);
    sqlite3_bind_text(stmt, 5, sVI, -1, SQLITE_TRANSIENT);
    sqlite3_bind_text(stmt, 6, sDT, -1, SQLITE_TRANSIENT);
    sqlite3_bind_text(stmt, 7, sTM, -1, SQLITE_TRANSIENT);

    sqlite3_step(stmt);

    sqlite3_clear_bindings(stmt);
    sqlite3_reset(stmt);

    n++;
}
fclose (pFile);

sqlite3_exec(db, "END TRANSACTION", NULL, NULL, &sErrMsg);

printf("Imported %d records in %4.2f secondsn", n, (clock() - cStartClock) / (double)CLOCKS_PER_SEC);

sqlite3_finalize(stmt);
sqlite3_close(db);

return 0;

импортированные записи 864913 в 16.27 секунды!--23-->

приятно! Там немного больше кода (не забудьте позвонить sqlite3_clear_bindings и sqlite3_reset), но мы более чем удвоили нашу производительность 53,000 вставок в секунду.

Pragma synchronous = OFF

по умолчанию SQLite приостанавливается после выполнения команды записи на уровне ОС. Это гарантирует, что данные будут записаны на диск. Установив synchronous = OFF, мы инструктируем SQLite просто передать данные в ОС для записи, а затем продолжить. Существует вероятность того, что файл базы данных может быть поврежден, если компьютер терпит катастрофический сбой (или сбой питания), прежде чем данные будут записаны на блюдо:

/* Open the database and create the schema */
sqlite3_open(DATABASE, &db);
sqlite3_exec(db, TABLE, NULL, NULL, &sErrMsg);
sqlite3_exec(db, "PRAGMA synchronous = OFF", NULL, NULL, &sErrMsg);

импортированные записи 864913 в 12.41 секунды!--23-->

улучшения теперь меньше, но мы до 69,600 вставки в второй.

PRAGMA journal_mode = память

рассмотрите возможность хранения журнала отката в памяти, оценив PRAGMA journal_mode = MEMORY. Ваша транзакция будет быстрее, но если вы потеряете питание или ваша программа выйдет из строя во время транзакции, вы можете оставить базу данных в поврежденном состоянии с частично завершенной транзакцией:

/* Open the database and create the schema */
sqlite3_open(DATABASE, &db);
sqlite3_exec(db, TABLE, NULL, NULL, &sErrMsg);
sqlite3_exec(db, "PRAGMA journal_mode = MEMORY", NULL, NULL, &sErrMsg);

импортированные записи 864913 в 13.50 секунды!--23-->

немного медленнее, чем предыдущий оптимизация на 64,000 вставок в секунду.

Pragma synchronous = OFF и PRAGMA journal_mode = память

давайте объединим предыдущие две оптимизации. Это немного более рискованно (в случае сбоя), но мы просто импортируем данные (не запускаем банк):

/* Open the database and create the schema */
sqlite3_open(DATABASE, &db);
sqlite3_exec(db, TABLE, NULL, NULL, &sErrMsg);
sqlite3_exec(db, "PRAGMA synchronous = OFF", NULL, NULL, &sErrMsg);
sqlite3_exec(db, "PRAGMA journal_mode = MEMORY", NULL, NULL, &sErrMsg);

импортированные записи 864913 в 12.00 секунды!--23-->

фантастика! Мы в состоянии сделать 72,000 вставки в второй.

использование базы данных в памяти

просто для удовольствия, давайте построим на всех предыдущих оптимизациях и переопределим имя файла базы данных, чтобы мы работали полностью в ОЗУ:

#define DATABASE ":memory:"

импортированные записи 864913 в 10.94 секунды!--23-->

это не супер-практично хранить нашу базу данных в ОЗУ, но впечатляет, что мы можем выполнить 79,000 вставки в второй.

Рефакторинг Кода C

хотя и не специально улучшение SQLite, мне не нравится extra char* операции назначения в while петли. Давайте быстро рефакторинг кода, чтобы пройти вывод strtok() непосредственно в sqlite3_bind_text(), и пусть компилятор попытается ускорить работу для нас:

pFile = fopen (INPUTDATA,"r");
while (!feof(pFile)) {

    fgets (sInputBuf, BUFFER_SIZE, pFile);

    sqlite3_bind_text(stmt, 1, strtok (sInputBuf, "t"), -1, SQLITE_TRANSIENT); /* Get Route */
    sqlite3_bind_text(stmt, 2, strtok (NULL, "t"), -1, SQLITE_TRANSIENT);    /* Get Branch */
    sqlite3_bind_text(stmt, 3, strtok (NULL, "t"), -1, SQLITE_TRANSIENT);    /* Get Version */
    sqlite3_bind_text(stmt, 4, strtok (NULL, "t"), -1, SQLITE_TRANSIENT);    /* Get Stop Number */
    sqlite3_bind_text(stmt, 5, strtok (NULL, "t"), -1, SQLITE_TRANSIENT);    /* Get Vehicle */
    sqlite3_bind_text(stmt, 6, strtok (NULL, "t"), -1, SQLITE_TRANSIENT);    /* Get Date */
    sqlite3_bind_text(stmt, 7, strtok (NULL, "t"), -1, SQLITE_TRANSIENT);    /* Get Time */

    sqlite3_step(stmt);        /* Execute the SQL Statement */
    sqlite3_clear_bindings(stmt);    /* Clear bindings */
    sqlite3_reset(stmt);        /* Reset VDBE */

    n++;
}
fclose (pFile);

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

импортированные записи 864913 в 8.94 секунды!--23-->

небольшой рефакторинг кода обработки строк, используемого в нашей привязке параметров, позволил нам выполнить 96,700 вставок в секунду. я думаю, можно с уверенностью сказать, что это быстро. Когда мы начинаем настраивать другие переменные (например, размер страницы, создание индекса и т. д.) это будет нашим ориентиром.

резюме (so далеко)

надеюсь, ты все еще со мной! причина, по которой мы начали этот путь, заключается в том, что производительность массовой вставки сильно варьируется с SQLite, и не всегда очевидно, какие изменения необходимо внести, чтобы ускорить нашу работу. Используя тот же компилятор (и параметры компилятора), ту же версию SQLite и те же данные, мы оптимизировали наш код и наше использование SQLite для go от наихудшего сценария 85 вставок в секунду до более 96 000 вставок в секунду второй!

CREATE INDEX затем INSERT vs. INSERT затем CREATE INDEX

прежде чем мы начнем измерения SELECT производительность, мы знаем, что мы будем создавать индексы. В одном из ответов ниже было предложено, что при выполнении массовых вставок быстрее создавать индекс после вставки данных (в отличие от создания индекса сначала, а затем вставки данных). Попробуем:

создать индекс после вставки Данные

sqlite3_exec(db, "CREATE  INDEX 'TTC_Stop_Index' ON 'TTC' ('Stop')", NULL, NULL, &sErrMsg);
sqlite3_exec(db, "BEGIN TRANSACTION", NULL, NULL, &sErrMsg);
...

импортированные записи 864913 в 18.13 секунды!--23-->

вставьте данные, затем создайте индекс

...
sqlite3_exec(db, "END TRANSACTION", NULL, NULL, &sErrMsg);
sqlite3_exec(db, "CREATE  INDEX 'TTC_Stop_Index' ON 'TTC' ('Stop')", NULL, NULL, &sErrMsg);

импортированные записи 864913 в 13.66 секунды!--23-->

как и ожидалось, массовые вставки медленнее, если один столбец индексируется, но это имеет значение, если индекс создается после вставки данных. Наша базовая линия no-index составляет 96,000 вставок в секунду. создание индекса сначала, а затем вставка данных дает нам 47,700 вставок в секунду, тогда как вставка данных сначала, а затем создание индекса дает нам 63,300 вставок в секунду.

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