Django Persistent DB connections - Другой подход

Question

Я поехал похожие темы, как Django persistent database connection и другие материалы на эту же тему. Однако Django официально не поддерживает постоянные подключения к MySQL и Mongo (к моим ограниченным знаниям). Поэтому я попытался избежать многих вещей и попытался сделать это простым. Так что я сделал это в моих view.py сделанных глобальных переменных соединения как для MongoDB и MySQL, что-то вроде:

from pymongo import Connection 
import MySQLdb 
global mongo_connection,mongo_db,collection,mysql_connection,mysql_cursor 
mysql_connection = MySQLdb.connect (host = "localhost", 
         user = "root", 
         passwd = "password", 
         db = "demo") 
mysql_cursor = mysql_connection.cursor() 
mongo_connection = Connection() 
mongo_db = mongo_connection.test_database 
collection = mongo_db.test_collection 

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

mysql_cursor.execute('''INSERT INTO   
table_name(l,n_n,n_id,s_n,s_id,u,r) VALUES 
(%s,%s,%s,%s,%s,%s,%s)''', 
(l,n_n,n_id,s_name,s_id,u,re) 
) 

И аналогично я сделал для сохранения в MongoDB.

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

Почему такой подход не используется?

Как измерить улучшения производительности, которые я получаю с помощью этого подхода v/s, позволяя Django создавать новое соединение с БД при каждом вызове.

Также предполагается, что пакетная вставка улучшит ситуацию, уменьшив количество вызовов в DB. Как можно реализовать такую ​​концепцию в определении представления?

Вот как мое приложение ведет себя, прежде чем я использовал свой метод пытается сделать постоянное соединение и был позволить Django заботиться о нем

mysql> show status like '%onn%'; 
+--------------------------+--------+ 
| Variable_name   | Value | 
+--------------------------+--------+ 
| Aborted_connects   | 0  | 
| Connections    | 164359 | 
| Max_used_connections  | 3  | 
| Ssl_client_connects  | 0  | 
| Ssl_connect_renegotiates | 0  | 
| Ssl_finished_connects | 0  | 
| Threads_connected  | 1  | 
+--------------------------+--------+ 
7 rows in set (0.00 sec) 

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

mysql> show status like '%onn%'; 
+--------------------------+--------+ 
| Variable_name   | Value | 
+--------------------------+--------+ 
| Aborted_connects   | 0  | 
| Connections    | 175047 | 
| Max_used_connections  | 3  | 
| Ssl_client_connects  | 0  | 
| Ssl_connect_renegotiates | 0  | 
| Ssl_finished_connects | 0  | 
| Threads_connected  | 1  | 
+--------------------------+--------+ 
7 rows in set (0.00 sec) 

http://dev.mysql.com/doc/refman/5.5/en/server-status-variables.html#statvar_Connections утверждает, что соединение: количество попыток соединения (успешно или нет) к MySQL server.So является его из-за какой-либо проблемы, в которой я ручки экономии строки, используя Django ORM для MySQL или это своего рода соединение ns ожидается?

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

решаемые

запуталась, прочитав определение о Connections.So, наконец, понял это, выполнив тест. Внесено 19 записей в БД, соединения увеличены на тот же номер. Поэтому я считаю, что это означает, что с ним связали несколько раз. Так что в этом случае использование встроенного материала Django - лучший способ.

http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html сообщает, что максимальное количество соединений - 151, так что в любом случае это была неправильная интерпретация с моей стороны.

Answer 1

Если вы хотите, чтобы попасть в такой технической теме, посмотрите на django.db пакет и посмотреть, как движки базы данных в Django и QuerySet экземпляры взаимодействуют друг с другом, прежде чем делать какие-либо ошибочные предположения, Suh как то Django открывает новую базу данных соединение каждый раз, когда он взаимодействует с базой данных. Вы увидите, что уровень базы данных выполняет все, что вы упомянули здесь, не позволяя разработчику неправильно управлять ресурсами базы данных, например, получать курсор в цикле и забывать закрыть его и создать утечку памяти.

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

Сказав, что для неподдерживаемых баз данных, таких как MongoDB и любая другая нереляционная база данных, вам придется предположить, что у вас нет уровня базы данных Django, который управляет вашими ресурсами базы данных и как вы взаимодействуете с ними и старательно осматриваете каковы ваши обязательства как разработчика в условиях взаимодействия с их API баз данных. Когда вы увидите очевидные шаблоны, вы придумаете решение, подходящее для применения в контексте компонентов представления.