Я испортил свой диск, используя sqlite?

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

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

Что меня беспокоит, так это то, что каждая фиксация является фактической записью на диск. С чем-то вроде миллиона запросов мой SSD преждевременно устареет :/ Итак, в основном, два вопроса:

  1. Действительно ли это означает, что 1 фиксация = 1 запись на физический диск? Или в SQLite есть буферизация, или Linux делает что-то подобное, или, может быть, сам контроллер SSD хранит копию базы данных в ОЗУ (или памяти контроллера) и лишь изредка синхронизируется с диском? Сама база данных меньше 20 МБ.

  2. Если я этого боюсь, какие-либо настройки, которые я мог бы внести в sqlite3, или неизбежна ли база данных сервер-клиент? Насколько я понимаю, сервер базы данных будет иметь эксклюзивный доступ к базе данных, поэтому он может просто хранить рабочую версию в ОЗУ и регулярно синхронизироваться с диском.

Прошу прощения, вопрос больше дискуссионный :/


database sqlite android-sqlite solid-state-drive
person Liudvikas Akelis    schedule 03.06.2017    source источник
comment
Я хочу, если это возможно, избежать ненужной очистки, поэтому я делаю коммит после каждого результата, чтобы другие процессы знали, что этот результат не следует очищать . сохранить URL-адреса с флагом, указывающим, были ли они уже очищены (url, scrapped), и заблокировать их для записи, когда вы выбираете их таким образом 1- lock the url rows, 2-select the url rows 3-scrape them 4-set the flag for them 5-release the lock   -  person Accountant م    schedule 18.01.2019

Ответы (3)


arrow_upward
2
arrow_downward

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

Затем посмотрите выносливость вашего SSD при записи в таблице данных. Затем поймите, что ничтожный миллион записей, которые вы делаете «время от времени», совершенно безвредны.

Чтобы сделать вашу базу данных более удобной для SSD, вы можете включить режим WAL. Но если вы не работаете с базой данных круглосуточно и без выходных, вы не заметите никакой разницы.

person CL.    schedule 03.06.2017

arrow_upward
2
arrow_downward

С тех пор я нашел обходной путь, который работает для меня: настроить базу данных в ОЗУ (в Linux одним из таких мест является /dev/shm, и я полагаю, что в Windows также есть аналогичные утилиты).

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

while true; do sleep 20; cp /dev/shm/results.db ~/project/results.db; done

Это не идеальное долгосрочное решение, но оно определенно работает без модификаций и может значительно увеличить скорость.

person Liudvikas Akelis    schedule 22.05.2018
comment
Копирование файла базы данных без копирования журнала или файла Wal может привести к повреждению. API резервного копирования позволяет избежать этого риска. sqlite.org/backup.html - person Ben Page; 15.09.2020

arrow_upward
0
arrow_downward

Это немного долго для комментария. И я не очень хорошо знаком с самыми последними достижениями в технологии SSD. Но у вас есть обоснованная озабоченность.

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

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

Что ты можешь сделать? Мой совет: неукоснительно делайте резервную копию базы данных, следите за своим оборудованием и обновляйте его по мере необходимости. Кстати, этот совет не зависит от использования баз данных или твердотельных накопителей.

person Gordon Linoff    schedule 03.06.2017