Мой проект Django будет поддерживаться большой базой данных с несколькими сотнями тысяч записей и будет нуждаться в поддержке поиска (я, вероятно, в конечном итоге начну использовать djangosearch или аналогичный проект.)
Какой бэкэнд базы данных лучше всего подходит для моего проекта и почему? Можете ли вы рекомендовать какие-либо хорошие ресурсы для дальнейшего чтения?
Как кто-то, кто недавно переключил проект с MySQL на Postgresql, я не жалею об этом.
Основное отличие, с точки зрения Django, - это более строгая проверка ограничений в Postgresql, что хорошо, а также немного утомительно выполнять ручные изменения схемы (например, миграции).
Есть, вероятно, 6 или около того приложений миграции базы данных Django, и по крайней мере один из них не поддерживает Postgresql. Я не считаю это недостатком, потому что вы можете использовать один из других или делать это вручную (это то, что я предпочитаю atm).
Полнотекстовый поиск может быть лучше поддержан для MySQL. MySQL имеет встроенный полнотекстовый поиск, поддерживаемый в Django, но он довольно бесполезен (без слов, фразы и т.д.). Я использовал django-sphinx как лучший вариант для полнотекстового поиска в MySQL.
Полнотекстовый поиск встроен в Postgresql 8.3 (более ранние версии нуждаются в модуле TSearch). Вот хороший учебный пост в блоге: Полнотекстовый поиск в Django с PostgreSQL и tsearch2
За все, что стоит, создатели Django рекомендуют PostgreSQL.
Если вы не привязаны к какому-либо наследию системы и имеют свободу выбора базы данных, мы рекомендуем PostgreSQL, который достигает штрафа баланс между стоимостью, функциями, скоростью и стабильность. (Полное руководство по Django, стр. 15)
большая база данных с несколькими сотнями тыс. записей,
Это не большая база данных, она очень маленькая.
Я бы выбрал PostgreSQL, потому что он имеет намного больше функций. Самое главное это в этом случае: в PostgreSQL вы можете использовать Python в качестве процедурного языка.
Пойдите с тем, что вам больше знакомо. MySQL против PostgreSQL - это бесконечная война. Оба они отличные двигатели базы данных, и оба они используются основными сайтами. Это действительно не имеет значения на практике.
Даже если Postgresql выглядит лучше, я считаю, что он имеет некоторые проблемы с Django:
Postgresql предназначен для обработки "длинных соединений" (пул соединений, постоянных подключений и т.д.).
MySQL создан для обработки "коротких соединений" (подключение, выполнение запросов, отключение, имеет некоторые проблемы с множеством открытых подключений)
Проблема в том, что Django не поддерживает объединение пулов или постоянное соединение, он должен подключиться/отключиться от базы данных при каждом вызове вида.
Он будет работать с Postgresql, но подключение к Postgresql обойдется LOT больше, чем подключение к базе данных MySQL (On Postgresql, каждое соединение имеет собственный процесс, оно намного медленнее, чем просто появление нового потока в MySQL).
Затем вы получаете некоторые функции, такие как Query Cache, которые могут быть действительно полезны в некоторых случаях. (Но вы потеряли превосходный текстовый поиск PostgreSQL)
Все ответы приносят интересную информацию в таблицу, но некоторые немного устарели, так что здесь мое зерно соли.
Начиная с 1.7, миграции теперь являются неотъемлемой чертой Django. Таким образом, они задокументировали основные различия, которые разработчики Django могли бы хотеть знать заранее.
Поддержка бэкэнда
Миграции поддерживаются во всех бэкэндах, с которыми поставляется Django, а также во всех сторонних бэкэндах, если они запрограммированы для поддержки изменения схемы (выполняется через класс SchemaEditor).
Однако некоторые базы данных более эффективны, чем другие, когда дело доходит до миграции схемы; некоторые предостережения описаны ниже.
PostgreSQL
PostgreSQL является самой способной из всех баз данных здесь с точки зрения поддержки схемы; Единственное предостережение в том, что добавление столбцов со значениями по умолчанию приведет к полной перезаписи таблицы за время, пропорциональное ее размеру.
По этой причине рекомендуется всегда создавать новые столбцы с null = True, так как они будут добавлены немедленно.
MySQL
В MySQL отсутствует поддержка транзакций, связанных с операциями изменения схемы, а это означает, что если миграция не будет применена, вам придется вручную отменить изменения, чтобы повторить попытку (откат к предыдущей точке невозможен).
Кроме того, MySQL будет полностью переписывать таблицы практически для каждой операции схемы и обычно для добавления или удаления столбцов требуется время, пропорциональное количеству строк в таблице. На более медленном оборудовании это может быть хуже, чем минута на миллион строк - добавление нескольких столбцов в таблицу с несколькими миллионами строк может заблокировать ваш сайт более чем на десять минут.
Наконец, MySQL имеет достаточно небольшие ограничения на длину имен для столбцов, таблиц и индексов, а также ограничение на объединенный размер всех столбцов, охватываемых индексом. Это означает, что индексы, которые возможны на других серверах, не будут созданы под MySQL.
SQLite
SQLite имеет очень мало встроенной поддержки изменения схемы, и поэтому Django пытается эмулировать это:
- Создание новой таблицы с новой схемой
- Копирование данных через
- Сбрасывать старый стол
- Переименование новой таблицы в соответствии с исходным именем
Этот процесс обычно работает хорошо, но он может быть медленным и иногда глючить. Не рекомендуется запускать и переносить SQLite в производственной среде, если вы не очень осведомлены о рисках и их ограничениях; Поддержка, поставляемая Django, предназначена для того, чтобы позволить разработчикам использовать SQLite на своих локальных машинах для разработки менее сложных проектов Django без необходимости полной базы данных.
Когда миграция завершается неудачей в django-south, разработчики рекомендуют вам не использовать MySQL:
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
Чтобы добавить к предыдущим ответам:
Индекс FULLTEXT в MySQL - это шутка.
Другими причинами, не упомянутыми, являются чрезвычайно оптимизированный оптимизатор запросов, большой выбор типов соединений (слияние, хеш и т.д.), агрегация хешей, индексы gist на массивах, пространственный поиск и т.д., что может привести к чрезвычайно быстрым планам по очень сложным запросам.
Будет ли это приложение размещено на ваших собственных серверах или хостинговой компанией? Убедитесь, что если вы используете хостинговую компанию, они поддерживают базу данных по выбору.
Существует большая разница в лицензировании между двумя db, которые повлияют на вас, если вы когда-либо собираетесь распространять код с помощью db. MySQL-клиентские библиотеки GPL и PostegreSQL находятся под лицензией BSD, с которой может быть проще работать.
Пройдя путь MySQL, потому что я был знаком с ним (и изо всех сил пытался найти подходящий установщик и быстрый тест медленного веб-интерфейса "рабочей среды" postgreSQL, меня оттолкнул), в конце проекта, после нескольких Спустя месяцы после развертывания, просматривая варианты резервного копирования, я вижу, что вы должны заплатить за корпоративные функции MySQL. Попался прямо в самый конец.
Мне пришлось написать несколько уродливых необработанных SQL-запросов на монстра в Django, потому что не было выбранных отдельных групп для получения последних запросов для каждой группы. Также, глядя на полнотекстовый поиск в postgreSQL, я хотел использовать postgresSQL.
Я рекомендую PostgreSQL, даже если вы знакомы с MySQL, но ваш пробег может отличаться.