Подключение к базе данных

Цель лекции: Рассмотреть основные особенности поддерживаемых баз данных; ознакомились со структурой файла миграции; рассмотреть особенности использования Django с NoSQL, реализовали простейший проект MongoDB на Django.

Ключевые термины: Django, база, фреймворк, файл, SQL, миграция, проект, данные, field, class, url, python, схема, модель, слияние

Django - это фреймворк с агностическим подходом к базе данных, это означает, что поля базы данных, предоставляемых Django предназначены для работы в разных базах данных, таких как SQLite, Oracle, MySQL и PostgreSQL. Действительно, они также работают с некоторыми сторонними базами данных. PostgreSQL является небольшой базой данных для Django в рабочей фазе, в то время как для окружения разработки используется SQLite, и вы в конечном итоге проделаете много работы, если не захотите использовать СУБД для вашего проекта. Эта лекция даст вам подробную разницу между двумя типами и покажет вам, что лучше подходит для Django, и, так же, как мы действительно можем их имплементировать в наш проект Django.

Прежде всего, давайте посмотрим на разницу между SQL и NoSQL.

SQL против NoSQL

Базы данных SQL и реляционные базы данных использовались повсеместно в течение очень долгого времени; в самом деле, говоря о базах данных, подразумевали базы данных SQL, до тех пор, пока не был придуман новый термин — NoSQL.

Мы поговорим о высокоуровневых различиях между SQL и NoSQL. Ниже приведены различия между ними:

Давайте попробуем понять основные особенности некоторых из известных баз данных SQL и NoSQL.

Базы данных SQL

Следующие разделы посвящены различным SQL базами данных и их использованию.

MySQL – open source

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

PostgreSQL

Как упоминалось ранее, PostgreSQL является наиболее популярной базы данных в рамках сообщества Django. Он также имеет широкий набор функций, поддерживаемый основными базами данных.

Развитие расширенных запросов и особенностей PostgresSQL сделали возможным достигнуть комплексной строки обычного запроса SQL в гораздо более простой строке для записи запроса. Однако имплементация массивов, hstore, JSON и так далее сложнее с помощью обычных SQL баз данных.

NoSQL базы данных

Эта концепция была введена, когда горизонтальное масштабирование было непросто осуществить и базы данных на основе реляционных СУБД не могли масштабироваться, так как должны были. Часто этот термин расшифровывается Not Only SQL (Не только SQL). Он предоставляет механизм для хранения и извлечения данных, отличных от традиционных методов SQL.

MongoDB

MongoDB – одна из самых популярных документальных NoSQL баз данных, так как она хранит данные в JSON-подобных документах. Это нереляционная база данных с динамической схемой. Она была разработана основателями компании DoubleClick. Она написана на C++ и в настоящее время используется в некоторых крупных компаниях, таких как The New York Times, Craigslist и MTV Networks. Ниже приведены некоторые преимущества и сильные стороны MongoDB:

CouchDB

CouchDB является также документальной базой данных NoSQL. Он хранит данные в виде документов JSON. Ниже приведены некоторые преимущества и сильные стороны CouchDB:

Redis

Redis является еще одной базой данных NoSQL open source, которая используется главным образом в связи с молниеносной скоростью. Она написана на языке ANSI С. Ниже приведены некоторые преимущества и сильные стороны Redis:

Настройка системы базы данных

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

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

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

Вот почему мы использовали до сих пор эту базу данных на протяжении всего этого проекта.Конечно, вы можете использовать свою любимую СУБД. Мы можем указать Django, какую СУБД использовать путем редактирования файла конфигурации. Стоит также отметить, что, если вы хотите использовать MySQL, вам будет нужно установить MySQL, которая является драйвером MySQL для Python.

Установка системы базы данных в Django очень проста; все, что вам нужно сделать, это, во-первых, установить базу данных, которую вы хотите настроить, а затем добавить несколько строк конфигурации в файле settings.py и установка базы данных будет завершена.

Настройка MySQL

Мы установим и настроим MySQL связанные с ним плагины шаг за шагом в следующих разделах.

Установка MySQL в Linux - Debian

Выполните следующую команду для установки MySQL в Linux (Debian):

sudo apt-get install mysql-server 

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

Установка плагина MySQL для Python

