На наш взгляд, оптимальнее всего не забивать себе голову детскими фантазиями и высосанными из пальца проблемами.
У тебя нет сайта, нет пользователей, нет одновременной активности, нет проблем с производительностью.
Но зато уже есть ПРОБЛЕМА. Которую надо срочно решать.
С архитектурной точки зрения надо делать как обычно, и не пытаться решать несуществующие проблемы, изобретая какие-то хитрые решения с подвыподвертом. Потому что когда (если) проблемы с производительностью начнутся, то окажется, что это совсем не те, которые ты с таким трудом доблестно решал всё это время.
Не говоря уже о том что в реальности у тебя на сайте будет полтора инвалида, и единственной проблемой будет куда бы спихнуть это никому не нужное творение.
Зачем вам сторонние сервисы? Если на входе координаты, то можно использовать локально либу https://gdal.org/
Если точки уже в постгресе, то поставьте postgis и там все необходимые функции прямо в базе. Хоть на лету считайте, хоть агрегируйте.
Могу написать вам лично такой веб-сервис незадорого=)
DevOps скрипты хранятся в отдельном репозитории. Это pipelines, всякие питоновские скрипты конфиги и т.д Соответственно, код проектов по платформам ios, android, web и т.д. в отдельных репо.
А подумать?
Первая цифра может быть выбрана 8 способами (от 1 до 8), вторая 7 способами (от 1 до 8, исключая первую цифру, т.к. без повторений), третья - 6 способами, четвёртая - 5 способами. Всего у нас получается 8 * 7 * 6 * 5.
ФИО в три отдельные таблицы - имена и отчества часто повторяются. Фамилии просто для единого стиля.
Дату безусловно в отдельную таблицу. 35млн / (365*100). На 100 лет по 1000 человек в день рождалось. На самом деле распределение не равномерное и выигрыш по скорости/памяти будет больше.
Место рождения и место проживания скорее всего не две таблицы, а гораздо больше (есть смысл отдельно хранить города, улицы, дома).
Ну и таблица с ID индивида, содержащая индексы всех его ФИО и прочего. Эту таблицу можно проиндексирвоать по всем столбцам для быстрого поиска.
Простенькая реляционная база данных получается.
Ты имеешь ввиду пакет? Если да, то плохо искал Laravel-forum maintained by riari
Вообще ставил его себе, при знание фреймворка, можно хорошо допилить, да и под версию переделать не сложно
Воспользуйтесь прекрасным анализатором, он покажет с чем именно есть проблемы. Там же есть ссылки на дополнительную информацию, при помощи которой можно будет замечания устранить.
нужно засунуть большой шарик в квадратное отверстие, при этом что бы шарик не сломался
что было сделано
1) красил шарик другим цветом, не помогло, все равно не влазит
2) гуглил, в гугле пишут ни у кого не получилось
3) можно сточить шарик до меньшего размера, он влезет, но это не подходит
.......... можно продолжать дальше
Если ты готов сам отвечать за консистентность данных, вручную считать всю статистику, следить за исправлениями во всех местах, готов писать сотни велосипедов на простейшие задачи и делать другие не очень интересные вещи, то твой выбор noSQL
