Чому паралельні записи заборонені в базі даних SQLite?

Я займаюся програмуванням баз даних за допомогою Java з SQLite.

Я виявив, що лише одне з'єднання одночасно з базою даних має можливості запису, тоді як багато з’єднань одразу мають можливість читання.

Чому архітектура SQLite була спроектована так? Поки дві речі, які записуються, не записуються на одне і те саме місце в базі даних, чому два записи не можуть відбутися відразу?

database concurrency sqlite

— SteelToe
джерело

пов'язаний (можливо, дублікат): SQLite з двома процесами python, що мають доступ до нього: одне читання, одне написання

— gnat

Тому що SQLite був розроблений так, щоб він був "легким". Низька пам'ять і низька обробка з продуктивністю. Подумайте, як би ви зробили SQLite обробляти кілька записів у один і той же файл. Поточний дизайн легко здійснити - весь файл заблокований, а іншим доводиться чекати. Для обробки одночасності запису на більш низькому рівні деталізації потрібно блокування рядків / сторінок, які ви отримуєте від RDMS. Якщо вимога вимагає написати одночасність запису, тоді SQLite не є кандидатом, а замість цього слід звернути увагу на легкі RDBMS: en.wikipedia.org/wiki/…

— Томас Карлайл

Відповіді:

157

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

Підтримка високого ступеня одночасності запису є ознакою великих двигунів баз даних, таких як DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL та Sybase. Але це технічно важко здійснити, вимагаючи широких стратегій контролю та оптимізації кон'юнктури, таких як блокування баз даних, таблиць та рядків або, у більш сучасних реалізаціях, багатоверсійний контроль одночасності . Дослідження цієї проблеми / вимоги є об'ємними і тягнеться десятиліттями .

SQLite має зовсім іншу філософію дизайну від більшості тих серверно-орієнтованих СУБД, які підтримують кілька авторів. Він розроблений для того, щоб наблизити потужність SQL та реляційну модель до окремих додатків і справді бути вбудованою у кожну програму. Ця мета вимагає значних компромісів. Не додавання значної інфраструктури та накладних витрат, необхідних для обробки кількох одночасних авторів, є одним із таких.

Філософію можна підсумувати висловлюванням на сторінці відповідного використання SQLite :

SQLite не конкурує з базами даних клієнт / сервер. SQLite конкурує з fopen ().

— Джонатан Юніс
джерело

+1. SQLite - це база даних у процесі. Немає центрального арбітра, як у базі даних на сервері. Письменникам доведеться безпосередньо співпрацювати і довіряти один одному. Один злісний письменник міг пошкодити лише не співпрацюючи.

— Йорг W Міттаг

Також деякі середовища, в яких виконується SQLite, можуть навіть не підтримувати декілька процесів.

— david25272

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

— відключення

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

— Джонатан Юніс

@bdsl Бази даних будь-якого типу повинні вважати, що автори не будуть добре себе вести, тому вони не втрачають дані. Автори SQLite позиціонують це як конкурента fopen(), тому враховуйте всю волохатість, яка поставляється при одночасному записі до простого текстового файлу.

— Blrfl

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

Як зазначається в коментарі, одночасне записування також може підтримуватися внутрішнім потоком. Не впевнений, наскільки добре це буде працювати (теж не дуже думав про це). Так чи інакше, чому SQLite не використовує теми: Д-р Хіпп вважає, що нитки є злими.

Те, що Д.Р. Хіпп вважає, що нитки є злими, задокументовано у FAQ щодо SQLite .

— Гойо
джерело

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

— Роберт Харві

Рішення створити SQLite таким чином, щоб він обробляв лише одне записування за один раз.

— Роберт Харві

@Goyo сервер не зобов'язаний обробляти паралельні записи: наскільки сервер баз даних є окремим процесом, може бути окремий внутрішній потік SQLite, який виконує ту саму мету. Роберт Харві правильний: рішення дизайну було прийнято командою SQLite, і це не має нічого спільного зі здатністю однієї бібліотеки обробляти паралельні записи (бо теоретично це може).

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

— jpa

@jpa: SQLite вдається синхронізувати блокування між декількома процесами / потоками без "сервера". "Сервер" не потрібен - використовуючи передбачені ОС блокування / синхронізацію / IPC / все, що достатньо, але він стає складним реально швидко. Згадана у публікації "внутрішня нитка" не має сенсу.

— Мат