Дмитрий

Нормализацию данных не предлагать?

Именнованный location в помощь

location / {
  root /var/www/html;
  try_files @upstream $uri =404;
}
location @upstream {
  proxy_pass http://127.0.0.1:3000;
  proxy_intercept_errors on;
  recursive_error_pages on;
  error_page 404 = @local;
}
location @local {
  try_files $uri =404
}

Блин ну люди что с вами? Почему нельзя все заскриптовать. Даже без скриптов банальным копипастом что хост что бд создается за несколько секунд. По моему опыту панели даже мешают банальный шелл удобней в разы.

WITH cte AS (
    SELECT SUM(CASE WHEN balance < 0 THEN 0 ELSE 1 END) OVER (ORDER BY date) grp
    FROM test
    )
SELECT COUNT(*) - 1 max_cnt
FROM cte
GROUP BY grp
ORDER BY 1 DESC LIMIT 1;

fiddle (исходные украдены у Дмитрий).

Все файлы небезопасны. Можно загрузить картинку, в которой будет исполеяемый код.
Вы должны настроить сервер (nginx/apache) так, чтобы в папке где будут загруженны клиентами файлы, в принципе нельзя было исполнять НИКАКИЕ файлы.

Можно я внесу немного конструктивной критики в ваш вопрос, ну и сделаю некоторые выводы, возможно вам они будут полезны...

Я занимаюсь разработкой интернет проектов. Сейчас вместе с командой специалистов мы готовимся к разработке большого и высоконагруженного проекта.

Вы же не рекламное письмо фирме пишете, говорите четко - "у нас есть 6 маркетологов, джун верстальщик и эйчар". Ну или " У нас было два пакетика травы, семьдесят пять ампул мескалина, 2 явиста мидла, 2 пхп сеньера, бухгалтерия, наполовину наполненная старушками с калькуляторами, и целое море различных специалистов по яваскрипту, цсс, хтмл и их комбинациям в ассортименте, а так же...".
Тогда понятно - что вам искать, какие спецы какого уровня у вас уже есть и стоит ли их менять или строить будущую архитектуру под уже имеющийся состав.

Общая концепция выглядит приблизительно так:
Будет много разных баз данных, в которых будет храниться информация разного типа, текстовая, . Каждая база будет содержать информацию по разным темам.

Информация графическая, видео и аудио типов чаще всего не хранится в бд. Если вы не программист/архитектор IT структур - поручите вопросы архитектуры и структурирования данных кому-либо из команды, кто в этом разбирается (если таковые есть).

Отдельно будет полнотекстовая поисковая система объединяющая информацию из всех источников.

В принципе не особо зависит от стека, тут больше архитектурно-проектировочная задача.

Так же будет много различных микросервисов расширяющих сервисный функционал, например сквозная авторизация, сервис закладок, хранения паролей и т.д.

Тоже самое - больше архитектура, нежели стек.

Посоветуйте пожалуйста какой стек технологий для разработки выбрать, с учётом некоторых условий:
- Язык(и) программирования современные и содержащие подробную информационно-документальную базу и популярные сообщества поддержки.

На сегодняшний день есть 4-5 хорошо распространенных языка, используемых в вебе: пхп, ява, жс, питон, в меньшей степени c#, руби, голанг, остальные больше экзотика, нежели мэйнстрим.

- Высокая производительность и многопоточность.

Которая в вебе не особо нужна, хотя практически все вышеперечисленные языки в той или иной мере многопоточность поддерживают. Опять же - сразу "видны уши" вашей недостаточной компетентности в вопросах разработки высоконагруженных проектов. Дело в том что в 99% случаев код именно языка программирования особо не нагружен. Больше всего процессорного времени будет съедаться запросами к бд и внешним сервисам. Код просто прослойка между фронтом и бд, чаще всего просто выполняющая задачи CRUD прослойки.

- Простая масштабируемость.
- Актуальность на ближайшие 2-3 года.

Везде подходит

- Интеграция с проектами написанными на других языках.

Ни один язык не интегрируется с другим. Есть вопросы обмена данными между различными приложениями, но они абсолютно одинаковы на любом языке, не в плане кода, а в плане методов реализации. По этому это тупой и бесполезный пункт.

Постарайтесь пожалуйста привести аргументы в пользу того или иного выбора, а так же возможные минусы.

выбор надо делать не в пользу языка, а в пользу специалистов (ну и от них плясать уже по стеку). Как пример - проще всего поднять на пхп/ноде, специалистов много, они дешевле например явистов или шарпистов, поддержка проекта не сдохнет при уходе какого-нибудь ведущего спеца. С другой стороны, если речь идет о корпоративном заказе - скорее всего вам придется писать на яве/цшарп, емнип только у них есть соответствующие сертификаты по работе с шифрованием и прочей секюрити. Так же сильно зависит от того кто вообще есть в вашем регионе, кого можно быстро/возможно вообще найти на замену уходящим сотрудникам, и еще 1000 и один вопрос, который отпадает при выборе специалиста, а не стека (после этого голова болит уже у него, а не у вас, но в своей области, что гораздо лучше).

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

