Беглый опрос коллег по моему текущему проекту показал, что когда звучат слова «ORM и работа с базами данных», в подавляющем большинстве случаев звучат слова «Алхимия» и «Django ORM».
Знания этих двух слов обычно достаточно, чтобы писать чистый, аккуратный и работающий код. Но расширение нашего инженерного кругозора еще никому не повредило, поэтому сегодня мы добавим в нашу картину мира несколько (возможно, неизвестных ранее) крутых вещей для работы с базами данных.
Йо Йо
Сегодня любая ORM поставляется с внутренней системой миграции баз данных.Простой и классный подход, когда ORM следит за структурой таблиц, в целом устраивает всех.
Но у этого решения есть случай, когда его неудобно использовать:
- Есть ребята, которые пишут запросы к базе данных, не проходя через ORM. В данном случае используется что-то вроде asyncpg и небольшой самодельный патч для упрощения подготовки запросов.
Почему эти ребята отказываются от удобства ORM? Да потому, что любая обертка базы данных съедает определенное количество системных ресурсов, а этим ребятам нужно писать высокопроизводительный код. ORM выкинули, но базу как-то нужно перенести.
- Встроенные средства миграции могут иметь свои собственные взгляды на создание ссылок и индексацию записей.
Иногда невозможно преодолеть эти взгляды ORM на структуру таблиц; вам придется внести исправления в запрос самостоятельно.
.
Конечным результатом является чистая, понятная и полностью управляемая структура таблицы, продуманная до мелочей.
Для такого ручного подхода существует программа миграции схемы базы данных.
Йоу йоу .
Далее вся работа по управлению миграциями выполняется с помощью исполняемого файла yoyo.pip install yoyo-migrations
yoyo new .
/migrations -m "Add column to foo"
Команда создает файл, в который можно ввести одну или несколько инструкций по переносу схемы.
from yoyo import step
steps = [
step("CREATE TABLE foo (id INT, bar VARCHAR(20), PRIMARY KEY (id))",
"DROP TABLE foo"),
]
После этого миграции можно накатить на базу yoyo apply --database postgresql://scott:tiger@localhost/db .
/migrations
Все просто как бревно.
И при этом вы имеете абсолютно полный контроль над тем, как выглядит база данных.
У этого подхода есть два недостатка
- Вам придется вручную следить за набором полей в таблицах и их параметрами.
Каждое изменение приводит к необходимости писать ИЗМЕНИТЬ ТАБЛИЦУ самостоятельно вы теряете возможность перенести все в один клик.
- Такие миграции вам тоже всегда придется сливать руками и головой.
Это, конечно, дополнительная работа.
Но на практике конфликты и сложные миграционные механизмы редки.
Крошка
Небольшой и не самый популярный ORM (хотя о нем здесь писалось не раз), который, тем не менее, имеет свою аудиторию.
Peewee спроектирован как самая глупая и простая оболочка базы данных с наиболее понятным механизмом выполнения запросов и легко читаемым кодом.
Users.select().
where( Users.user_id == user_id ).
get()
Несмотря на свою простоту, минимализм и небольшой объем кода, в peewee есть все необходимое для вменяемой работы.
- Адекватная производительность (хотя и не самая высокая скорость запросов)
- Все необходимые вкусности — различные наборы полей, связи между сущностями, пулы связей, наборы плагинов и расширений.
- Есть ещё более-менее вменяемая асинхронность, добавленная сторонним модулем peewee_async .
Пони ОРМ
Пони - обертка, легендарная своей скоростью.Уровень базы данных, написанный с использованием этого ORM, может быть во много раз быстрее, чем другие решения.
Никакой магии в скорости нет, есть очень грамотная политика кэширования запросов в базы, куча оптимизаций и хитростей с кодом.
В сумме это приводит к тому, что Пони жарится со скоростью лошади.
Недостатком является синтаксис запросов в этой ORM — он очень специфичен, использует генераторы, лямбда-выражения и другие вкусности языка Python. query = select(c for c in Customer
if sum(o.total_price for o in c.orders) > 1000)
Product.select().
order_by(lambda p: desc(sum(p.order_items.quantity))).
first()
Этот подход требует определенного повреждения головного мозга.
Черепаха ОРМ
Копаясь в различных репозиториях Python, я нашел сбор тестов для разных ORM с измерением скорости.
Помимо уже упомянутого Pony ORM, в список самых быстрых вошел некий Черепаха ОРМ .
Понятно, что результаты тестов зависят от того, кто пишет тесты и как они их потом запускают, но к этой штуке надо присмотреться.
Tortoise — относительно молодой проект, который все еще находится в стадии активной разработки.
Хорошая производительность этой библиотеки объясняется тем, что ORM не содержит ничего лишнего и «из коробки» рассчитан на асинхронность.
Также предполагается использование увлуп , который работает быстрее, чем собственные циклы событий Python. Эта ORM еще слишком сырая для использования в бою (например, пулы соединений еще даже не реализованы), но за развитием этой библиотеки стоит следить.
Если у разработчиков все пойдет хорошо, в следующем году мы получим действительно быструю оболочку базы данных с хорошей скоростью и без странного синтаксиса в стиле Pony. Теги: #python #petty python радость
-
Владимир Владимирович Научит Вас Стучать
19 Oct, 24 -
Отличный Плагин Для Проверки Макета
19 Oct, 24 -
Css3-Калькулятор
19 Oct, 24 -
Ssd Теперь Доступен На 512 Гб
19 Oct, 24 -
Не Целевая Аудитория
19 Oct, 24
