Как диагностировать причину медленного доступа к базе данных sqlite?

Question

Как я уже говорил в этом вопросе некоторое время назад, у меня возникают проблемы с производительностью при доступе к базе данных sqlite из Python. Чтобы сделать это еще раз, идентичный код выполняется более чем в 20 раз быстрее, используя apsw . Недавно я параллельно установил другую версию Python и установил новую версию apsw для этого. Эта версия тоже работала медленно. Я попробовал тот же код на другом компьютере, используя pythons built-int sqlite3, и он работал быстро (но медленно с apsw). Я также попытался установить самую последнюю версию pysqlite на свой компьютер, но она работала медленно.

Я абсолютно уверен, что это не проблема со схемой.

Мой вопрос сейчас, как я могу приступить к диагностике ошибки?

Answer 1

На случай, если вы, возможно, не заметили этого, убедитесь, что вы работаете с последними версиями как адаптера базы данных pysqlite2, так и библиотеки sqlite3 . Связанный ответ также показывает, как точно определить, какую версию каждого из них вы используете, и данные, которые вы, возможно, захотите добавить к своему вопросу.

Answer 2

Я могу предложить свой опыт на аналогичном опыте, но на другой платформе, а именно J.

Была некоторая медлительность, и я определил ее для функции sqlite3_get_table. Эта функция возвращает указатель для каждого столбца, каждый из которых указывает на массив указателей, где каждый из них ссылается на строку с нулевым символом в конце. Указатели также могут быть нулевыми, если результатом функции является нулевой (скажем, Max для пустого набора данных, он вернет нулевой указатель, а не указатель на нулевой. Я ненавижу это.) Затем J сформировал адреса как читаемые ( сформировать большую матрицу адресов, за которой следуют 0 для смещения и -1 для длины (то есть до первого нуля) и циклически перебирается каждый из них, чтобы окончательно изменить форму таблицы в ее предполагаемые столбцы и строки.

Итак, есть аспект передачи памяти, а также фактический аспект чтения, для извлечения данных из SQLite на другую платформу. Я обнаружил, что этот часто большой набор данных не так легко обрабатывается J, что означает, что он неуклюж, как и все строки. Плюс есть эта неприятная вещь с нулевым указателем.

Мне удалось ограничить модификации матрицы настолько, чтобы оптимизировать функцию. Окончательная оптимизация состояла в том, чтобы использовать примитивный код для чтения адреса памяти (15!:1), а не прилично названную функцию (memr), потому что использование memr означало, что J должен был интерпретировать то, что memr означает в каждой памяти прочитать .

В заключение, если python допускает некоторые изменения, возможно, вы можете настроить доступ к базе данных, чтобы лучше соответствовать вашим потребностям. Надеюсь, это поможет, но у меня не очень большие надежды ...