1) В твоем случае вообще нужно юзать ресурсные роуты, которые работают с биндингом, а это еще минус строки кода. Далее тебе нужно проверить права доступа, а значит политики авторизации, с ресурсными контроллерами, это еще минус код тк они конектятся одной строкой кода ко всем методам и модель через биндинг передается автоматом в политику. А в этом и есть смысл фрейморка - не писать код самому и не пилить кривые велосипеды.
2) Модель тебе может понадобиться в мидлварях, форм реквестах, политиках, с биндингом тебе не нужно делать на каждом этапе свои одинаковые запросы.
3) Что такого в load неудобного не понял? Тот же самый with.
4) если ты проверяешь права доступа к модели, то тебе обычно не нужны ее отношения и поэтому нет смысла их грузить до проверки в политиках - это будут лишние запросы если авторизация не прошла. Для этого биндинг дает именно то, что тебе надо - чистую модель.
5) Where в модели не нужен. То, что ты проверяешь статус в модели - это проверка доступа, которую нужно делать в политике.
6) Удобно, красиво, быстро и необходимо для полноценного использования Ларавел, а не только роуты, контроллеры и вьюхи как в 99% проектов.

Немного бухгалтерии. Если взять по максимуму.

Размер одной записи должен быть порядка 60 + 32 +8 = 100 символов (байт для простоты)

При 50 млрд записей объем хранимых данных должен быть порядка

50 000 000 000 * 100 = 5 000 000 000 000 = 5 триллионов байт.

В дисковом хранении это будет примерно 4.5 терабайта. Задачка для in-memory неподъемная. Нужен диск + мемори.

Если я там где-то ошибся в расчетах - то только в средних значениях. Если подставить не максимумы а среднее - то цифры будут поскромнее. Но в любом случае - многовастенько для покупки памяти.

Вобщем нужна дисковая БД которая встраивается в приложение. На требование менеджеров которые запретили использовать БД забейте. Они ничего не понимают. Делайте БД встраиваемую в приложение. В качестве таких (встраиваемых систем можно поробовать) LevelDb, BerkeleyDb, RocksDb. Они поддерживают индекс класса B+Tree и это даст возможность искать группы записей по одному ID. Для этого класса систем любую запись можно найти за 4-5 дисковых IOPS. Если какдый IOPS стоит 15 мс (это я так мерял свой собственный магнитный HDD) то любой поиск группы ключей для TTFB будет порядка 15 * 5 = 75 милисекунд. Ну если вы поставите SSD - то быстрее.

По поводу предложений хранить в файлах. До того как обсуждать это - надо уяснить требования по времени отклика. Сколько секунд вы согласны ждать - насколько можно и партицировать (или шардировать ваш файл).
В простейшем случае мы делим большой CSV файл на 512 partitions по хешу от ID и получаем соотв время фулл-скана всего файла поделенное на 512. Дальше - играйтесь с этим параметром партишенинга выводя его на доступный уровень отклика. Из недостатков - будет россыпь файлов. Надо почиать документацию на вашу файловую систему (ext4?) и тюнить ее так чтоб она не сдохла от такого числа inodes.

Я поддержу оба сценария. И с встраиваемой БД и с файлами. Но с БД надежнее т.к. есть транзакции а файлы у вас могут быть в крешнутом состоянии долго. И вы об этом ничего знать не будете.

По поводу Parquet. Не взлетит. Скорее всего индекс по данному типу файла - это совсем не то что вкладывают туда релационные системы. Обычно Parquet/Orc/Delta вкладывают в индекс смысл - отбрасывания тех полосок данных (stripes) которые бесполезны при чтении всего файла. Такой индес - обычно просто либо range-признак либо карта Блума. И в случае с range - дает эффект на сортированных данных. Для прочих - будет бесполезно т.к. фулл-скан все равно обеспечен. А если фулл-скан то зачем тогда вообще индекс.

Вобщем для дизайна архитектуры нам нужны цифры. Средние длины по колонкам. И я-бы еще запросил кардинальность по полю ID.

Нужно помнить о том что между вычитыванием 1-й и 2-й страницы таблица могла быть изменена. И процесс может либо пропустить какую-то строку либо прочитать дубликат. У этой проблемы есть много решений. Почти все они лежат в плоскости транзакций. Но поскольку тема тегирована только SQL - то непонятно с какой dbms мы имеем дело. Реализация режимов транзакций - вещь крайне нестандартизированная.

Тоесть чтобы обсуждать правильный pagination нам нужно понять что по ту сторону application. Oracle? MSSQL? e.t.c.