Горутино-безопасное обоащение к sqlite3?

Question

[Muxauko]

Помогите разобраться с многопоточным обращением к БД.
Не могу понять суть. Прошу на примере кода.
Как понимаю, при помощи sql.Open я получаю объект получения, через который в люьой горутине чтение с базы могу производить без ограничений и запись. Но когда приходит момент изменить одно и то же значение или прочесть то, что должно измениться...Нагуглил что можно через mutex, но разве mutex-ом например через db.Exec я не заблочу сам пулл(объект соединения)? Не могу понять как мютексом организовать запись, изменение. Допустим в базе данных имеется 4 таблицы. Сервер читает с трех таблиц и отправляет данные клиенту. Другой клиент делает запрос, что ведет к изменению данных определенного поля в 2 таблицах. Третий клиент тоже делает запрос, который приведет к изменению данных в 1 из 4 таблиц...Как мне этим мютексом орудовать на деле с sqlite3

Comments

[Евгений Самсонов]

В чем у вас проблема? Покажите код и ошибку

[Muxauko]

Евгений Самсонов, принцип работы не пойму.
Вот набросал код примера эмитации 100 записей в базу.
Время выполнения 11,5 сек.
База будет стоять на сервере и обслуживать клиентов tcp.
Запускал код с 1000 записями, уходит минута с лишним.
Но сервер не только будет писать, но и читать с базы, но на чтение думаю у пулла соединений db нет ограничений.

https://play.golang.org/p/BjuY8kJ2TQz

[Евгений Самсонов]

Muxauko, На уровне кода Go блокировки через мьютекс не нужны.

sqlite поддерживает неограниченное число запросов на чтение, и один запрос на запись в один момент времени. Но БД сама разруливает это, вам не нужно беспокоиться. Запросы на запись будут исполняться по очереди
https://www.sqlite.org/whentouse.html

High Concurrency

SQLite supports an unlimited number of simultaneous readers, but it will only allow one writer at any instant in time. For many situations, this is not a problem. Writers queue up. Each application does its database work quickly and moves on, and no lock lasts for more than a few dozen milliseconds. But there are some applications that require more concurrency, and those applications may need to seek a different solution.

[Muxauko]

Евгений Самсонов, да, в случае недоступности базы, она будет выдавать ошибку что база используется. Но она выдаст раз, выдаст два, а потом? Потом запись отвалится и пропадет.
Есть конечно и другой вариант, это включить Journal Mod - WAL. Тогда данный код и 1000 горутин с записями отрабатывает за 500 мс а то и меньше. Но насколько безопасен этот метод и как он поведет себя на одноядерной VPS.

[Евгений Самсонов]

Muxauko, Копайте в сторону ошибки, не нужно мудрить с блокировками там, где они не нужны :)

[Muxauko]

Но с модом WAL существуют опять же недозаписи при исполнении моего кода. Может код надо пилить или что, но пока что самый надежный вариант это через Mutex, тише едешь, дальше будешь...

[Muxauko]

Евгений Самсонов, а что копать то? Это не ошибка а "Внимание". Но оно дается 2 раза, на третий раз горутина уже не обращается, а просто умирает. Вот и все. А через Mutex мы явно даем ей указ, чтобы она не умирала и ждала.

[Евгений Самсонов]

Muxauko, хотя бы приложить текст ошибки. Тут не Ванги сидят)

[Muxauko]

Евгений Самсонов, "date base is locked", "date base is locked" и всё....запись умерла. А из 1000 записей в базу попало 980+...

[Евгений Самсонов]

Muxauko, так как код во множестве горутин выполняет INSERT, и каждый такой запрос приводит к блокировке, можно либо уменьшить количество одновременно выполняемых запросов, например, используя буферизированный канал как семафор, либо увеличить таймаут ожидания ответа от базы данных. Другой вариант использовать более быструю базу данных https://sqlite.org/speed.html

Answer 1

[uvelichitel]

Если вы работаете с sql консистентность данных гарантируется и обеспечивается движком базы через механизм транзакций. Транзакции отражены в пакете database/sql из стандартной библиотеки https://golang.org/pkg/database/sql/#Tx Ничего особенного на уровне языка делать вообще нет необходимости, просто не обращайтесь к одной транзакции из нескольких горутин.

Comments

[Muxauko]

https://play.golang.org/p/BjuY8kJ2TQz

Вот эмитация 100 записей в базу. Выполнение кода занимает 11,5 сек.
База для хранения данных на сервере, по любому горутинам придется встречаться

[uvelichitel]

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

func zapis(db *sql.DB, seler int, t time.Time){ //Без *sync.Mutex
	zapis, err := db.Prepare("insert into proda (Name, Seler) values ('Muxa', ?)")
    if err != nil {
        log.Println(err)
    }
	tx, err := db.Begin()
    if err != nil {
        log.Println(err)
    }
	_, err = tx.Stmt(zapis).Exec(seller)
    if err != nil {
        fmt.Println("doing rollback")
        tx.Rollback()
    } else {
        tx.Commit()
    }
	log.Println("Завершено добавление объекта: ", seler)
	if seler == 100{
		fmt.Println(time.Since(t))
	}
}

Так вы получаете гарантии движка и можете не бояться вызывать эту функцию конкуррентно без мутексов.
Насчет секунд определенно сказать не могу - нужно бенчмаркать по месту.

[Muxauko]

uvelichitel, Выглядит интересно. То есть и я могу эту функцию zapis запускать в горутинах, и типа stmt сам автоматически управляет мютексами? И можете разжевать для чего prepare идет, begin и прочее. Почему именно такой контекст и такая последовательность.

[uvelichitel]

Muxauko, Prepare компилирует шаблон sql команды который можно исполнять подставив переменную Stmt.Exec(seller). Begin открывает транзакцию, в транзакции вы исполняете подготовленный Stmt Потом транзакцию целиком можно принять tx.Commit() или если пошло не так откатить tx.Rollback(). То что транзакцию можно принять или откатить только целиком(а частично нельзя) гарантирует консистентность данных. Stmt не управляет мутексами, блокировками и транзакциями управляет sqlite3. sqlite3 для того и сделан таким, чтобы на уровне клиента никаких особенных действий/блокировок не требовалось. В этом смысл sql движка.

[Muxauko]

uvelichitel, то есть в данную функцию я могу ведь записать три разных prepare для трех разных таблиц в базе, потом передать их stmt, begin и commit? Я просто не пойму как ими управлять(

[Muxauko]

uvelichitel, и кстати, этот код падает с ошибкой и не завершает все записи)

Answer 2

[falconandy]

Можно ограничить максимальное кол-во соединений до 1:
db.SetMaxOpenConns(1)
Это приведет к тому, что и запросы на чтение перестанут выполняться параллельно - так что может подойти, если у вас запросы "шустрые".
Плюс в том, что в коде не надо будет ничего менять, никаких мьютексов.
Но так как у вас мест записи в БД немного, то можно использовать и мьютексы - вряд ли вы что-то упустите.
Если бы мест изменения БД было много, то еще можно рассмотреть вариант обертки над *sql.DB, в которой автоматически использовать мьютекс для всех "подозрительных" методов - например Exec методов (из предположения что в них как правило идет изменение БД) или Query методов, если в запросе есть insert, update или delete.

Вот еще ссылка по теме: https://stackoverflow.com/questions/35804884/sqlit...