Python-сообщество

ZZZ
Быстрее питьоньего кода. Иногда очень важно оптимизировать работу с базой, когда она является узким местом.
Конечно не стоит делать из БД контроллер.

Согласен. Для реализации сложной логики ее реализация на сервере быстрее (масло масляное :)).
Но я не могу представить сложную логику и встраиваемую БД в одном проекте.

ZZZ
Ээээ… Нет. Самое главное тут то, что запросы к базе синхронны, а вот траблы при несинхронных изменениях известны – лично я сталкивался с повреждениями базы при множественных инсертах в несколько потоков (но там было всё сложно и я решил перейти на постгри).

Интересно.
Могу предположить, что это система снятия данных с нескольких (десятков) датчиков. В этом случае легко превысить возможности СУБД.
Данные вставлялись единичными инсертами или пакетами. Т.е. было ли ручное управление транзакциями?

Lexander

ZZZ
Выделить всю работу с СУБД в отдельный класс - это просто удобство работы с кодом, сопровождения и т.п.

А как же ORM? :-)

Не понял, что вы хотели этим сказать. Можно уточнить?

Отредактировано (Апрель 28, 2010 11:41:03)

Lexander

Ed
Пришли к выводу, что это нельзя использовать, если происходит интенсивная запись в базу

О, уже что-то.
А поподробнее можно?

Было это год назад где-то. Приложение небольшое, несколько таблиц, несколько many-to-many отношений.
Количество insert-ов порядка нескольких тысяч на круг. С mysql-ем это вылилось где-то в минуту, а с sqlite - минут пять или около того.
Размер записываемых данных небольшой, в среднем от нескольки килобайт до может пары десятков в записи где-то.
К сожалению более точных данных у меня нет и посчитать уже не на чем - приложение уже было отрефакторено несколько раз. Но помню, что был сильно удивлен результатом замены бэкэнда. Такой разницы не ожидал.

Да, есть еще и положительный опыт. Маленькое приложение на PyGTK + sqlite для мобильного девайса. До этого был pickle и жутко тормозил. При переходе на sqlite все залетало. Но там в основном чтение да и объемы на 2 порядка меньше.

Ed
Количество insert-ов порядка нескольких тысяч на круг. С mysql-ем это вылилось где-то в минуту, а с sqlite - минут пять или около того.

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

Скорее всего вы правы. Только для mysql тоже самое юзалось. Там бы я тоже мог(и собственно сделал потом) использовать bulk insert, но это уже другая история. Прирост производительности в несколько раз был вызван только сменой движка.

В mysql используется другой алгоритм блокировки таблиц, который к тому же зависит от типа используемых таблиц, которые, в свою очередь, могут быть как транзакционными, так и не… (что уже влияет на скорость работы).
Кроме того, операции вставки в mysql имеют по-умолчанию самый высокий приоритет.
А уж о конфигурационных переменных (в том числе буфере для вставок) можно статью писать.

Lexander
Интересно.
Могу предположить, что это система снятия данных с нескольких (десятков) датчиков. В этом случае легко превысить возможности СУБД.

Бухгалтерская херотень – конкурент 1С в своём сегменте.
Если бухгалтер один, то ставилась встроенная версия, если много – клиент-серверная.

Lexander
Данные вставлялись единичными инсертами или пакетами. Т.е. было ли ручное управление транзакциями?

Да, там была довольно тонкая работа с транзакциями.

Ну, про транзакции после уточнения что за клиенты можно было и не отвечать :)