Дмитрий, я посмотрел видео. Слайды были поняты правильно, инстаграм переписывал ORM не потому, что он показывал плохую производительность, а потому что им нужен был шардинг. Даже если бы они слали напрямую sql-запросы через psycopg2, на тех же объёмах данных и тех же нагрузках их СУБД загнулась бы без шардинга. К тому же в 2014-м они перешли на TAO, который вообще графовая СУБД, а потому реляционный Django ORM вообще не смог бы с ней работать. Очень интересная часть на 51-й минуте, когда докладчик говорит, что стоковый Django способен показывать очень высокую производительность и потребность в оптимизациях не появится раньше, чем проект достигнет масштабов инстаграма. Что вполне ответ на вопрос Вадим
Дмитрий, вот за это я так люблю видео, надо потратить час жизни, чтобы продолжить беседу, идеальный формат передачи знаний. На сколько я понял из слайдов, что-то с ORM они сделали достигнув 500 миллионов пользователей, и потребность у них в этом появилась не потому, что ORM медленный, а потому что СУБД задыхалась под нагрузкой и нужен был шардинг. Не? Ну, и замечу, что они ORM переписывали, а не на psycopg2 переходили.
Андрей Романов, вероятно, надо разбить итерируемую коллекцию на десять равных частей и отправить каждую часть на выполнение в пул потоков нужного размера. Хотя, я бы лучше использовал асинхронность вместо потоков.
Дмитрий, откуда информация? Ещё пару лет назад их инженер писал, что единственный тюнинг, который они делали - запускали интерпретатор с отключенным сборщиком мусора. В их инженерном блоге я информации о переписывании ORM не нашёл.
Лицензия, которая была раньше, не запрещала создавать конкурентов Facebook, как написал автор вопроса. Она позволяла Facebook запретить использовать React тем, кто подал на Facebook в суд.
Jake Taylor, ага, как-то так REST и устроен - есть некоторое пространство имён, в котором можно ссылаться на отдельные сущности по уникальному идентификатору. Если нужно обеспечить безопасность, чтобы пользователи могли смотреть только свои заказы, то контроллер должен взять пользовательских токен из авторизационного заголовка, получить с его помощью id пользователя запрашивающего заказ, сверить с id владельца заказа и выдать 403-ю ошибку в случае несовпадения.
Вадим, во-первых, вся суть Django в том, чтобы обеспечить разработчику возможность писать прикладной код на более высоком уровне абстракции. Причём практически все механизмы фреймворка построены вокруг ORM. Уход на более низкий уровень превратится в борьбу с фреймворком. Легче тогда взять Flask или Aiohttp. Во-вторых, "не быстрая" - это смотря с чем сравнивать. Если руки прямые, то обеспечить 300 rps одним инстансом вполне реально. А при наличии Celery, memcached и кубика с десятками подов, можно обеспечить обработку десятков тысяч запросов в секунду, как это делает тот же Instagram.
Евгений Лернер, единственные заказчики, который может волновать какая-либо сертификация - это госструктуры, ищущие исполнителей через тендеры. В этом случае выбор свистоперделок зависит от того, что именно компания разрабатывает и на чём.
