Comments 14
А почему RawSQL
, а не django.contrib.postgres.fields.KeyTextTransform
?
0
Да, django ORM мощная штука. Мы также юзаем всю мощь annotate/aggregate для всяких вычисляемых полей (для соблюдения нормальной формы БД). Но ИМХО сложность этого запроса очень высока, и поддержка его в дальнейшем будет очень дорогой. И скорость для ручки в 3 секунды тоже так себе результат.
Мы в своей практики для такого юзаем OLAP решения. Если данные как-то связанны с временем то timeseries DB, если случай как у вас то чтонить типа Vertica. И в этих таблицах уже храним денормализированные представления которое легко и удобно обсчитывать.
Конечно у такого подхода тоже есть минусы, это цена поддержки. Но такой подход нам больше нравится так как позволяет быть немного гибче в основной БД.
Мы в своей практики для такого юзаем OLAP решения. Если данные как-то связанны с временем то timeseries DB, если случай как у вас то чтонить типа Vertica. И в этих таблицах уже храним денормализированные представления которое легко и удобно обсчитывать.
Конечно у такого подхода тоже есть минусы, это цена поддержки. Но такой подход нам больше нравится так как позволяет быть немного гибче в основной БД.
0
OLAP
Vertica
timeseries DB
У нас всё это тоже есть, но больше используется для аналитики. Думаю стоит попробовать внедрить и в продукте.
И скорость для ручки в 3 секунды тоже так себе результат.
Это только первый ответ для большого партнера с сотнями бронирований. После
первого запроса кешируем результат на несколько минут и ручка отвечает в пределах 100 мс. За последние 90 дней среднее время ответа ручки — 600 мс. Для нас приемлемо, тем более, что это не ключевой функционал сервиса.
0
А почему бы еще не использовать решение в лоб но в фоне? Данные не выглядят как realtime можно формировать их раз в сутки и отдавать готовые на дашборд.
Плюсы:
* Проще код, проще поддержка
* Дешевле изменения
* Быстрая отдача
* Легче тестировать
* Нагрузка в вeчернее или ночное время на один slave
Минусы:
* Не реалтайм
* Инфраструктуры для бэкграунд подсчета (разработка, поддержка)
* Доп. данные для хранения
Плюсы:
* Проще код, проще поддержка
* Дешевле изменения
* Быстрая отдача
* Легче тестировать
* Нагрузка в вeчернее или ночное время на один slave
Минусы:
* Не реалтайм
* Инфраструктуры для бэкграунд подсчета (разработка, поддержка)
* Доп. данные для хранения
0
Не видел ничего тормазнутее Django ORM. Лет 5 нада это был полный адище с кучей клонирований query при конструировании сложного запроса, сейчас это исправили и стало просто медленно.
Если есть возможность использовать сырой SQL, используйте его. Он не сложнее ORM и это позволит исключить огромный непрозрачный слой абстракций.
Django ORM можно использовать для админок, простых и/или редких запросов и прототипов. Для остального лучше не надо.
Если есть возможность использовать сырой SQL, используйте его. Он не сложнее ORM и это позволит исключить огромный непрозрачный слой абстракций.
Django ORM можно использовать для админок, простых и/или редких запросов и прототипов. Для остального лучше не надо.
-2
Наверное джанго можно использовать не только для простых запросов.
К примеру с использованием поддержки JSON(B), кастомного Manager/переопределением objects + RawSQL можно делать уже вещи поинтересней. В джанге очень много основано на переопределении и сделав свой собственный QuerySet на основе стандартного, можно написать свою альтернативу взамен EAV.
А «сырой» SQL… да, может он и очевиден, но зачастую не так удобно поддерживать его после тех кто писал этот SQL.
К примеру с использованием поддержки JSON(B), кастомного Manager/переопределением objects + RawSQL можно делать уже вещи поинтересней. В джанге очень много основано на переопределении и сделав свой собственный QuerySet на основе стандартного, можно написать свою альтернативу взамен EAV.
А «сырой» SQL… да, может он и очевиден, но зачастую не так удобно поддерживать его после тех кто писал этот SQL.
0
А не практичнее для сложных запросов использовать SQLalchemy? Ведь посути она может работать парралельно джанговскому ORM по тем-же моделькам той-же базы если речь идет о только выборках без блокировки?
0
UFO just landed and posted this here
А не практичнее для сложных запросов использовать SQLalchemy?
Соглашусь с ArsenAbakarov, чем меньше поддерживать технологий и описаний моделей, тем лучше.
0
Если я правильно понял, ваша команда ведет разработку внутри компании и решения в виде кода/технологий не аутсорсятся наружу.
Если это так, вы можете дать оценку, насколько с точки зрения перфоманса и нагрузки, было бы выгодней (или наоборот) разработать свою «ORM» используя например паттерны того же М. Фаулера, под конкретные нужды конкретной предметной области?
Если это так, вы можете дать оценку, насколько с точки зрения перфоманса и нагрузки, было бы выгодней (или наоборот) разработать свою «ORM» используя например паттерны того же М. Фаулера, под конкретные нужды конкретной предметной области?
0
Да, разрабатываем сами.
Свою ORM писать не выгодно, потому что бизнесу нужен продукт и будет сложно обосновать, почему так много времени нужно на разработку велосипеда, ведь есть столько готовых решений. Но бывает и так, что все готовые решения не подходят, слишком медленные или не поддерживают что-то, тогда это может быть хорошим обоснованием.
Свою ORM писать не выгодно, потому что бизнесу нужен продукт и будет сложно обосновать, почему так много времени нужно на разработку велосипеда, ведь есть столько готовых решений. Но бывает и так, что все готовые решения не подходят, слишком медленные или не поддерживают что-то, тогда это может быть хорошим обоснованием.
0
Sign up to leave a comment.
Не ORMом единым