Comments 27
Я, кстати, был одним из первых юзеров пони, т.к. они на реддит проскочили. Но не в Django, конечно, а просто в виде ORM.
Вопрос — пони уже поддерживает connection pooling?
Вопрос — пони уже поддерживает connection pooling?
Очень вкусно выглядит, надо будет на своих проектах посмотреть, если действительно так, то перейти. Спасибо за статью.
А не рассматривали такой вариант как MongoEngine с mongodb?
oRm, R = Relational.
Это понятно, автор статьи писал об озабоченности производительностью и соблазне все переписать. Насколько я знаю MongoEngine может работать с django и имеет интрефейс Django ORM. Понятное дело в данном случае нужно будет перевсети данные под монгу, но если текущая модель нормально ляжет на монгу, то это будет гораздо проще сделать, чем переписать приложение заново, и возможно получить выгоду за счет нового ORM/ODM.
Признаться, у меня есть серьезные сомнения в производительности монги, но тестов я еще не проводил.
Лучше сразу в /dev/null, не? :p
платная ORM, непривычно
GPL 3 же (вроде как) либо платите, если не опен сурс
Не совсем так, не opensource, а именно GPL3, это вирусная лицензия.
В прочем в случае веб-приложения вы и так отдаёте заказчику исходники, так что никаких проблем не вижу.
В прочем в случае веб-приложения вы и так отдаёте заказчику исходники, так что никаких проблем не вижу.
Отдаете заказчику это не GPL, вы должны опубликовать исходники.
Отдаете заказчику это не GPL
Извините, но не распарсил фразу, не могли бы перефразировать?
В прочем в случае веб-приложения вы и так отдаёте заказчику исходники, так что никаких проблем не вижу.
Как это позволит удовлетворить условиям GPL?
А чем это мешает GPL?
Ничем не мешает, но и не удовлетворяет.
Код нужно будет сделать открытым всем.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Код нужно будет сделать открытым всем.
Не всем, а только тем, кому распространяется программа. В данном случае — только заказчику.
Ну вы же понимаете, что потом заказчику надо будет открывать всем, кто пользуется web-приложением?
Нет, не надо будет.
Но если вам хочется, чтобы было так, то используйте AGPL (http://ru.wikipedia.org/wiki/GNU_Affero_General_Public_License).
Но если вам хочется, чтобы было так, то используйте AGPL (http://ru.wikipedia.org/wiki/GNU_Affero_General_Public_License).
ponyorm.com/license-and-pricing.html:
«Pony ORM can be used under one of the following licenses:
— Open source project: GNU Affero General Public License 3.0»
Я думал мы знаем, что обсуждаем.
«Pony ORM can be used under one of the following licenses:
— Open source project: GNU Affero General Public License 3.0»
Я думал мы знаем, что обсуждаем.
Платных опенсорс продуктов немало, и сама лицензия не ограничивает финансовую модель.
Да кстати, если вы хотите получить здесь комментарии разработчиков Pony ORM и у вас случайно завалялась пара инвайтов, вот их аккаунты на хабре: AlexeyMalashkevich,
metaprogrammer.
metaprogrammer.
Тестовая функция
Интересно какая версия Джанги тестировалась в этой и предыдущих статьях.
Насколько различаются SQL запросы генерируемые Django ORM и Djorny.
Как поменяются результаты если делать случайные выборки имен пользователей, а не одного пользователя как сейчас.
has_perm для test_pony намного проще оригинальной реализации в Джанго. Наверное, для чистоты эксперименты было бы лучше создать пару тестовых моделей.Интересно какая версия Джанги тестировалась в этой и предыдущих статьях.
Насколько различаются SQL запросы генерируемые Django ORM и Djorny.
Как поменяются результаты если делать случайные выборки имен пользователей, а не одного пользователя как сейчас.
Тестовая функция has_perm для test_pony намного проще оригинальной реализации в Джанго.
Не намного, но да, попроще. Однако предыдущие статьи по-моему вполне убедительно показывают приращение скорости при использовании Pony ORM, по сравнению с Django ORM на эквивалентных запросах, вплоть до идентичного сгенерированного SQL.
Интересно какая версия Джанги тестировалась в этой и предыдущих статьях.
В этой статье использовалась Django 1.5, в предыдущей по-моему 1.4, сейчас не помню.
Насколько различаются SQL запросы генерируемые Django ORM и Djorny.
В простейших случаях, запросы идентичны. Более сложные требуют абсолютно различного синтаксиса обращений в Django и Pony, поэтому сравнивать сгенерированные запросы не совсем корректно.
Как поменяются результаты если делать случайные выборки имен пользователей, а не одного пользователя как сейчас.
Разумеется, общее время несколько увеличится за счет бОльшей нагрузки на СУБД, поэтому относительное преимущество Pony будет снижено. Хочу однако отметить, что при этом потери Django ORM никуда не денутся и по-прежнему будут создавать неизменную в абсолютном выражении паразитную нагрузку на процессор.
На наших (у нас в конторе) задачах, при использовании ТОЛЬКО Django ORM для доступа к данным, нагрузка в целом распределяется как 5-10% на SQL и 85-90% на python. В случае замены на доступ напрямую к библиотеке СУБД, нагрузка распределяется примерно поровну. При использовании Pony ORM по предварительным результатам, нагрузка распределяется примерно как 25%/70%.
Приглашаю почитать также следующую статью почти на ту же тему — habrahabr.ru/post/201294/
> Не намного, но да, попроще.
— Это не ответ для бенчмарков. Вы должны обеспечить идентичность условий. В Джанго этот метод запускает поиск по коллекции бэкенднов авторизации, и многое зависит от конфигурации сайта.
В любом случае, — для сравнительного тестирования условия должны быть идентичными.
А самое интересное, — за счет чего достигается эта скорость.
Часто бывает, что люди лукавят, и делают кеширование, например, в словаре, потребляя понапрасну память. В таком случае показатели будут фантастическими. У Вас случайно не такой же случай? Беглый греп исходников намекает именно на это.
Если так, — то это очень плохо. Потому что это расходы памяти. А что если я хочу кешировать на ином уровне, кешировать сразу фрагмент HTML с кучей запросов? При этом возникает вопрос относительно инвалидации кеша. Например, у меня регулярно обновляется какой-то атрибут модели, который не должен инвалидировать кеш.
Кроме того, — это было бы просто не справедливо. У Джанги тоже есть приложения для кеширования запросов в БД, которые работают на уровне ОРМ. И если все дело в кеше, — то следовало бы обеспечить равные условия.
К тому же, этот примитивный кеш может оказаться бесполезным на реально больших объемах данных. Где он будет больше потреблять ресурсы, чем экономить их, из-за низкого коэффициента повторных запросов.
Возникает, следовательно, вопрос, относительно многопоточности и мультипроцессинга. Можно ли кеш сделать общим для всех потоков (memcache и пр.)? Как обстоит дело с инвалидацией? Как обстоит дело с параллельным доступом? Не перезапишется ли кеш старыми данными после инвалидации и до коммита?
Что делать если мне кеш на этом уровне вообще не нужен? Если у меня кеширование решено на ином уровне (скажем, кеш БД меня устраивает, или кешируются целые фрагменты HTML страниц)?
В общем, я обозначил далеко не полный список вопросов. Статья больше похожа на рекламу, нежели на стремление помочь разработчикам выбирать качественные инструменты.
Бегло глянул исходники этого пони. Скажем так, исходники SQLAlchemy учат хорошо кодировать. Навигация в коде простая. Все понятно, слои абстракции выбраны качественно. Может, я конечно, плохо разглядел это пони, но первые впечатления были не ахти.
— Это не ответ для бенчмарков. Вы должны обеспечить идентичность условий. В Джанго этот метод запускает поиск по коллекции бэкенднов авторизации, и многое зависит от конфигурации сайта.
В любом случае, — для сравнительного тестирования условия должны быть идентичными.
А самое интересное, — за счет чего достигается эта скорость.
Часто бывает, что люди лукавят, и делают кеширование, например, в словаре, потребляя понапрасну память. В таком случае показатели будут фантастическими. У Вас случайно не такой же случай? Беглый греп исходников намекает именно на это.
Если так, — то это очень плохо. Потому что это расходы памяти. А что если я хочу кешировать на ином уровне, кешировать сразу фрагмент HTML с кучей запросов? При этом возникает вопрос относительно инвалидации кеша. Например, у меня регулярно обновляется какой-то атрибут модели, который не должен инвалидировать кеш.
Кроме того, — это было бы просто не справедливо. У Джанги тоже есть приложения для кеширования запросов в БД, которые работают на уровне ОРМ. И если все дело в кеше, — то следовало бы обеспечить равные условия.
К тому же, этот примитивный кеш может оказаться бесполезным на реально больших объемах данных. Где он будет больше потреблять ресурсы, чем экономить их, из-за низкого коэффициента повторных запросов.
Возникает, следовательно, вопрос, относительно многопоточности и мультипроцессинга. Можно ли кеш сделать общим для всех потоков (memcache и пр.)? Как обстоит дело с инвалидацией? Как обстоит дело с параллельным доступом? Не перезапишется ли кеш старыми данными после инвалидации и до коммита?
Что делать если мне кеш на этом уровне вообще не нужен? Если у меня кеширование решено на ином уровне (скажем, кеш БД меня устраивает, или кешируются целые фрагменты HTML страниц)?
В общем, я обозначил далеко не полный список вопросов. Статья больше похожа на рекламу, нежели на стремление помочь разработчикам выбирать качественные инструменты.
Бегло глянул исходники этого пони. Скажем так, исходники SQLAlchemy учат хорошо кодировать. Навигация в коде простая. Все понятно, слои абстракции выбраны качественно. Может, я конечно, плохо разглядел это пони, но первые впечатления были не ахти.
> Как поменяются результаты если делать случайные выборки имен пользователей, а не одного пользователя как сейчас.
— Совершенно справедливый вопрос, исключающий влияние возможного внутреннего кеширования.
— Совершенно справедливый вопрос, исключающий влияние возможного внутреннего кеширования.
Sign up to leave a comment.
Внедрение высокопроизводительного Pony ORM в проект Django