NaName

Не импортировать классы моделей, а в ForeignKey или ManyToManyField передавать строку с именем класса, вместо самого класса:

class A(models.Model):
    b = models.ForeignKey('B')

Давай я погугулю за тебя.

хранить не в контейнере

https://docs.docker.com/storage/volumes/

вариантов много:
- запускать в screen;
- запускать в tmux;
- запускать через nohup и смотреть вывод в создаваемом им файле;
- запускать через systemd;
- ...

https://docs.djangoproject.com/en/2.1/howto/deployment/

Добрый день! Хотел посоветоваться с опытными бэкэнд программистами.
Встала задача создать высоконагруженный проект (Типо кассового решения). В базе данных через 1-2 года планируется , около 150млн записей у основной сущности (продажа).

150 миллионов записей - это ерунда, а не высоконагруженное решение.
У меня 5 000 записей в секунду создается на довольно дохлом (что-то около 500 рублей в месяц стоит хостинг) сервере VDS/VPS
Два года? 150 миллионов - это за ... 9 часов.
И да, я не считаю это решение высоконагруженным.
Нагруженным - да.

то есть нужно максимально быстрое чтение этих данных

Нет.
Людям не нужно снимать отчеты со всех данных сразу. Только часть данных интересует их.

Если всё же нужны все данные сразу (ну какая-то общая статистика) - то на основании первичных данных выполняется агрегация (например, по ночам) и тогда отчеты будут строится вообще - мгновенно.

Но большим плюсом является что эти 150млн записей - разделены примерно на 1000-5000 разных пользователей, и выборка нужна в рамках одного пользователя только.

Вот только если ваши 1000-5000 пользователей будут постоянно получать данные - только тогда это и можно назвать нагруженным решением.

Как лучше хранить такие данные? в одной таблице? или можно разделить по разным таблицам, и держать связку какой пользователь в какой базе хранит.

Это зависит от того что за данные.
Что именно за данные.

Сам пишу на mysql - потянет ли он такие объемы, на нормальном железе. Или нужно смотреть в сторону других БД?

MySQL довольно быстр.
Например, PostgreSQL более функционален. Но насчет скорости - не обязательно.

потянет ли он такие объемы, на нормальном железе

А в официальную документацию заглянуть?
https://dev.mysql.com/doc/refman/8.0/en/limits.html
150 млн. записей для современных СУБД и современных компьютеров (даже не на "нормальном железе") - это тьфу, а не нагрузка.

P.S.:
Для высоконагруженных систем формирования отчетов есть различные решения:

1. Предварительная (ночная) агрегация данных
   
2. Master-slave, где master только обновляет данные, а slave - только для отчетов.
   
3. Специализированные, заточенные под конкретный вид данных СУБД (InfluxDB, Redis-Tarantool-Aerospike, ClickHouse пр.)
   

1. Делаете отдельное поле normalized_phone, в которое пишите "нормализованное" по вашим правилам значение
   
2. При поиске по тем же правилам "нормализуете" пользовательский ввод и ищете по полю normalized_phone.