[knotes]SQLite и параллельный доступ к базе

че так все бояться mysql. Dolphin памяти больше занимает, чем полновесный mysqld. На фоне файрфокса, опенофиса, амарока и кторрента это все капля в море.

Они знали, они знали, что у меня восемь гигов простаивают! Ну, то есть 0,8 примерно занято, но остальные — простаивают.

а зачем тогда столько памяти купил? Венду хотел поставить что ли?

Вообще хотелось бы тесты

мне сложно представить, почему эксплозивный доступ к базе должен затормозить. посмотрите на mac os x. они sqlite используют везде. и все работает и быстро

Все верно, SQLite не заточена под выполнения конкретных задач.

SQLite FAQ-Q5

(5) Can multiple applications or multiple instances of the same application access a single database file at the same time?

Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.

SQLite uses reader/writer locks to control access to the database. (Under Win95/98/ME which lacks support for reader/writer locks, a probabilistic simulation is used instead.) But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time. On Windows, Microsoft's documentation says that locking may not work under FAT filesystems if you are not running the Share.exe daemon. People who have a lot of experience with Windows tell me that file locking of network files is very buggy and is not dependable. If what they say is true, sharing an SQLite database between two or more Windows machines might cause unexpected problems.

We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.

However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.

When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions.

И тут даже обращаться в рассылку не надо. И так все понятно.

и что. можно сделать один поток-диспетчерезатор

а остальное будут общаться с ним

tsya.ru

lleo.aha.ru/na/

>и что. можно сделать один поток-диспетчерезатор

Это порождает велосипедо-строение. Будет также крутится сервер, получится клиент-серверная архитектура. Вопрос зачем это надо, когда есть MySQL, PostgreSQL ?

MySQL, SQLite - это все пофиг

Мне не понравилась адресная книга на базе Akonadi, появившаяся в 4.4, похоже Akonadi не поддерживает больше половины полей, записанных в моем файле контактов. Ничего не портит конечно, просто не читает. Поэтому я пока на 4.3.5 посижу, благо он меня радует и фичами, и стабильностью.

Не думаю что это так.

Давай-те посмотрим, как это сделано в mac os:

• в системе где-то живет объект: адресная книга
• любой заинтересованный процесс запрашивает proxy к этому объекту (в obj-c это легко и прозрачно, но в С++ это тоже можно сделать так же красиво)
• он обращается к нему, запрашивая или изменяя данные
• этот объект в однопоточном режиме общается с БД

Теперь подумаем, как же выглядит любая другая система: так же остается объект адресная книга, но при этом она создается во множестве экземпляров, с ней общается ее пользователь, а она уже общается с БД. Эта схема проще тем, что отсутствует проксирование запросов. Но при этом возникает 2 проблемы: многопоточный доступ к БД и сохранение когюретности данных в разных объектах (этого можно избежать если не кэшировать результаты запросов, но цена этому - падение производительности).

На мой взгляд минусов у второго подхода больше, в то время как первый действительно легковесный и простой объект

>На мой взгляд минусов у второго подхода больше, в то время как первый действительно легковесный и простой объект

Все случаи с запросами меньше 1000/с не имеют преимуществ в схеме с MySQL/pgSQL, согласен. Но, в базу MySQL в KDE могут оставить для использования скажем совместно с Amarok, KTorrent, KWallet и еще масса приложений, где MySQL пригодится. Как только выходим за рамки в 1к/с запросов - выйгрыш от MySQL только усиливается. Также нельзя забывать про приложения где задержка в несколько долей секунды может стать критичной (как это будет выражаться зависит от проектирования).

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

тем более вопрос в запросах на запись. а на чтение sqlite быстрее mysql по моему даже в разы

Я с трудом могу представить задачу, когда обращение к адрессной книге потребует более 1000 запросов в секунду.

О том и речь. Что авторы Akonadi думали наперед, а не лишь бы решить свои насущные вопросы. Тем не менее автор знал чего хочет. Его осуждение - глупо:

http://lists.kde.org/?l=kmail-devel&m=115973406400111&w=2

After some frustrating days debugging multithreading issues with various embedded databases at akademy I can only say that sqlite is no option anymore. At least not until it gets decent support for highly concurrent access, something thats locks the complete database (even for some read-only operations!) just doesn't work for us.

We also tried MySQL/Embedded which seems to perform better, but it also had problems with multithreading (might be caused by the QSql driver).

Are there any other suggestions for open-source embedded databases? I'm not too happy with a stand-alone database server for Akonadi...

имхо все это не совсем правильная архитектура

зачем усложнять задачу? я думаю управление контактами не когда не потребует тысячи записей в минуту

>я думаю управление контактами не когда не потребует тысячи записей в минуту

Вернемся к такой удобной вещи, как синхронизация телефонной книжки с мобильника. Вот тут-то задержки в несколько десятков миллисекунд будут чувствоваться. 100 записей х 3 поля и задержка в 10мс = 3 секунды. Для MySQL - с задержкой меньше 1 мс = 0.3 секунды. Разница уже есть.

>100 записей х 3 поля и задержка в 10мс = 3 секунды.

Зависит от реализации. Но даже разницу между 1 секундой и 0.1 секундой уже можно ощутить.

при сихронизации можно сделать один общий запрос к дистпетчеру

допустим ему надо записать данные. данные ему кормяться, он их копит - потом ему говорят commit

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

http://habrahabr.ru/blogs/webdev/42121/

>допустим ему надо записать данные. данные ему кормяться, он их копит - потом ему говорят commit

Это потеря времени. Вместо моментальной записи в БД, мы получаем прослойку, которой еще потребуется время все это «разжевать» и записать. Это очень много «лишних» операций, которые выражаются в том что вместо 0.1 секунды мы получим импорт данных в 1 секунду, а то и больше. А если записей 1000, 2000 ? Ждать 20 секунд в нынешних мерках это характеристика «тормозов».

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

да и где 0.1 с. записиси идут очень быстро, 1000 в секунду. sqlite это сдлеате в 2-6 раз быстрее, чем mysql

проблема в том, что во время операции чтение будет приостановлено из базы

В общем конечно идея с mysql круто, но избыточна

Мне не понравилась адресная книга на базе Akonadi, появившаяся в 4.4, похоже Akonadi не поддерживает больше половины полей, записанных в моем файле контактов. Ничего не портит конечно, просто не читает. Поэтому я пока на 4.3.5 посижу, благо он меня радует и фичами, и стабильностью.

Отпишись по этому поводу в багзилу. Считаю что это баг

Не знаю - не знаю. Проверил в korganizer, он среди событий показывает дни рождения контактов. Да и в самом файле контактов все данные на месте конечно. Адресная книга же показывает почему-то только e-mail, хотя раньше показывала и e-mail, и день рождения, и телефоны. Меня с самого начала удивило, что там почему-то полностью другой интерфейс, хотя во всех других программах естественно интерфейс изменился разве что по мелочам. В общем будем разбираться, но, т.к. книга мне нужна, пока на 4.3.5 останусь.

Использовать реляционные БД в DE-приложениях - УГ и СС3Б

Спасибо. Протерял эту ссылку и всё найти не мог :-)