Для установки плагинов MySQL, которые вам требуются, используйте команду:

pip install mysql-python

Теперь откройте файл settings.py и добавьте следующие строки для соединения Django с MySQL:

DATABASES = {
'default':	{
'ENGINE':	'django.db.backends.mysql',
'NAME':	'django_db',
'USER': 'your_username',
'PASSWORD':	'your_password',
}
}

Вот и все, то, вам нужно сделать сейчас, это воссоздать все таблицы в новой базе данных, которую вы просто настроили и выполните следующую команду:

python manage.py syncdb

Вы получите исключение django.db.utils.ConnectionDoesNotExist, если не определена база данных, к которой вы пытаетесь получить доступ

Преимуществом Django является, что вы можете использовать его с несколькими базами данных одновременно. Однако вы можете задуматься, какова необходимость использовать несколько баз данных в одном проекте?

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

Для системы с несколькими базами данных может быть идеальным решением хранить реляционную информацию, например пользователей,их роль и другую учетную информацию, в базе данных SQL, такой как MySQL. Данные приложений, которые является независимыми, могут храниться в базе данных NoSQL, такой как MongoDB.

Нам необходимо определить несколько баз данных через файл конфигурации. Django необходимо указать, когда вы хотите использовать более чем одну базу данных с серверами базы данных, которые вы используете. Так, в файле settings.py, вам нужно изменить настройку DATABASE с отображением псевдонимов базы данных.

Соответствующий пример конфигурации нескольких баз данных может быть записан следующим образом:

DATABASES = {
 'default':	{
'NAME':	'app_data',
'ENGINE':	'django.db.backends.postgresql_psycopg2',
'USER':	'postgres_user',
'PASSWORD':	's3krit'
}
'users': {
'NAME':	'user_data',
'ENGINE' :	'django.db.backends.mysql',
'USER':	'mysql_user',
'PASSWORD':	'priv4te'
}
}

В предыдущем примере используется две базы данных, е MySQL и PostgreSQL с требуемыми учетными данными.

Миграция и потребность в миграции

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

Схема миграции с Django имеет длительную и сложную историю; за последние несколько лет единственным выбором было стороннее приложение South. Если вы думаете о важности миграции, Django 1.7 был выпущен с встроенной поддержкой миграции.

Нам нужно знать также о сравнении миграции South и Django.Для тех, кто знаком с South, тот должен почувствовать себя в знакомой среде 'и вероятно немного чище. Для удобства в следующей таблице сравниваются процесс старого рабочего потока South и миграции нового рабочего потока Django:

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

Новые возможности миграции Django

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

Давайте взглянем на следующий список терминов, чтобы понять преимущества миграции Django:

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

До версии Django 1.8.4, которая является последней, необходимо было отдельно устанавливать модуль South. Однако начиная с миграции версии Django 1.7, модуль South встроен в систему. Вы могли всегда делать это, например, когда вы изменили (изменения, такие как добавление новых атрибутов) ваши классы моделей, используя следующую команду:

python manage.py syncdb

В новой версии manage.py syncdb была признана устаревшей для миграции, но, если вы все еще хотите использовать старый способ, он работает.

Поддержка внутреннего интерфейса

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

Некоторые из наиболее совместимых баз данных являются следующими:

Как сделать миграции?

Миграция выполняется главным образом с помощью трех команд, которые заключаются в следующем:

Таким образом поток для схемы миграции Django может быть сформулирован следующим образом:

python manage.py makemigrations ‘appname’

Это подготовит файл миграции, который будет выглядеть аналогично следующему:

Migrations for 'app_name':
0003_auto.py:
- Alter field name on app_name

Затем после того, как файл будет создан, , вы можете проверить структуру каталогов. Вы увидите файл с именем 0003_auto .py в папке миграции; можно применить изменения с помощью следующей команды:

python manage.py migrate appname 

Ниже приведены действия, которые необходимо выполнить:

Synchronize non migrated apps: sessions, admin, messages, auth, staticfiles, contenttypes Apply all migrations: appname Synchronizing apps without migrations:

Creating tables...
Installing custom SQL...
Installing indexes... 
Installed 0 object(s) from 0 fixture(s)
Running migrations:
Applying appname.0003_auto... OK

