sim3x

В трейдинге обожают джаву
В гугле сотни тысяч линков по запросу programming rust slowdown

В tiobe в 20-ке его нет

Даже если обгонит всех, то разумность его изучения для работы под вопросом

Ваш вопрос вцелом не имеет смысла
Хайлоад появляется только на успешных проектах

Если вас просто мандраж перед термином
Возьмите свой проект, любой
Поставьте себе локально на виртуалку
И поставьте себе задачу завалить его
Потом отбейте свой ДДОС без потери легитимных пользователей

каким образом организовать начальный этап этой разработки?Каков стек необходимого ПО и/или иных инструментов для этого?

полностью зависит от ТЗ

Под стеком не имею в виду на каком языке делать бэк, какую использовать БД и что использовать для кэширования, а интересует больше то, каким должно быть окружение процесса разработки - нужно ли с самого начала поддерживать "версионность" и если да, то как это делать?

гит нужно использовать всегда
Версионность данных желательно
Как их хранить? - Делайте консистентные бекапы

Где вообще изначально разворачивать систему - на локалке или нет?

у вас джанга. При разработке используйте встроенный сервер, при деплое -nginx/uWSGI/postgreqsl

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

ansible

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

нет. Вначале просто докупают больше мощности, потом выселяют субд на отдельный сервер, и только после такого думают как разделять бекенд.
Или у вас в задаче прямо сказано, что у вас будет строго больше 10k RPS

Пока нет $2к на постоянного админа и ценник за хероку меньше 2к - стоит
После, зп админа + 500-2к на железо будет приносить больше производительности чем любой паас

RPS - 1k+

Смотри EXPLAIN
Используй временные таблицы
Присмотрись к начальству, а точнее к их адекватности
Запрос вставь в текстовик и сделай замену полей на поле_1, поле_х, аналогично с названиями таблиц

1. django + rest + angular2/react
ClojureScript + React

2. PostgreSQL. С оракла даже яндекс сваливает (свалил?)
3. Нинасколько. Если нужен будет код, который не выкинется целиком после прихода нормального СТО, то спецы на любом ЯП будут стоить одинаково дорого

nginx умеет проксировать tcp
в платной версии имеет баллансировку и перезапрос на другой бек

postgres

Пока не поймеш какая структура у проекта, можешь хранить данные в json

Когда все устаканится - нормализуешь

4kk / (60*60*24) = 46 rps
hiload
lol

nginx ( + lua scripts) or nginx plus
настроить апстрим на 1-2 сервера
на серверах пхп-фпм

Если нагрузка только на чтение - справится 1 сервер с хорошим каналом
Апдейт-инсерт потребуют настройки СУБД

Или нанять человека, который понимает, что нужно делать

https://en.wikipedia.org/wiki/Entity%E2%80%93attri...

БД проектируется для проекта, а не для фреймворка

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

Заказать разработку у специалиста

Чувствуется недосказанность в вопросе

Ведь 200к за раз запихнть в очередь СУБД и потом вставить в БД - легко
Принять по гигабиту 200мб и записать в текстовик на RAID10 - не проблема

какие подводные камни

кроме того что

junior-angular

никаких

-дополнительный уровень защиты данных (нет вероятности, что при ошибке в программной части пользователь увидит "чужие" данные)

нет

-проще масштабироваться шардингом - разносить далее БД разных аккаунтов по серверам

большей части юзеров никогда не понадобится такое

-упрощается программная часть - не надо в каждый запрос дописывать id_проекта

все зависит от архитектуры - в общем случае такой проблемы нет

-проще управление индексами - при размещении индексов на диске будет сразу такой же эффект как при создании partitions индексов на каждый аккаунт

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

Хочется и нужно - две большие разницы

А хотелось бы, если не реалтаймовой обработки, то задержки не больше часа и отсуствие линейной сложности от кол-ва постгрессов.

такое наврятли получится без всяких хадупов

Вот забавное решение
stackoverflow.com/a/3200176/1346222

truncate table tableA;

insert into tableA
select *
from dblink('dbname=postgres hostaddr=xxx.xxx.xxx.xxx dbname=mydb user=postgres',
            'select a,b from tableA')
       as t1(a text,b text);

можно еще с WAL файлами поиграться и репликациями

Ну и неплохо иметь схему сервиса в общих чертах