Які характеристики продуктивності sqlite з дуже великими файлами баз даних? [зачинено]

Я знаю, що sqlite не дуже добре працює з надзвичайно великими файлами баз даних, навіть коли вони підтримуються (раніше на сайті sqlite був коментар, який стверджує, що якщо вам потрібні розміри файлів вище 1 Гб, ви можете розглянути можливість використання корпоративних rdbms. Можна Ви не знайдете його більше, можливо, це стосується старішої версії sqlite).

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

Я говорю про файли даних sqlite в багатогігабайтному діапазоні, починаючи від 2 Гб. Хтось має з цим досвід? Якісь поради / ідеї?

Тому я зробив кілька тестів на sqlite для дуже великих файлів і прийшов до деяких висновків (принаймні для мого конкретного застосування).

Тести включають один файл sqlite з однією таблицею або декількома таблицями. Кожна таблиця мала приблизно 8 стовпців, майже всі цілі числа та 4 індекси.

Ідея полягала в тому, щоб вставити достатню кількість даних, поки файли sqlite не склали близько 50 Гб.

Єдиний стіл

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

Це підводить мене до висновку, що одна, дуже велика таблиця sqlite матиме проблеми із вставками та, ймовірно, й іншими операціями.

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

Кілька таблиць

Потім я спробував розділити дані за часом на кілька таблиць, одну таблицю на день. Дані для початкової 1 таблиці розділили на ~ 700 таблиць.

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

Питання вакууму

Як зазначає i_like_caffeine, команда VACUUM є проблемою, чим більший файл sqlite. Коли більше вставок / видалень буде зроблено, фрагментація файлу на диску буде погіршуватися, тому мета періодично VACUUM оптимізувати файл та відновити файловий простір.

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

Висновки

У моєму конкретному застосуванні я, мабуть, буду розбивати дані на кілька db-файлів, один на день, щоб отримати найкращу ефективність роботи вакууму та швидкість вставки / видалення.

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

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

Це дуже погано, що, здається, не існує інкрементального методу вакууму, крім автоматичного вакууму . Я не можу його використовувати, тому що моя мета вакууму - дефрагментація файлу (файловий простір не є великою справою), що не робить автоматичний вакуум. Насправді в документації зазначено, що це може погіршити фрагментацію, тому мені доводиться періодично вдаватися до повного вакуумування файлу.

Ми використовуємо DBS на 50 ГБ + на нашій платформі. без скарг чудово працює. Переконайтесь, що ви все робите правильно! Чи використовуєте ви заздалегідь задані заяви? * 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 Limits , максимальний розмір кожної сторінки бази даних - 32K. А максимальна кількість сторінок у базі даних - 1024 ^ 3. Тож за моєю математикою, яка виходить на 32 терабайта як максимальний розмір. Я думаю, ви досягнете меж вашої файлової системи, перш ніж потрапляти на SQLite!

Більшість причин, через які знадобилось> 48 годин, щоб зробити свої вставки, - це через ваші індекси. Це неймовірно швидше:

1 - Відкинути всі індекси 2 - Зробити всі вставки 3 - Створити індекси заново

Крім звичайної рекомендації:

1. Індекс падіння для об'ємної вставки.
2. Пакетні вставки / оновлення у великих транзакціях.
3. Налаштуйте кеш-буфер / вимкніть журнал / без 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. Немає реплікації.

У мене база даних SQLite 7 Гб. Для виконання конкретного запиту з внутрішнім з'єднанням потрібні 2.6 секунди. Щоб прискорити це, я спробував додати індекси. Залежно від того, який індекс я додав, іноді запит знижувався до 0,1s, а іноді - до 7s. Я думаю, що проблема в моєму випадку полягала в тому, що якщо стовпець сильно повторюється, то додавання індексу знижує продуктивність :(

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

Але що стосується останніх версій SQLite, це більше не потрібно. Детальніше читайте тут .

У мене виникли проблеми з великими файлами sqlite під час використання вакуумної команди.

Я ще не пробував функцію auto_vacuum. Якщо ви плануєте часто оновлювати та видаляти дані, то це варто переглянути.