Наверное всем известно, что Django является одним из самых популярных фреймворков для web-разработки на python-е. И даже если в основе web-проекта лежит сторонний код, то зачастую при разработке используют отдельные части этого фреймворка — например ORM. В данной статье я хотел бы рассказать об особенностях использования Django ORM при работе с базой данных MySQL, а именно про транзакции и подводные камни, связанные с ними. Так, например, если в какой-то момент вы осознаёте, что вместо ожидаемых данных, возвращается совершенно другой результат, то возможно, данная статья поможет разобраться что к чему.

Доброе время суток всем!
Как обещал ранее, а также по просьбе некоторых пользователей хабра выкладываю в сеть новый вариант эмулятора PEAR DB сделанный на основе PDO и успешно работающий с новыми версиями PHP. Скачать можно здесь (из раздела Code, ветка trunk) или здесь, а также используя snv
так: svn checkout svn://svn.code.sf.net/p/peardb2pdo/code/trunk peardb2pdo-code
или так: svn checkout svn.code.sf.net/p/peardb2pdo/code/trunk peardb2pdo-code

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

Лицензия: GNU General Public License .

Далее подробнее…

Предыстория

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

Количество записей в данной таблице до недавнего времени колебалось от 30 до 50 миллионов. Обычный OPTIMIZE даже при таких условиях не всегда срабатывал. Поэтому отец-основатель (Евгений Васильевич) придумал пересобирать таблицу таким образом: все актуальные (is_deleted = 0) копировались в таблицу с идентичной структурой с добавлением префикса по дате и времени, а когда копирование завершалось, оставалось только удалить исходную таблицу, а новую переименовать в исходную.

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

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

Большинство реляционных баз данных, за исключением MS Access, состоят из двух отдельных компонентов: «back-end», где хранятся данные и «front-end» — пользовательский интерфейс для взаимодействия с данными. Этот тип конструкции достаточно умный, так как он распараллеливает двухуровневую модель программирования, которая отделяет слой данных от пользовательского интерфейса и позволяет сконцентрировать рынок ПО непосредственно на улучшении своих продуктов. Эта модель открывает двери для третьих сторон, которые создают свои приложения для взаимодействия с различными базами данных.

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

Twitter опубликовала свои улучшения для MySQL.
Исходный код изменений распространяется под модифицированной лицензией BSD и располагается на GitHub
Более подробные изменения читайте под хабракатом.

Все мы помним хрестоматийное объяснение «что такое индексы в БД и как они облегчают задачи поиска нужных строк». Уверен, у большинства из вас перед глазами встаёт нечто подобное:



И сразу становится очевидно, насколько меньше данных нужно перелопатить для поиска двух-трёх нужных строк. Гениально. Просто. Понятно.

И лично мне всегда казалось, что улучшать эту схему некуда… Пока я не познакомился с кластерными индексами. Оказалось, что всё не так уж радужно с «обычными» индексами.

Итак, что же такое кластерный индекс, чем он лучше некластерного, и как с ним обстоит дело у MySQL.

Почта в своей конторе разрослась и наличие более чем 1 рабочего места у более чем 1 сотрудника начали требовать большего, нежели простейшая реализация мультидоменного почтового сервера на базе exim+teapop без использования mysql на обычных файликах. Главная причина изменений — постоянное вычищение спама и просто ненужных писем на каждом из рабочих мест по многу раз начало доставать, и было принято решение реализовать-таки почту по известной статье лиссяры "Связка exim и courier-imap". Самое главное, чего в ней не хватало из того, что требовалось, так это сортировщика писем по папкам. Для того, кто подписан на рассылки, весьма полезно раскладывать письма по требуемым каталогам, чтобы: а) не писать сортировщики в каждом клиенте; б) иметь такую же структуру папок при доступе к почте через веб, как и в почтовом клиенте.

Имеем MSSQL 2008
Хотим MySQL версии 5.х

Зачем это может быть нужно?

Для разработчиков на .NET променять MSSQL на MySQL это наверное все равно, что пересесть с мерседеса на что-то по-проще. Как говорится, к хорошему быстро привыкаешь.
Но есть как минимум две причины сделать это

• Сэкономить на лицензиях
• Получить простую master-slave репликацию

Работа с базой MSSQL в нашем случае осуществляется через LINQ провайдер.
При переходе, не хотелось бы терять эту возможность, поэтому для работы с MySQL выбор пал на BLToolkit.

Мигрируем

Самое простое — это переписать код. BLToolkit в отличие от MS-провайдера относится к классу легких ORM, поэтому там немного другие конструкции подключения к базе, но LINQ-выражения останутся теми же.

Думаете осталось перенести данные и все заработает?
Как бы не так.

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

В опубликованной накануне (февраль, 2012) статье озаглавленной «Определение страны по IP: тестируем скорость алгоритмов» сравнивались реализации на уровне БД и нативной реализации. Мы же предлагаем рассмотреть ещё более оптимальный и простой алгоритм, который может быть реализован как в БД, так и в нативном варианте – плоские диапазоны.