участников
вопрос: как думаете с точки зрения перфа лучше будет сначала проверить(на уровне прилаги) есть ли такие записи уже или создать ограничение которое будет недопускать дубликаты? скорость первостепенна
"сначала проверить(на уровне прилаги) есть ли такие записи уже" - а как будет гарантироваться атомарность? Я думаю, что лучше на уровне БД уникальный ключ повесить
How do yo do? В смысле -- как вы планируете сделать, чтобы скорость СОЗДАНИЯ участников была критичной? Просто интересуюсь, есличо.
не подумал про атомарность даже, спасибо!
Разумеется, надо вешать стандартный unique constraint. Остальное -- как там проверять, как отрабатывать upsert или просто ошыбку -- это ужэ следующий вопрос, варианты разные есть.
в плане требований, нужно чтобы запрос с клиента выполнялся как можно быстрее
Это очень странное требование, на самом деле. Потому что "как можно быстрее" - это вилами по воде, и зависит от кучи факторов
Понимаете, Артём, на ноутбуке с магнитным жёстким диском 5400rpm запросы на создание нового в типичном случае будет давать вам несколько тысяч новых пользователей в секунду. Ну, при достаточно количестве воркеров (десяток-другой). Куда вам столько?
вариант 1: 1 секунду эндпоинт выполняется вариант 2: 2 секунды эндпоинт выполняется учитывая что все N вариантов дают одинаковый результат, нужно заюзать самый быстрый вариант
Если таблица пользователей влезает в память -- то время выполнения операцыи будет примерно один hdd roundtrip, если не влезает -- ближэ к двум. Тип диска не очень важэн, просто у магнитного hdd этот roundtrip -- где-то 7мс, у ssd -- где-то 0.3-1.5мс. И да, если эта операцыя выполняется секунду в типичном случае -- значит у вас там что-то сломано.
1 2 секунды это рандомные цифры:)
То есть вы не знаете требований к скорости, реальных скоростей и не умеете их оцэнивать. Но занимаетесь оптимизацыей. Не надо так. Я не думаю, что преждевременная оптимизацыя -- это источник бОльшэй части зла в программировании. Но что это порочная практика -- я абсолютно согласен.
Чтобы эндпоинт выполнялся 1 секунду - это очень "постараться" надо. Даже на слабом VPS эндпоинт будет отвечать в десятки раз быстрее. Понятное дело, что это ещё от нагрузки зависит, от количества индексов на таблице и т.п. Но при любом раскладе вариант с дополнительным запросом из приложения на проверку дубля, во-первых, не даст атомарности, во-вторых, сам по себе будет лишним шагом.
Обсуждают сегодня