Почему мы используем именно данные технологии? Пояснительная записка от руководителя Django направления нашей компании Сергея Белентьева. В будущем планируем добавить пояснительные записки от руководителей других отделов.
Django отдел использует стек: - Django - Django rest framework - Postgresql - S3 (minio/cloud) - CDN - KeyDB (Redis) - Qdrant - Advantage (внутренняя библиотека tltpro для django)
Один из самых популярных и распространённых web фреймворков для python. Его главные фичи: ORM, система миграций, встроенная админ панель для разработчиков, жёсткая структура проекта, большое количество функционала (на уровне обвязки), широкая поддержка сообщества.
Orm - библиотека, которая позволяет составлять sql запросы на чистом python ни как не взаимодействуя с базой данных напрямую. Такой подход ускоряет разработку проекта, стандартизирует код, увеличивает его читаемость, а так же добавляет дополнительный слой защиты от sql инъекций.
Система изменения структуры БД без потери данных. Представим ситуацию, когда проект находиться в production(вышел на рынок), в БД есть данные реальных пользователей и мы не хотим их терять. Как же нам внедрять новый функционал? Система миграций позволяет в автоматическом режиме записать необходимые изменения в структуре таблиц БД для внедрения нового функционала, а затем применить их на целевой БД. Данная автоматизация снижает риски при каждом обновлении, так как сильно уменьшает влияние человеческого фактора на процесс обновления структуры таблиц БД. Что в общей сумме даёт команде больше ресурсов на то, чтобы сфокусироваться на функционале системы.
В django есть встроенная админ-панель, в которую можно добавить CRUD для любой таблицы в БД парой строк кода. Однако, при необходимости, любой функционал админ панели можно переписать под свои нужны. Это очень сильно упрощает разработку, отладку и тестирование продукта.
Django фреймворк задаёт "жёсткую" структуру проекта. В первую очередь это означает, что весь функционал должен быть разделён на функциональные "модули". Каждый модуль, в свою очередь, представляет собой регламентированный набор файлов: модели, вьюшки(view) и роуты. Таким образом: - Увеличивается стандартизация кода - Структура кода соответствует стандартам ООП python - В коде становиться проще ориентироваться, а значит проще дописывать новый функционал, искать и исправлять баги - Необходимо меньше времени на интеграцию нового разработчика в проект
Django предоставляет большое количество базового функционала, но важно не путать его с готовыми решениями. Помимо orm и админ панели, из коробки идёт система авторизации, формы, Content Types, миграции БД, middelwares, подсистема настроек, абстракции для всех http сущностей (request, response и тд), generic view классы, декораторы и тд. Большой набор инструментов позволяет уделять больше времени реализации функционала продукта, не беспокоясь о промежуточных слоях системы.
Django - фреймворк проверенный временем и полюбившийся сообществом, поэтому он имеет широкий спектр готовых решений как с точки зрения расширения функционала, так и с точки зрения интеграций. Большинство коммерческих it компаний, специализирующихся на продаже решений для backend разработки, имеют интеграцию с django. В ином случае, зачастую, существует интеграции написанные сообществом. Помимо интеграций, комьюнити публикует и поддерживает множество библиотек расширяющих функционал django, предоставляя решение для какой-то конкретной функциональной проблемы.
Библиотека для Django. Отличный пример работы сообщества над добавлением дополнительного функционала в Django. Изначальная философия django - всё в одном: мы предоставили тебе инструмент, чтобы собрать полноценную web систему без использования сторонних сервисов. Однако данный подход имеет существенный недостаток - он не учитывает вариант, когда django работает только в роли backend, что не позволяет быстро и эффективно создавать frontend отдельно. Эволюционно сообщество создало библиотеку, решающую данную проблему. Django Rest Framework или же сокращённо DRF, предоставляет инструменты для построения полноценного REST full API, что позволяет django работать в роли backend для любого внешнего frontend, а также позволяет быстро собирать валидаторы данных, которые не дают сохранить некорректные данные в БД.
Сокращённо PSQL - самая популярная в мире БД - отраслевой стандарт. И не просто так, ведь она сочетает в себе баланс между большим количеством функционала, скоростью работы и отказоустойчивостью. К тому же PSQL рекомендуется разработчиками django, так как наиболее полно поддерживает систему миграций. Немаловажным фактом является то, что PSQL - Open Source проект, над улучшением которого работают разработчики со всего мира.
Или же Simple Storage Service - сервис, придуманный AWS, для хранения большого количества файлов разного объёма. Если у вас возникает вопрос: где хранить файлы на моём проекте? Ответом будет: S3, S3 и ещё раз S3. На данный момент технология является отраслевым стандартом: все уважающие себя cloud провайдеры имеют S3 совместимое хранилище, и не просто так. - Простой интерфейс взаимодействия - Крайне высокая надёжность/доступность файлов - Крайне высокая отказоустойчивость к нагрузкам - Простота и гибкость
S3 может использоваться в совершенно разных кейсах:
Мы активно храним статические файлы frontend на S3. Это позволяет существенно снизить нагрузку на frontend сервер, снижая стоимость обслуживания сервера при масштабировании, при этом увеличивая отказоустойчивость системы.
S3 предоставляет функционал загрузки файлов на S3 напрямую пользователем в обход backend, соблюдая при этом все протоколы безопасности. Это позволяет существенно снизить нагрузку на backend сервер, снижая стоимость обслуживания сервера при масштабировании, при этом увеличивая отказоустойчивость системы.
Хранить файлы на S3 надёжно и безопасно, а главное дёшево, если сравнивать с кейсами, когда необходимо самостоятельно поднимать сервера для хранения файлов.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
12254 тендера
проведено за восемь лет работы нашего сайта.
S3 не витает в вакууме, а находится на серверах cloud провайдеров. Это многократно расширяет спектр возможности системы. S3 позволяет реагировать на события добавления, изменения, удаления файлов и вызывать lambda (serverless) функции в облаке для их обработки. Основная фишка этих serverless функций в том, что они сами вызываются, сами масштабируются под нагрузкой и, как ни странно, не требуют менеджмента серверов. Serverless функции позволяют быстро создать pipeline обработки media: обработка фотографий, анализ файлов, да хоть извлечения текста из фотографий или перекодировка видео. Это позволяет стоить высоконагруженные web системы любой сложности.
Или же Contend Dilivery Network, или же система доставки контента - это географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию содержимого конечным пользователям. Простыми словами - если ты находишься в Москве - файлик тебе вернёт Московский сервер, а если в Германии - Европейский. Очень часто используется в связке с S3: Файл кладётся на S3, а CDN распределяет его по своим серверам в автоматическом режиме.
Key-Value БД, данные в которой хранятся в оперативной памяти, благодаря чему обеспечивается их высокая скорость извлечения и добавления. В большинстве случаев используется в качестве кэша. Кэш - промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью.
Таким образом мы сильно снижаем нагрузку на сервер, увеличиваем скорость работы сайта, уменьшаем стоимость масштабирования.
Простыми словами: кэш можно разделить на статический и динамический
Допустим у нас есть категории товаров, и меняются они крайне редко. В таком случае полезно их положить в кэш: во первых, мы сильно снижаем нагрузку на БД, так как не делаем к ней очень много одинаковых запросов, ответы на которые будут одинаковые.
Допустим у нас есть блог из 1000 статей. 999 статей никому не нужно, а вот 1 статья завирусилась, на неё внезапно приходит много пользователей, и вот внезапно у нас случился higth load. Держать все статьи в кэше - не разумно - статей много - оперативная память дорогая - разумнее хранить в PSQL. Однако если в кэше держать самые ходовые статьи, то наш сервер с меньшей вероятностью превратиться в консервную банку под нагрузкой, так мы ещё и ресурсы сервера сэкономим.
Специализированная БД для хранения векторов и поиска по ним.\ А зачем нам эти вектора вообще нужны? По сути весь современный ML завязан на взаимодействии и обработки векторных данных: весь контент преобразуется в набор векторов -> загружается в модель -> получает набор векторов. И часть этих векторов нам, по хорошему, надо где-нибудь хранить. Конкретно мы используем вектора для построения систем неточного семантического поиска, кластеризации и тд. Это позволяет, тратя относительно небольшие ресурсы, как серверов, так и разработчиков, создавать системы поиска высокого качества.
Внутренняя библиотека tltpro для django. У Django большое сообщество, но либо не на все задачи есть типовые решения, либо типовое решение не подходит под наш формат работы. Эволюционно, в компании появилась небольшая, активно развивающаяся библиотека, закрывающая типовой функционал, необходимый в первую очередь нам, в том формате, который нас больше всего интересует.
Существенной разницы нет особо распинаться не буду
PHP - однопоточный синхронный ЯП, написанный специально под Backend. У него много недостатков: Во первых - однопоточность - она сильно ограничивает масштабирование и утилизацию ресурсов сервера. Грубо говоря за единицу времени сервер php может обработать только 1 запрос. Как следствие, для нормальной работы php нужно поднимать несколько docker контейнеров или вовсе распределять нагрузку между разными серверами, молясь, что нагрузка будет расти предсказуемо плавно или не будет расти вовсе. Асинхронность частично бы решила данную проблему, но её там нет) Отсутствие асинхронности не позволяет PHP адекватно работать с SSE и WebSocket - с технологиями, где нужно держать соединение открытым. То есть, чтобы сделать на сайте уведомления или чат - придётся танцевать с бубном. Сам по себе язык морально устарел, но главное - отстал от жизни - в нём много функционала, который следовало бы удалить, при этом есть кипа функционала, который следовало бы добавить. Поддержка сообщества большая, однако сам язык накладывает существенные ограничения: если на python ты можешь сделать условно всё что угодно (если закрыть глаза на задачи, где критически необходима скорость выполнения кода), то на php, например, ML модель вряд ли когда-нибудь будет запущена.
Тут всё просто, на С++/C#/Go, Rust и тд. всё будет работать очень быстро, но разрабатывать на них функционал вы будете очень долго. С Django ситуация обратная: частично жертвуем скоростью работы - в подарок получаем высокую скорость разработки.
Да, web сервер на django будет работать действительно медленнее, чем web сервер на c++ и ему подобных, однако: большая часть времени ожидания для пользователя - i/o операции, то есть операции ввода/вывода, то есть ожидание ответа базы данных. И если задача не специфическая, то время ожидания ответа на c++/django будет примерно одинаковое.