Django Постоянные соединения с БД - другой подход - PullRequest
Новая
       10

Django Постоянные соединения с БД - другой подход

1 голос
/ 14 декабря 2011

У меня были похожие темы, такие как Постоянное соединение с базой данных Django и другие материалы по той же теме.Однако Django официально не поддерживает постоянные соединения с MySQL и Mongo (насколько мне известно). Поэтому я старался избегать многих вещей и пытался упростить это. Так что я сделал в моих views.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.

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

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

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

Кроме того, пакетная вставка должна сделать вещи еще лучше, сократив количество вызовов к 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 утверждает, что Connection: количество попыток подключения (успешно или нет) к серверу MySQL. Так что это из-за какой-то проблемы, в которой я занимаюсь сохранением строки, используяDjango ORM для MySQL или ожидается такое количество соединений?

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

решено

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

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

1 Ответ

2 голосов
/ 14 декабря 2011

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

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

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

...