Каковы характеристики производительности sqlite с очень большими файлами базы данных?

Мы используем DBS 50 GB + на нашей платформе. никаких жалоб не работает. Убедитесь, что вы все делаете правильно! Вы используете предопределенные заявления? * SQLITE 3.7.3

• Сделки
• Предварительно сделанные заявления

• Примените эти настройки (сразу после создания БД)

  PRAGMA main.page_size = 4096;
  PRAGMA main.cache_size=10000;
  PRAGMA main.locking_mode=EXCLUSIVE;
  PRAGMA main.synchronous=NORMAL;
  PRAGMA main.journal_mode=WAL;
  PRAGMA main.cache_size=5000;
  

Надеюсь, это поможет другим, отлично работает здесь.

Я создал базы данных SQLite размером до 3,5 ГБ без заметных проблем с производительностью. Если я правильно помню, я думаю, что SQLite2 мог иметь некоторые более низкие пределы, но я не думаю, что SQLite3 имеет такие проблемы.

В соответствии с страницами SQLite Limits максимальный размер каждой страницы базы данных составляет 32K. Максимальные страницы в базе данных - 1024 ^ 3. Так по моей математике, которая достигает 32 терабайт как максимальный размер. Я думаю, вы попадете в пределы вашей файловой системы, прежде чем ударить SQLite!

Большая часть причин, по которым потребовалось более 48 часов, чтобы сделать ваши вставки, объясняется вашими индексами. Это невероятно быстрее:

1 - Отбросьте все индексы 2 - Сделайте все вставки 3 - Создание индексов снова

Кроме обычной рекомендации:

• Индекс падения для массовой вставки.
• Пакетные вставки/обновления в больших транзакциях.
• Настройте буферный кеш/отключите журнал /w PRAGMA.
• Используйте 64-битную машину (чтобы использовать много кеш-памяти).
• [добавлен июль 2014] Используйте общее табличное выражение (CTE) вместо запуска нескольких SQL-запросов! Требуется выпуск SQLite 3.8.3.

Из моего опыта работы с SQLite3 я узнал следующее:

• Для максимальной скорости вставки не используйте схему с любым ограничением столбца. ( Изменить таблицу позже по мере необходимости Вы не можете добавлять ограничения с помощью ALTER TABLE).
• Оптимизируйте свою схему, чтобы сохранить то, что вам нужно. Иногда это означает разбиение таблиц и/или даже сжатие/преобразование ваших данных перед вставкой в ​​базу данных. Отличным примером является сохранение IP-адресов в виде (длинных) целых чисел.
• Одна таблица на файл db - чтобы минимизировать конфликт блокировок. (Используйте ATTACH DATABASE, если вы хотите иметь один объект подключения.
• SQLite может хранить разные типы данных в одном столбце (динамическая типизация), использовать это в ваших интересах.

Вопрос/комментарий.; -)

Я думаю, что основные жалобы на масштабирование sqlite:

• Отдельная запись процесса.
• Нет зеркального отображения.
• Нет репликации.

У меня есть база данных SQLite объемом 7 ГБ. Для выполнения конкретного запроса с внутренним соединением требуется 2.6 Чтобы ускорить это, я попытался добавить индексы. В зависимости от того, какие индексы я добавил, иногда запрос опускался до 0,1 с, а иногда он увеличивался до 7 с. Я думаю, что проблема в моем случае заключалась в том, что если столбец сильно дублируется, то добавление индекса ухудшает производительность: (

В документации SQLite раньше указывалось, что практический размер файла базы данных составляет несколько десятков ГБ: с. В основном это связано с необходимостью SQLite "распределять битмап грязных страниц" всякий раз, когда вы начали транзакцию. Таким образом, 256 байт ОЗУ были необходимы для каждого МБ в базе данных. Вставка в DB файл объемом 50 ГБ потребует массивного (2 ^ 8) * (2 ^ 10) = 2 ^ 18 = 256 МБ ОЗУ.

Но по последним версиям SQLite это больше не требуется. Подробнее здесь.

У меня возникли проблемы с большими файлами sqlite при использовании команды вакуума.

Я еще не пробовал функцию auto_vacuum. Если вы планируете регулярно обновлять и удалять данные, то это стоит посмотреть.