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

Я знаю, что sqlite не очень хорошо работает с чрезвычайно большими файлами базы данных, даже когда они поддерживаются (на сайте sqlite был комментарий, в котором указано, что если вам нужны размеры файлов выше 1 ГБ, вы можете рассмотреть возможность использования корпоративного rdbms. ‘t найти его больше, может быть связано с более старой версией sqlite).

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

Я говорю о файлах данных sqlite в диапазоне от нескольких гигабайт, начиная с 2 ГБ. У кого-нибудь есть опыт? Любые советы / идеи?

Поэтому я сделал несколько тестов с sqlite для очень больших файлов и сделал некоторые выводы (по крайней мере, для моего конкретного приложения).

Тесты include один файл sqlite с одной таблицей или несколькими таблицами. В каждой таблице было около 8 столбцов, почти всех целых чисел и 4 индекса.

Идея заключалась в том, чтобы вставить достаточное количество данных, пока файлы sqlite не составят около 50 ГБ.

Одноместный стол

Я попытался вставить несколько строк в файл sqlite только с одной таблицей. Когда файл был около 7 ГБ (извините, я не могу быть конкретным в отношении количества строк), вставки занимали слишком много времени. Я подсчитал, что мой тест на вставку всех моих данных займет около 24 часов, но он не завершился даже через 48 часов.

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

Я думаю, это не удивительно, так как таблица становится больше, вставка и обновление всех индексов занимает больше времени.

Несколько таблиц

Затем я попытался разбить данные по времени на несколько таблиц, по одной таблице в день. Данные для исходной 1 таблицы были разделены на ~ 700 таблиц.

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

Вакуумные проблемы

Как указано i_like_caffeine, команда VACUUM является проблемой, тем больше файл sqlite. По мере того, как будет выполнено больше вложений / удалений, fragmentация файла на диске будет ухудшаться, поэтому задача состоит в периодическом VACUUM для оптимизации файла и восстановления файлового пространства.

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

Выводы

Для моего конкретного приложения я, вероятно, буду раскалывать данные по нескольким файлам db, по одному в день, чтобы получить максимум от производительности вакуума и скорости вставки / удаления.

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

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

Очень жаль, что, похоже, не существует дополнительного метода вакуума, кроме автоматического вакуума . Я не могу использовать его, потому что моя цель для вакуума – деfragmentировать файл (файловое пространство не является большим делом), которого автоматический вакуум не делает. Фактически, документация утверждает, что это может сделать fragmentацию еще хуже, поэтому мне приходится прибегать к периодическому заполнению полного вакуума в файле.

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

  1. операции
  2. Предварительные заявления
  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» максимальный размер каждой страницы базы данных составляет 32 КБ. Максимальные страницы в базе данных – 1024 ^ 3. Так по моей математике, которая достигает 32 терабайт как максимальный размер. Я думаю, вы попадете в пределы вашей файловой системы, прежде чем нанести удар по SQLite!

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

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

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

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

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

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

Вопрос / комментарий приветствуется. 😉

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

  1. Одиночный процесс записи.
  2. Нет зеркалирования.
  3. Нет репликации.

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

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

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

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

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

  • Что быстрее? ByVal или ByRef?
  • Медленная загрузка первой страницы на сайт asp.net
  • Инструменты для измерения затрат на связь MPI
  • Производительность MongoDB по агрегационным запросам
  • Передача целых чисел в виде постоянных ссылок и копирование
  • Эффективные C ++ строки (интернирование, веревки, копирование на запись и т. Д.)
  • Что более эффективно i ++ или ++ i?
  • Что случилось с использованием ассоциативности компиляторами?
  • arrayfun может быть значительно медленнее, чем явный цикл в matlab. Зачем?
  • Почему моя программа работает медленнее, если вы перебираете ровно 8192 элементов?
  • Снижается ли производительность при выполнении циклов, чей счетчик uop не кратен ширине процессора?
  • Давайте будем гением компьютера.