Внешние ключи Django могут оставить лишние индексы и заблокировать миграцию
В модели всё выглядит аккуратно: несколько
Статья How to Get Foreign Keys Horribly Wrong разбирает, где появляются дублирующие индексы и как обнаружить блокирующую миграцию. Затем переходит к безопасному переносу внешнего ключа, обратимым операциям и конкурентному созданию индексов.
Перед следующим изменением схемы по ссылке стоит проверить ещё две вещи: когда нужен частичный индекс и в каком порядке выполнять миграционные операции.
В модели всё выглядит аккуратно: несколько
ForeignKey, on_delete=PROTECT и unique_together. Но внешний ключ связывает две таблицы, поэтому обеспечить такое ограничение сложнее, чем уникальность или проверку значения. Явное лучше неявного, а неявного поведения здесь хватает.Статья How to Get Foreign Keys Horribly Wrong разбирает, где появляются дублирующие индексы и как обнаружить блокирующую миграцию. Затем переходит к безопасному переносу внешнего ключа, обратимым операциям и конкурентному созданию индексов.
Перед следующим изменением схемы по ссылке стоит проверить ещё две вещи: когда нужен частичный индекс и в каком порядке выполнять миграционные операции.
Hakibenita
How to Get Foreign Keys Horribly Wrong
Common Pitfalls and Potential Optimizations in Django
❤1
Как найти хеш пароля в 37 ГБ меньше чем за миллисекунду
Офлайн-проверка пароля по списку утечек выглядит как обычный поиск, пока Pwned Passwords не распаковывается в текстовый файл на 37 ГБ. Минимальный вариант на Python работает, но оказывается слишком медленным.
Автор профилирует код, пробует пропускать части файла, применяет двоичный поиск, строит отдельный индекс и переводит его в двоичный формат. Вполне по дзену: сначала измерить, потом усложнять. Результат: поиск занимает меньше миллисекунды.
В разборе оптимизации можно проследить, почему первые ускорения не уложились в цель, как генерируется и читается индекс и какие структуры данных автор рассматривает в финале.
Офлайн-проверка пароля по списку утечек выглядит как обычный поиск, пока Pwned Passwords не распаковывается в текстовый файл на 37 ГБ. Минимальный вариант на Python работает, но оказывается слишком медленным.
Автор профилирует код, пробует пропускать части файла, применяет двоичный поиск, строит отдельный индекс и переводит его в двоичный формат. Вполне по дзену: сначала измерить, потом усложнять. Результат: поиск занимает меньше миллисекунды.
В разборе оптимизации можно проследить, почему первые ускорения не уложились в цель, как генерируется и читается индекс и какие структуры данных автор рассматривает в финале.
death and gravity
Has your password been pwned? Or, how I almost failed to search a 37 GB text file in under 1 millisecond (in Python)
... in which we check if your password has been compromised in many inconvenient ways, in a tale of destruction, obsession, and self-discovery.