Сообщение ОК говорит о том, что миграция успешно завершилась.

Чтобы добавить больше понимания миграции можно объяснить с помощью следующей схемы:

Существует три отдельных сущности:

Разработчик вносит изменения в исходный код, главным образом в файл models.py и изменяет ранее определенную схему. Например, когда они создают новое поле в соответствии с требованиями бизнеса, или обновляют поле max_length с 50 до 100.

Мы завершим правильную миграцию нашего проекта, чтобы увидеть, как на самом деле работает эта миграция.

Во-первых, мы должны создать начальную миграцию приложения:

 python manage.py makemigrations tweets

Вывод этой команды следующий:

Migrations for 'tweet':
0001_initial.py:
 Create model HashTag
 Create model Tweet
 Add field tweet to hashtag

Это показывает, что первоначальная миграция был создана.

Давайте теперь изменим нашу модель tweet, которая в настоящее время выглядит следующим образом:

text = models.CharField(max_length=160, null=False, blank=False)

Мы изменим предыдущую модель tweet на:

text = models.CharField(max_length=140, null=False, blank=False)

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

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

python manage.py makemigrations tweets

Вывод этой команды следующий:

Migrations for 'tweets':
0002_auto_20141215_0808.py:
 Alter field text on tweets

Как вы можете видеть, обнаружено изменение в нашем поле.

Для проверки мы откроем нашу базы данных SQL и проверим текущую схему нашей таблицы tweet.

Соединитесь с MySQL с помощью команды::

mysql -u mysqlusername - pmysqlpassword mytweets

В консоли MySQL напишите:

mysql > desc tweettweet; 

Это покажет вам схему таблицы tweet, следующим образом:

| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+--------+-------+-------------------+
|userid | int(ll) | NO | MUL| NULL	|	|
|text | varchar(160) | NO |	|NULL |	|
|created_date | datetime | NO	|	| NULL	|	|
|country | varchar(30) | NO |	|	NULL	|	|
| is_active | tinyint(l) | NO |	| NULL |	|
+---------------+-------------+--------+-------+-------------------+
        6 rows in set (0.00 sec)

Так как мы еще не применили наши миграции, база данных ясно отображает текст в символьном поле в 160 символов:

text | varchar(160) | NO |	| NULL

Мы сделаем именно это, как только применим миграции:

python manage.py migrate tweets

Далее следуют операции, которые нам нужно выполнить:

Apply all migrations: tweet
      Running migrations:
Applying tweet.0002_auto_20141215 0808.. . OK

Наша миграция была успешно применена; давайте проверим то же самое из-под базы данных.

Чтобы выполнить ту же команду desc MySQL в таблице tweet_tweet, используйте следующую команду:

MySQL > desc tweettweet;




| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+--------+-------+-------------------+
|	userid | int(ll) | NO | MUL	|	NULL	|	|
|	text | varchar(140) | NO |	|	NULL |	|
|	created_date | datetime | NO	|	| NULL	|	|
|	country | varchar(30) | NO |	|	NULL	|	|
| is_active | tinyint(l) | NO |	| NULL |	|
+---------------+-------------+--------+-------+-------------------+
        6 rows in set (0.00 sec)

И действительно! Наша миграция была успешно применена:

|	text | varchar(140) | NO |	|	NULL |	|	

Как миграции узнают, что требуется подвергнуть миграции

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

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

mysql> select * from django_migrations	-+		-+			+	
	-+		-+			+	
id	1 app | +	name	| applied |
		+	+
i	tweet	1 0001	initial | 2014-12-15 08:02:34 |
2	tweet -+		1 0002 -+		_auto_20141215_0808 | 2014-12-15 08:13:19 | 	+	

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

Это означает, что даже если вы измените файл миграции вручную, он будет пропущен.

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

Конечно, если вы действительно хотите запустить одну и ту же миграцию дважды, то вам следует удалить запись таблицы "THIS IS NOT A OFFICIALLY RECOMMENDED WAY" и все будет прекрасно работать.

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

Например, если вы наберете следующую команду, все ваши миграции для приложения tweet обратятся:

python manage.py migrate tweet zero

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

Файл миграции

Итак, что же содержит файл миграции, и что действительно происходит при выполнении команды:

