Выполняет ли SQLite активность диска при вызове операторов SELECT с отключенным AutoCommit в perl?

Question

Я создал новую базу данных SQLite в файле на диске с отключенным AutoCommit, используя:

my $dsn      = "dbi:SQLite:dbname=folder/path/file.db";
my $user     = "";
my $password = "";
my $dbh = DBI->connect($dsn, $user, $password,{AutoCommit => 0});

#… Doing some processing on the database (Creating tables/Inserting rows/Updating fields)

#… Many query SELECT statements here
    # My question here: Does SQLite read data from memory or disk each time a SELECT statement is performed.

При запросе данных (с помощью операторов SELECT SQL) SQLite считывает данные из файла или памяти на диске?Выполняет ли SQLite какую-либо активность на диске (которая ниже по производительности, чем активность оперативной памяти)?

---

Примечания:

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

Примечание: Моя созданная база данных не станет слишком большой, поэтому я не беспокоюсь опроблема с заполнением моей базы данных.

Если SQLite читает данные с диска каждый раз, когда вызывается оператор запроса SELECT, то это приведет к огромному отставанию производительности по сравнению с копированием БД в памятьРешение, упомянутое в моем предыдущем вопросе .

---

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

Answer 1

В общем, да.

SQLite не загружает всю базу данных в память на connect.Действительно, база данных может быть намного больше памяти - базы данных SQLite имеют максимальный размер примерно 140 ТБ.SQLite будет кэшировать некоторые недавно использованные данные в памяти, но большинство запросов в большой базе данных попадут на диск (или в кэш диска ОС).

Answer 2

В общем, да, если ваша база данных находится на диске, то доступ к диску будет осуществляться для выполнения любых SELECT, если только необходимые данные не буферизуются в памяти где-либо (скорее всего, либо внутри самого SQLite, либо в кеше диска).

Но обратите внимание на фразу «, если ваша база данных находится на диске ».SQLite также поддерживает базы данных в памяти.Если у вас достаточно свободной оперативной памяти для хранения базы данных, и если вы собираетесь выполнять с ней достаточно операций, чтобы компенсировать затраты на ее копирование в память, это может стоить изучить.

Вместо настройки в вопросе вы можете:

my $dbh = DBI->connect('dbi:SQLite:dbname=:memory:');
$dbh->sqlite_backup_from_file('folder/path/file.db');

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

Если вы вносите какие-либо изменения в базу данных в памяти, вам также потребуется

$dbh->sqlite_backup_to_file('folder/path/file.db');

перед $dbh отключается, если вы хотите сохранить эти изменения обратно на диск.

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

Answer 3

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

Недостатком этого вопроса является то, что он пахнет преждевременной оптимизации. Оцените свои подходы и посмотрите, какой из них выиграет в вашем конкретном приложении.