Скорость работы БД в приложении |
Здравствуйте, гость ( Вход | Регистрация )
Скорость работы БД в приложении |
Kagami |
18.3.2011, 20:59
Сообщение
#11
|
Старейший участник Группа: Участник Сообщений: 601 Регистрация: 2.2.2009 Пользователь №: 523 Спасибо сказали: 101 раз(а) Репутация: 9 |
Замедляют в смысле? Пусть тебе надо сделать 5 операций вставки. По-умолчанию для каждой операции будет сделана своя транзакция (причем автоматически), т.е. QSqlDatabase::beginTransaction(); QSqlQuery::exec("..."); QSqlDatabase::commit(); ...А как к примеру это сделать, т.е. запускать и завершать транзакции вручную? А теперь представь что у тебя таких операций в разы больше. При этом для каждой транзакции тот же QSqlLite создает журнал, а фактически - файл на жестком диске. А если начать транзакцию самому (с помощью явного вызова QSqlDatabase::beginTransaction()), выполнить все свои запросы, а затем завершить ее, то все будет работать быстрее. |
|
|
Litkevich Yuriy |
18.3.2011, 22:55
Сообщение
#12
|
разработчик РЭА Группа: Сомодератор Сообщений: 9669 Регистрация: 9.1.2008 Из: Тюмень Пользователь №: 64 Спасибо сказали: 807 раз(а) Репутация: 94 |
|
|
|
AD |
18.3.2011, 22:56
Сообщение
#13
|
Профессионал Группа: Участник Сообщений: 2003 Регистрация: 4.2.2008 Из: S-Petersburg Пользователь №: 84 Спасибо сказали: 70 раз(а) Репутация: 17 |
Пусть тебе надо сделать 5 операций вставки. По-умолчанию для каждой операции будет сделана своя транзакция (причем автоматически), т.е. QSqlDatabase::beginTransaction(); QSqlQuery::exec("..."); QSqlDatabase::commit(); ... А теперь представь что у тебя таких операций в разы больше. При этом для каждой транзакции тот же QSqlLite создает журнал, а фактически - файл на жестком диске. А если начать транзакцию самому (с помощью явного вызова QSqlDatabase::beginTransaction()), выполнить все свои запросы, а затем завершить ее, то все будет работать быстрее. Ясно, спасибо. При работе с SQLite буду иметь в виду. Пока еще на Paradox. Посмотрел с помощью hasFeature() поддерживает ли мой драйвер Paradox транзакции и увидел, что не поддерживает. Сообщение отредактировал AD - 18.3.2011, 22:56 |
|
|
AD |
1.4.2011, 16:41
Сообщение
#14
|
Профессионал Группа: Участник Сообщений: 2003 Регистрация: 4.2.2008 Из: S-Petersburg Пользователь №: 84 Спасибо сказали: 70 раз(а) Репутация: 17 |
Кто-нибудь еще может подсказать, как увеличить скорость работы запросов? СУБД - Paradox. Переход на SQLite не удался в связи с проблемой транзакций. По каким причинам время работы запроса составляет несколько секунд?
|
|
|
Iron Bug |
1.4.2011, 17:27
Сообщение
#15
|
Профессионал Группа: Модератор Сообщений: 1611 Регистрация: 6.2.2009 Из: Yekaterinburg Пользователь №: 533 Спасибо сказали: 219 раз(а) Репутация: 12 |
а что в SQLite с транзакциями? по-моему, там не было проблем с ними.
я работала с SQLite - держит очень приличную скорость. я сливала данные очень быстро, и они ещё читались другой софтиной. проблем не было. но лучше транзакции начинать вручную, как уже написали выше и сливать порциями, чтобы обращение к винту было не слишком частым. и ещё у SQLite есть две фичи: 1. когда база становится жирнее 300 метров (это под вендой я работала), он начинает иногда глючить при вставке записей (возвращает SQLITE_CORRUPT. они про эту ошибку знают, но вроде пока не исправили). я не уверена, что этот предел зависит именно от размера базы, а не от количества записей. у меня их там были сотни тысяч. но, в принципе, я решила проблему созданием нового файла базы после накопления этого объёма. но если база не может быть разделена на куски и она больше 300 метров - то это может быть проблемой. 2. у него есть несколько настроек, которые позволяют ускорять работу с базой:
я их сейчас просто из кода взяла и уже не особо помню, что конкретно они делают, это надо читать в доках на SQLite, пояснения есть на их сайте. но это существенно ускоряет вставку записей в таблицы. P.S. я пользовалась стандартным интерфейсом SQLite. сама QT тоже может отъесть сколько-то времени, но не думаю, что разница будет существенной. Сообщение отредактировал Iron Bug - 1.4.2011, 17:41 |
|
|
Litkevich Yuriy |
1.4.2011, 19:48
Сообщение
#16
|
разработчик РЭА Группа: Сомодератор Сообщений: 9669 Регистрация: 9.1.2008 Из: Тюмень Пользователь №: 64 Спасибо сказали: 807 раз(а) Репутация: 94 |
я месяц назад пользовал небольшую (по мегабайтам) SQLite БД, у меня было: вставка без транзакции > 13 сек. Вставка с транзакцией <1 сек.
|
|
|
Iron Bug |
1.4.2011, 20:06
Сообщение
#17
|
Профессионал Группа: Модератор Сообщений: 1611 Регистрация: 6.2.2009 Из: Yekaterinburg Пользователь №: 533 Спасибо сказали: 219 раз(а) Репутация: 12 |
я месяц назад пользовал небольшую (по мегабайтам) SQLite БД, у меня было: вставка без транзакции > 13 сек. Вставка с транзакцией <1 сек. транзакция позволяет делать откаты и либо ты не коммитил (данные не сливались реально, а хранились в памяти), либо что-то неправильно делал. потому что с отдельными транзакциями на каждую запись обращение к базам всегда медленнее. кстати, вставка 13 секунд - это тоже что-то нездоровое. хотя, наверное смотря какой объём. у меня наоборот была задача: довольно мелкие записи, но очень быстро: примерно 30 записей (в разные таблицы, со связями) каждые 50миллисекунд. за час эта хрень отъедала чуть больше гигабайта на винте (но база была поделена на куски по 300 метров) и всё работало на ура и ни грамма не грузило ни проц, ни память, ни винт. при этом параллельно пользователь работал с софтиной, в которой он просматривал и сортировал выборки из данных. и даже при выборках в сотни тысяч записей ничего не тормозило. хотя юзерский интерфейс, конечно, отъедал больше ресурсов. но там ещё на каждую запись отрисовка шла и скорее всего, поэтому. сами обращения к базе не так много брали. в худших случаях ну секунд 5. но это уж когда вообще открывался один целый файл в 300 метров с хитрожопой сортировкой. Сообщение отредактировал Iron Bug - 1.4.2011, 20:20 |
|
|
Litkevich Yuriy |
2.4.2011, 9:21
Сообщение
#18
|
разработчик РЭА Группа: Сомодератор Сообщений: 9669 Регистрация: 9.1.2008 Из: Тюмень Пользователь №: 64 Спасибо сказали: 807 раз(а) Репутация: 94 |
|
|
|
AD |
2.4.2011, 14:13
Сообщение
#19
|
Профессионал Группа: Участник Сообщений: 2003 Регистрация: 4.2.2008 Из: S-Petersburg Пользователь №: 84 Спасибо сказали: 70 раз(а) Репутация: 17 |
Повторюсь. Проблема со скоростью - на Paradox, на SQLite вообще не удавалось записи в таблицу вставить. Даже не знаю почему... Либо он создавал в памяти образ БД, либо еще что-то. Т.е. запись вставлялась, но как только перезапускал приложение, все оставалось по прежнему... commit транзакци не срабатывал. До скорости в SQLite не успел добраться!
|
|
|
Iron Bug |
2.4.2011, 17:16
Сообщение
#20
|
Профессионал Группа: Модератор Сообщений: 1611 Регистрация: 6.2.2009 Из: Yekaterinburg Пользователь №: 533 Спасибо сказали: 219 раз(а) Репутация: 12 |
я не раз сталкивалась с SQLite, на предыдущей работе мы тоже её использовали. проблем не было и всё работало. это отличная база для локального использования. лёгкая и быстрая. но мы использовали их родной API, без всяких там оболочек. у них очень простые API-функции и освоение занимает от силы пару дней. я не могу сказать, почему что-то не срабатывало у других, но это точно не проблема SQLite. коммиты и транзакции там работают, как и всё прочее.
|
|
|
Текстовая версия | Сейчас: 11.12.2024, 4:10 |