python manage.py migrate tweet

После ее выполнения, вы можете увидеть каталог migrations, где хранятся файлы миграции. Давайте взглянем на них.. так как это файлы Python, то их можно легко понять.

Откройте файл tweet/migrations/0001_initial.py, так как это файл, где создан код первоначальной миграции. Он должен выглядеть примерно так:

# -*- coding: utf-8 -*-
from  future  import unicode_literals
from django.db import models, migrations
class Migration(migrations.Migration): dependencies = [
('user_profile',	'first'),
]
operations = [
migrations.CreateModel( name='HashTag', fields=[
('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
('name', models.CharField(unique=True, max_length=64)),
3,
options = {
},
bases=(models.Model,),
) ,
migrations.CreateModel( name='Tweet', fields=[
('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
('text', models.CharField(max_length=160)),
('created_date', models.DateTimeField(auto_now_add=True)),
('country', models.CharField(default=b'Global', max_length=30)),
('is_active', models.BooleanField(default=True)),
('user', models.ForeignKey(to='user_profile.User')),
] ,
options = {
},
bases=(models.Model, ) ,
) ,
migrations.AddField( model_name='hashtag' , name='tweet',
field=models.ManyToManyField(to='tweet.Tweet'),preserve_default=True,
) ,
}

Для того, чтобы миграция действительно работала, здесь должен быть класс Migration () который наследует от модуля django.db.migrations.Migration. Это основной класс, который используют инструменты миграции, и этот класс миграции содержит два основных списка:

migrations.CreateModel ( 
name='HashTag',……
migrations.CreateModel(
name='Tweet',……..

Схема миграции – не единственное, что требуется для миграции при обновлении приложения; Другой важной вещью являются данные миграции.

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

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

Давайте поиграем с нашим проектом, загрузив твит из файла username.txt. Создайте пустую миграцию для нашего проекта, используя следующую команду:

python manage.py makemigrations --empty tweet

Это создаст файл миграции mytweets/migrations/003_auto<date_ time_stamp>.py.

Открыв этот файл, он будет выглядеть следующим образом:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
        ('tweets', '0002_auto_20150926_1834'),
    ]

    operations = [
    ]

Здесь нет ничего, кроме основной структуры инструмента миграции Django, и чтобы организовать миграцию данных, мы должны добавить функцию RunPython () — в операции, как показано:

#	 -*- coding: utf-8 -*-
from  future  import unicode_literals
from django.db import models, migrations
def load_data(apps, schema_editor):
Tweet(text= 'This is sample Tweet', created_date=date(2013,11,29), country='India', is_active=True,
) .save () 
class Migration(migrations.Migration):
dependencies = [
('tweet',	'0002_auto_20141215_0808 ' ),
]
operations = [
migrations.RunPython(load_data)
]

Теперь выполним команду migrate:

python manage.py migrate

Вот операции, которые вам необходимо выполнить:

Synchronize unmigrated apps: userprofile
Apply all migrations: admin, contenttypes, tweet, auth, sessions Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
Applying contenttypes.000linitial... FAKED
 Applying auth.0001initial... FAKED 
Applying admin.0001initial... FAKED 
Applying sessions.0001_initial... FAKED
 Applying tweet.0003_auto_20141215_1349 ... OK

После выполнения предыдущей команды, команда мигрировала все приложения и в наконец применила нашу миграцию, в которой мы создали новый твит из загруженных данных:

mysql> select * from tweettweet;
+	+	+	+	
| id | user_id | text | created_date | country | is_active |
+	+	+	+	
| 1 | 1 | This Tweet was uploaded from the file. | 2014-12-15 14:17:42 | India | 1 |
+-----+---------+-------------------------------------------+---------
2 rows in set (0.00 sec)

Невероятно, правда?

Этот типа решения очень необходим, когда у вас есть внешние данные в форме JSON или XML-файла.

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

python load data tweet/initial_data.json

Не забудьте добавить ваши каталоги миграции на Git, так как они так же важны, как и ваш исходный код.

Django с NoSQL

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

Для того, чтобы вам продемонстрировать работу, мы будем использовать проект Django-Norel для настройки Django с базой данных MongoDB.

Вы можете найти подробную информацию об этом на http://django-nonrel.org/.

MongoDB можно установить, выполнив шаги, указанные на http://docs.mongodb.org/manual/installation/ отталкиваясь от конфигурации, которая у вас есть.

Сейчас, мы настроим MongoDB для Debian- версии Linux (в частности, Ubuntu).

Импортируйте открытый ключ GPG MongoDB:

sudo apt-key adv--keyserver hkp://keyserver.ubuntu.com:80--recv 7F0CEB10

Создайте файл списка для MongoDB:

echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist lOgen' | sudo tee /etc/apt/sources.list.d/mongodb.list

Перезагрузите локальный пакет базы данных:

sudo apt-get update

Установите пакеты MongoDB:

sudo apt-get install -y mongodb-org

Запустите MongoDB:

sudo service mongod start

Проект одностраничного приложения – сокращатель URL-ссылок

Существует два способа, которыми MongoDB может использоваться совместно c Django, которые заключаются в следующем:

MongoEngine

Прежде чем двигаться дальше и показать вам, как настроить MongoEngine на совместную работу с Django, нам требуется установка MongoEngine. Установите MongoEngine, введя следующую команду:

pip install mongoengine

Для того чтобы защитить предыдущего проект, который мы создали и добиться лучшего понимания, мы создадим отдельный новый проект для конфигурации MongoDB, и мы используем наш существующий проект для настройки MySQL:

django-admin.py startproject url_shortner
cd url_shortner
python manage.py startapp url

Это создаст базовую структуру проекта, как мы очень хорошо знаем.

Подключение MongoDB совместно с Django

Нам придется изменить файл, settings.py, и если мы используем только MongoDB для проекта, что верно в данном случае, то мы можем игнорировать стандартный параметр базы данных. Все, что мы должны сделать - вызвать метод connect () на файл settings.py.

Мы разместим пустой внутренний интерфейс для MongoDB. Просто замените следующий код в файле settings.py, которое выглядит следующим образом:

DATABASES = {
'default' : {
'ENGINE':	'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}

Замените предыдущий код следующим:

DATABASES = {
'default' : {
'ENGINE':	'django.db.backends.dummy'
}
}

Аутентификация в Django

Преимуществом MongoEngine является, что он включает внутренний интерфейс аутентификации Django.

Модель пользователя становится документом MongoDB и имплементирует большинство методов и атрибутов нормальной модели пользователя Django , что делает MongoEngine совместимым с Django. Мы также можем использовать инфраструктуру аутентификации и декораторов, такие, как методы login_required () и authentication().Модуль auth также содержит метод get_user (), который принимает идентификатор пользователя в качестве аргумента и возвращает объект пользователя.

Для включения этого внутреннего интерфейса для MongoEngine, добавьте следующую запись в файл settings.py:

AUTHENTICATION_BACKENDS = (
'mongoengine.django.auth.MongoEngineBackend',
)

Хранение сеанса

В Django можно использовать различные базы данных для хранения сеанса приложения .Чтобы включить сеанс MongoEngine, который хранится в MongoDB, должна быть запись параметра django.contrib.sessions.middleware SessionMiddleware в MlDDLEWARE_CLASSES в файле settings.py. Также должна быть запись о django.contrib.sessions в INSTALLED_APPS, которая уже есть, так как мы начали проект с основной структуры Django.

Теперь все, что вам нужно сделать это добавить следующую строку в файл settings.py:

SESSION_ENGINE = 'mongoengine.django.sessions'
SESSION_SERIALIZER = 'mongoengine.django.sessions.BSONSerializer'

Сейчас мы все настроили для небольшого демонстрационного проекта, где мы имплементируем проект сокращателя URL-адресов на MongoDB.

Давайте создадим сперва URL-модель, в которой мы будем хранить все длинные и соответствующие им короткие URL-адреса.

Перейдите к файлу url/models.py:

from django.db import models 
from mongoengine import * 
connect('urlShortener')

Вы уже знакомы с двумя строками предыдущего кода, которые импортирует модули.

Третья строка, то есть, connect('urlShortener'), соединяет Django с базой данных MongoDB с именем urlShortener.

MongoDB предоставляет много механизмов подключения, и вы можете выбрать , как, в следующем фрагменте:

from mongoengine import connect
 connect('project')