[Высокая производительность, Python, SQL, Проектирование и рефакторинг, ООП] SQLAlchemy: а ведь раньше я презирал ORM
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Так вышло, что на заре моей карьеры в IT меня покусал Oracle -- тогда я ещё не знал ни одной ORM, но уже шпарил SQL и знал, насколько огромны возможности БД.Знакомство с DjangoORM ввело меня в глубокую фрустрацию. Вместо возможностей -- хрена с два, а не составной первичный ключ или оконные функции. Специфические фичи БД проще забыть. Добивало то, что по цене нулевой гибкости мне продавали падение же производительности -- сборка ORM-запроса не бесплатная. Ну и вишенка на торте -- в дополнение к синтаксису SQL надо знать ещё и синтаксис ORM, который этот SQL сгенерирует. Недостатки, которые я купил за дополнительную когнитивную нагрузку -- вот уж где достижение индустрии. Поэтому я всерьёз считал, что без ORM проще, гибче и в разы производительнее -- ведь у вас в руках все возможности БД.Так вот, эта история с SQLAlchemy -- счастливая история о том, как я заново открыл для себя ORM. В этой статье я расскажу, как я вообще докатился до такой жизни, о некоторых подводных камнях SQLAlchemy, и под конец перейду к тому, что вызвало у меня бурный восторг, которым попытаюсь с вами поделиться.Опыт и как результат субъективная система взглядовЯ занимался оптимизацией SQL-запросов. Мне удавалось добиться стократного и более уменьшения cost запросов, в основном для Oracle и Firebird. Я проводил исследования, экспериментировал с индексами. Я видел в жизни много схем БД: среди них были как некоторое фекалии, так и продуманные гибкие и расширяемые инженерные решения.Этот опыт сформировал у меня систему взглядов касательно БД:
- ORM не позволяет забыть о проектировании БД, если вы не хотите завтра похоронить проект
- Переносимость -- миф, а не аргумент:
- Если ваш проект работает с postgres через ORM, то вы на локальной машине разворачиваете в докере postgres, а не работаете с sqlite
- Вы часто сталкивались с переходом на другую БД? Не пишите только "Однажды мы решили переехать..." -- это было однажды. Если же это происходит часто или заявленная фича, оправданная разными условиями эксплуатации у разных ваших клиентов -- милости прошу в обсуждения
- У разных БД свои преимущества и болячки, всё это обусловлено разными структурами данных и разными инженерными решениями. И если при написании приложения мы используем верхний мозг, мы пытаемся избежать этих болячек. Тема глубокая, и рассмотрена в циклах лекций Базы данных для программиста и Транзакции от Владимира Кузнецова
- Структура таблиц определяется вашими данными, а не ограничениями вашей ORM
Естественно, я ещё и код вне БД писал, и касательно этого кода у меня тоже сформировалась система взглядов:
- Контроллер должен быть тонким, а лучший код -- это тот код, которого нет. Код ORM -- это часть контроллера. И если код контроллера спрятан в библиотеку, это не значит, что он стал тонким -- он всё равно исполняется
- Контроллер, выполняющий за один сеанс много обращений к БД -- это очень тонкий лёд
- Я избегаю повсеместного использования ActiveRecord -- это верный способ как работать с неконсистентными данными, так и незаметно для себя сгенерировать бесконтрольное множество обращений к БД
- Оптимизация работы с БД сводится к тому, что мы не читаем лишние данные. Есть смысл запросить только интересующий нас список колонок
- Часть данных фронт всё равно запрашивает при инициализации. Чаще всего это категории. В таких случаях нам достаточно отдать только id
- Отладка всех новых запросов ORM обязательна. Всегда надо проверять, что там ORM высрала (тут пара сочных примеров), дабы не было круглых глаз. Даже при написании этой статьи у меня был косяк как раз по этому пункту
Идея сокращения по возможности количества выполняемого кода в контроллере приводит меня к тому, что проще всего возиться не с сущностями, а сразу запросить из БД в нужном виде данные, а выхлоп можно сразу отдать сериализатору JSON.Все вопросы данной статьи происходят из моего опыта и системы взглядовОни могут и не найти в вас отголоска, и это нормальноМы разные, и у нас всех разный фокус внимания. Я общался с разными разработчиками. Я видел разные позиции, от "да не всё ли равно, что там происходит? Работает же" до "я художник, у меня справка есть". При этом у некоторых из них были другие сильные стороны. Различие позиций -- это нормально. Невозможно фокусироваться на всех аспектах одновременно.Мне, например, с большего без разницы, как по итогу фронт визуализирует данные, хотя я как бы фулстэк. Чем я отличаюсь от "да не всё ли равно, что там происходит"? Протокол? Да! Стратегия и оптимизация рендеринга? Да! Упороться в WebGL? Да! А что по итогу на экране -- пофиг.Знакомство в SQLAlchemyПервое, что бросилось в глаза -- возможность писать DML-запросы в стиле SQL, но в синтаксисе python:
order_id = bindparam('order_id', required=True)
return \
select(
func.count(Product.id).label("product_count"),
func.sum(Product.price).label("order_price"),
Customer.name,
)\
.select_from(Order)\
.join(
Product,
onclause=(Product.id == Order.product_id),
)\
.join(
Customer,
onclause=(Customer.id == Order.customer_id),
)\
.where(
Order.id == order_id,
)\
.group_by(
Order.id,
)\
.order_by(
Product.id.desc(),
)
Этим примером кода я хочу сказать, что ORM не пытается изобрести свои критерии, вместо этого она пытается дать нечто, максимально похожее на SQL. К сожалению, я заменил реальный фрагмент ORM-запроса текущего проекта, ибо NDA. Пример крайне примитивен -- он даже без подзапросов. Кажется, в моём текущем проекте таких запросов единицы.Естественно, я сразу стал искать, как тут дела с составными первичными ключами -- и они есть! И оконные функции, и CTE, и явный JOIN, и много чего ещё! Для особо тяжёлых случаев можно даже впердолить SQL хинты! Дальнейшее погружение продолжает радовать: я не сталкивался ни с одним вопросом, который решить было невозможно из-за архитектурных ограничений. Правда, некоторые свои вопросы я решал через monkey-patching.ПроизводительностьНасколько крутым и гибким бы ни было API, краеугольным камнем является вопрос производительности. Сегодня вам может и хватит 10 rps, а завтра вы пытаетесь масштабироваться, и если затык в БД -- поздравляю, вы мертвы.Производительность query builder в SQLAlchemy оставляет желать лучшего. Благо, это уровень приложения, и тут масштабирование вас спасёт. Но можно ли это как-то обойти? Можно ли как-то нивелировать низкую производительность query builder? Нет, серьёзно, какой смысл тратить мощности ради увеличения энтропии Вселенной?В принципе, нам на python не привыкать искать обходные пути: например, python непригоден для реализации числодробилок, поэтому вычисления принято выкидывать в сишные либы.Для SQLAlchemy тоже есть обходные пути, и их сразу два, и оба сводятся к кэшированию по разным стратегиям. Первый -- применение bindparam и lru_cache. Второй предлагает документация -- future_select. Рассмотрим их преимущества и недостатки.bindparam + lru_cacheЭто самое простое и при этом самое производительное решение. Мы покупаем производительность по цене памяти -- просто кэшируем собранный объект запроса, который в себе кэширует отрендеренный запрос. Это выгодно до тех пор, пока нам не грозит комбинаторный взрыв, то есть пока число вариаций запроса находится в разумных пределах. В своём проекте в большинстве представлений я использую именно этот подход. Для удобства я применяю декоратор cached_classmethod, реализующий композицию декораторов classmethod и lru_cache:
from functools import lru_cache
def cached_classmethod(target):
cache = lru_cache(maxsize=None)
cached = cache(target)
cached = classmethod(cached)
return cached
Для статических представлений тут всё понятно -- функция, создающая ORM-запрос не должна принимать параметров. Для динамических представлений можно добавить аргументы функции. Так как lru_cache под капотом использует dict, аргументы должны быть хешируемыми. Я остановился на варианте, когда функция-обработчик запроса генерирует "сводку" запроса и параметры, передаваемые в сгенерированный запрос во время непосредственно исполнения. "Сводка" запроса реализует что-то типа плана ORM-запроса, на основании которой генерируется сам объект запроса -- это хешируемый инстанс frozenset, который в моём примере называется query_params:
class BaseViewMixin:
def build_query_plan(self):
self.query_kwargs = {}
self.query_params = frozenset()
async def main(self):
self.build_query_plan()
query = self.query(self.query_params)
async with BaseModel.session() as session:
respone = await session.execute(
query,
self.query_kwargs,
)
mappings = respone.mappings()
return self.serialize(mappings)
Некоторое пояснение по query_params и query_kwargsВ простейшем случае query_params можно получить, просто преобразовав ключи query_kwargs во frozenset. Обращаю ваше внимание, что это не всегда справедливо: флаги в query_params запросто могут поменять сам SQL-запрос при неизменных query_kwargs.На всякий случай предупреждаю: не стоит слепо копировать код. Разберитесь с ним, адаптируйте под свой проект. Даже у меня данный код на самом деле выглядит немного иначе, он намеренно упрощён, из него выкинуты некоторые несущественные детали.Сколько же памяти я заплатил за это? А немного. На все вариации запросов я расходую не более мегабайта.future_selectВ отличие от дубового первого варианта, future_select кэширует куски SQL-запросов, из которых итоговый запрос собирается очень быстро. Всем хорош вариант: и высокая производительность, и низкое потребление памяти. Читать такой код сложно, сопровождать дико:
stmt = lambdas.lambda_stmt(lambda: future_select(Customer))
stmt += lambda s: s.where(Customer.id == id_)
Этот вариант я обязательно задействую, когда дело будет пахнуть комбинаторным взрывом.Наброски фасада, решающего проблему дикого синтаксисаПо идее, future_select через FutureSelectWrapper можно пользоваться почти как старым select, что нивелирует дикий синтаксис:
class FutureSelectWrapper:
def __init__(self, clause):
self.stmt = lambdas.lambda_stmt(
lambda: future_select(clause)
)
def __getattribute__(self, name):
def outer(clause):
def inner(s):
callback = getattr(s, name)
return callback(clause)
self.stmt += inner
return self
return outer
Я обращаю ваше внимание, что это лишь наброски. Я их ни разу не запускал. Необходимы дополнительные исследования.Промежуточный вывод: низкую производительность query builder в SQLAlchemy можно нивелировать кэшем запросов. Дикий синтаксис future_select можно спрятать за фасадом.А ещё я не уделил должного внимания prepared statements. Эти исследования я проведу чуть позже.Как я открывал для себя ORM зановоМы добрались главного -- ради этого раздела я писал статью. В этом разделе я поделюсь своими откровениями, посетившими меня в процессе работы.МодульностьКогда я реализовывал на SQL дикую аналитику, старой болью отозвалось отсутствие модульности и интроспекции. При последующем переносе на ORM у меня уже была возможность выкинуть весь подзапрос поля FROM в отдельную функцию (по факту метод класса), а в последующем эти функции было легко комбинировать и на основании флагов реализовывать паттерн Стратегия, а также исключать дублирование одинакового функционала через наследование.Собственные типыЕсли данные обладают хитрым поведением, или же хитро преобразуются, совершенно очевидно, что их надо выкинуть на уровень модели. Я столкнулся с двумя вопросами: хранение цвета и работа с ENUM. Погнали по порядку.Создание собственных простых типов рассмотрено в документации:
class ColorType(TypeDecorator):
impl = Integer
cache_ok = True
def process_result_value(self, value, dialect):
if value is None:
return
return color(value)
def process_bind_param(self, value, dialect):
if value is None:
return
value = color(value)
return value.value
Сыр-бор тут только в том, что мне стрельнуло хранить цвета не строками, а интами. Это исключает некорректность данных, но усложняет их сериализацию и десериализацию.Теперь про ENUM. Меня категорически не устроило, что документация предлагает хранить ENUM в базе в виде VARCHAR. Особенно уникальные целочисленные Enum хотелось хранить интами. Очевидно, объявлять этот тип мы должны, передавая аргументом целевой Enum. Ну раз String при объявлении требует указать длину -- задача, очевидно, уже решена. Штудирование исходников вывело меня на TypeEngine -- и тут вместо примеров использования вас встречает "our source code is open 24/7". Но тут всё просто:
class IntEnumField(TypeEngine):
def __init__(self, target_enum):
self.target_enum = target_enum
self.value2member_map = target_enum._value2member_map_
self.member_map = target_enum._member_map_
def get_dbapi_type(self, dbapi):
return dbapi.NUMBER
def result_processor(self, dialect, coltype):
def process(value):
if value is None:
return
member = self.value2member_map[value]
return member.name
return process
def bind_processor(self, dialect):
def process(value):
if value is None:
return
member = self.member_map[value]
return member.value
return process
Обратите внимание: обе функции -- result_processor и bind_processor -- должны вернуть функцию.Собственные функции, тайп-хинты и вывод типовДальше больше. Я столкнулся со странностями реализации json_arrayagg в mariadb: в случае пустого множества вместо NULL возвращается строка "[NULL]" -- что ни под каким соусом не айс. Как временное решение я накостылил связку из group_concat, coalesce и concat. В принципе неплохо, но:
- При вычитывании результата хочется нативного преобразования строки в JSON.
- Если делать что-то универсальное, то оказывается, что строки надо экранировать. Благо, есть встроенная функция json_quote. Про которую SQLAlchemy не знает.
- А ещё хочется найти workaround-функции в объекте sqlalchemy.func
Оказывается, в SQLAlchemy эти проблемы решаются совсем влёгкую. И если тайп-хинты мне показались просто удобными, то вывод типов поверг меня в восторг: типозависимое поведение можно инкапсулировать в саму функцию, что сгенерирует правильный код на SQL.Мне заказчик разрешил опубликовать код целого модуля!
from sqlalchemy.sql.functions import GenericFunction, register_function
from sqlalchemy.sql import sqltypes
from sqlalchemy import func, literal_column
def register(target):
name = target.__name__
register_function(name, target)
return target
# === Database functions ===
class json_quote(GenericFunction):
type = sqltypes.String
inherit_cache = True
class json_object(GenericFunction):
type = sqltypes.JSON
inherit_cache = True
# === Macro ===
empty_string = literal_column("''", type_=sqltypes.String)
json_array_open = literal_column("'['", type_=sqltypes.String)
json_array_close = literal_column("']'", type_=sqltypes.String)
@register
def json_arrayagg_workaround(clause):
clause_type = clause.type
if isinstance(clause_type, sqltypes.String):
clause = func.json_quote(clause)
clause = func.group_concat(clause)
clause = func.coalesce(clause, empty_string)
return func.concat(
json_array_open,
clause,
json_array_close,
type_=sqltypes.JSON,
)
def __json_pairs_iter(clauses):
for clause in clauses:
clause_name = clause.name
clause_name = "'%s'" % clause_name
yield literal_column(clause_name, type_=sqltypes.String)
yield clause
@register
def json_object_wrapper(*clauses):
json_pairs = __json_pairs_iter(clauses)
return func.json_object(*json_pairs)
В рамках эксперимента я также написал функцию json_object_wrapper, которая из переданных полей собирает json, где ключи -- это имена полей. Буду использовать или нет -- ХЗ. Причём тот факт, что эти макроподстановки не просто работают, а даже правильно, меня немного пугает.Примеры того, что генерирует ORM
SELECT concat(
'[',
coalesce(group_concat(product.tag_id), ''),
']'
) AS product_tags
SELECT json_object(
'name', product.name,
'price', product.price
) AS product,
PS: Да, в случае json_object_wrapper я изначально допустил ошибку. Я человек простой: вижу константу -- вношу её в код. Что привело к ненужным bindparam на месте ключей этого json_object. Мораль -- держите ORM в ежовых рукавицах. Упустите что-то -- и она вам такого нагенерит! Только literal_column позволяет надёжно захардкодить константу в тело SQL-запроса.Такие макроподстановки позволяют сгенерировать огромную кучу SQL кода, который будет выполнять логику формирования представлений. И что меня восхищает -- эта куча кода работает эффективно. Ещё интересный момент -- эти макроподстановки позволят прозрачно реализовать паттерн Стратегия -- я надеюсь, поведение json_arrayagg пофиксят в следующих релизах MariaDB, и тогда я смогу своё костылище заменить на связку json_arrayagg+coalesce незаметно для клиентского кода.ВыводыSQLAlchemy позволяет использовать преимущества наследования и полиморфизма (и даже немного иннкапсуляции. Флеш-рояль, однако) в SQL. При этом она не загоняет вас в рамки задач уровня Hello, World! архитектурными ограничениями, а наоборот даёт вам максимум возможностей.Субъективно это прорыв. Я обожаю реляционные базочки, и наконец-то я получаю удовольствие от реализации хитрозакрученной аналитики. У меня в руках все преимущества ООП и все возможности SQL.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка под Android, Dart, Flutter] Основы Flutter для начинающих (Часть VI)
- [Python, TensorFlow] Упадок RNN и LSTM сетей (перевод)
- [Высокая производительность, Управление разработкой, Agile, IT-компании] Как масштабировать разработку при 400 000 RPM и не надорваться
- [Высокая производительность, DevOps, Микросервисы, Kubernetes] Заболел – не значит умер
- [Высокая производительность, Веб-дизайн, Визуализация данных, Дизайн] Топ-5 софт-навыков дизайнера в банке
- [Python, Программирование] Искусство написания циклов на Python (перевод)
- [Системное администрирование, PostgreSQL, Администрирование баз данных] Grafana дашборды для pgSCV
- [Программирование, Assembler, *nix, Алгоритмы, История IT] Процессор, эмулирующий сам себя — может быть быстрее самого себя
- [Мессенджеры, ООП, Функциональное программирование, Kotlin, Natural Language Processing] Распознавание команд
- [Python] Автоматизация тестирования на Python: Шесть способов тестировать эффективно (перевод)
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_python, #_sql, #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_oop (ООП), #_sqlalchemy, #_orm, #_pyhon, #_sql, #_database_design, #_vysokaja_proizvoditelnost (
Высокая производительность
), #_python, #_sql, #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_oop (
ООП
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 02:55
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Так вышло, что на заре моей карьеры в IT меня покусал Oracle -- тогда я ещё не знал ни одной ORM, но уже шпарил SQL и знал, насколько огромны возможности БД.Знакомство с DjangoORM ввело меня в глубокую фрустрацию. Вместо возможностей -- хрена с два, а не составной первичный ключ или оконные функции. Специфические фичи БД проще забыть. Добивало то, что по цене нулевой гибкости мне продавали падение же производительности -- сборка ORM-запроса не бесплатная. Ну и вишенка на торте -- в дополнение к синтаксису SQL надо знать ещё и синтаксис ORM, который этот SQL сгенерирует. Недостатки, которые я купил за дополнительную когнитивную нагрузку -- вот уж где достижение индустрии. Поэтому я всерьёз считал, что без ORM проще, гибче и в разы производительнее -- ведь у вас в руках все возможности БД.Так вот, эта история с SQLAlchemy -- счастливая история о том, как я заново открыл для себя ORM. В этой статье я расскажу, как я вообще докатился до такой жизни, о некоторых подводных камнях SQLAlchemy, и под конец перейду к тому, что вызвало у меня бурный восторг, которым попытаюсь с вами поделиться.Опыт и как результат субъективная система взглядовЯ занимался оптимизацией SQL-запросов. Мне удавалось добиться стократного и более уменьшения cost запросов, в основном для Oracle и Firebird. Я проводил исследования, экспериментировал с индексами. Я видел в жизни много схем БД: среди них были как некоторое фекалии, так и продуманные гибкие и расширяемые инженерные решения.Этот опыт сформировал у меня систему взглядов касательно БД:
order_id = bindparam('order_id', required=True)
return \ select( func.count(Product.id).label("product_count"), func.sum(Product.price).label("order_price"), Customer.name, )\ .select_from(Order)\ .join( Product, onclause=(Product.id == Order.product_id), )\ .join( Customer, onclause=(Customer.id == Order.customer_id), )\ .where( Order.id == order_id, )\ .group_by( Order.id, )\ .order_by( Product.id.desc(), ) from functools import lru_cache
def cached_classmethod(target): cache = lru_cache(maxsize=None) cached = cache(target) cached = classmethod(cached) return cached class BaseViewMixin:
def build_query_plan(self): self.query_kwargs = {} self.query_params = frozenset() async def main(self): self.build_query_plan() query = self.query(self.query_params) async with BaseModel.session() as session: respone = await session.execute( query, self.query_kwargs, ) mappings = respone.mappings() return self.serialize(mappings) stmt = lambdas.lambda_stmt(lambda: future_select(Customer))
stmt += lambda s: s.where(Customer.id == id_) class FutureSelectWrapper:
def __init__(self, clause): self.stmt = lambdas.lambda_stmt( lambda: future_select(clause) ) def __getattribute__(self, name): def outer(clause): def inner(s): callback = getattr(s, name) return callback(clause) self.stmt += inner return self return outer class ColorType(TypeDecorator):
impl = Integer cache_ok = True def process_result_value(self, value, dialect): if value is None: return return color(value) def process_bind_param(self, value, dialect): if value is None: return value = color(value) return value.value class IntEnumField(TypeEngine):
def __init__(self, target_enum): self.target_enum = target_enum self.value2member_map = target_enum._value2member_map_ self.member_map = target_enum._member_map_ def get_dbapi_type(self, dbapi): return dbapi.NUMBER def result_processor(self, dialect, coltype): def process(value): if value is None: return member = self.value2member_map[value] return member.name return process def bind_processor(self, dialect): def process(value): if value is None: return member = self.member_map[value] return member.value return process
from sqlalchemy.sql.functions import GenericFunction, register_function
from sqlalchemy.sql import sqltypes from sqlalchemy import func, literal_column def register(target): name = target.__name__ register_function(name, target) return target # === Database functions === class json_quote(GenericFunction): type = sqltypes.String inherit_cache = True class json_object(GenericFunction): type = sqltypes.JSON inherit_cache = True # === Macro === empty_string = literal_column("''", type_=sqltypes.String) json_array_open = literal_column("'['", type_=sqltypes.String) json_array_close = literal_column("']'", type_=sqltypes.String) @register def json_arrayagg_workaround(clause): clause_type = clause.type if isinstance(clause_type, sqltypes.String): clause = func.json_quote(clause) clause = func.group_concat(clause) clause = func.coalesce(clause, empty_string) return func.concat( json_array_open, clause, json_array_close, type_=sqltypes.JSON, ) def __json_pairs_iter(clauses): for clause in clauses: clause_name = clause.name clause_name = "'%s'" % clause_name yield literal_column(clause_name, type_=sqltypes.String) yield clause @register def json_object_wrapper(*clauses): json_pairs = __json_pairs_iter(clauses) return func.json_object(*json_pairs) SELECT concat(
'[', coalesce(group_concat(product.tag_id), ''), ']' ) AS product_tags SELECT json_object(
'name', product.name, 'price', product.price ) AS product, =========== Источник: habr.com =========== Похожие новости:
Высокая производительность ), #_python, #_sql, #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ), #_oop ( ООП ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 02:55
Часовой пояс: UTC + 5