d'Ivan

Ну, книги Вам уже посоветовал @firedragon
Я же хочу вкратце ответить на этот замечательный вопрос.
Давайте разберемся с одним CPU без потоков...
Когда процессоры были большими, а люди... В общем, на заре компухтеров был только один поток, и чтобы получить многозадачность, придумали ОС с вытеснением задач.
Смысл в том, что когда завершается "программа", то запускается следующая в очереди (очередь с приоритетом). Задача работает до тех пор, пока не завершится.

Так как задача иногда могла работать очень долго, и ничего не делать во время операций ввода-вывода то придумали прерывания, чтобы ввод-вывод сигнализировал о проделанной операции (окончании печати например, или нажатии клавиш). Тогда появились операционные системы с вытеснением задач по прерыванию. Здравствуйте мейнфреймы!

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

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

Ах, да, молодость процессоров - одно прерывание на все сразу :) И крутись, как хочешь :)

Хм тут вам помогут книги
Эндрю Таненбаум
Торвальдса
Русиновича
Helen Custer , David N Cutler
David A. Solomon
https://slideplayer.com/slide/6865915/

Гляньте вот на эту презентацию https://www.hse.ru/data/2010/12/24/1223886397/%D0%...

А вот тут прикладная часть
https://basis.gnulinux.pro/ru/latest/basis/15/15._...

В общем тема большая и гуглить вам много, но основных авторов я дал

Это называется стемминг (выделение корня) или лемматизация (группировка родственных слов).
Гугл говорит, что для этих целей часто используется сеть NLTK.

term - поиск по одному терму, terms - поиск по множеству термов,

{
  "query": {
    "terms": {
      "user.id": [ "kimchy", "elkbee" ],
      "boost": 1.0
    }
  }
}

https://www.elastic.co/guide/en/elasticsearch/refe...

Тут подходит любая реляционная SQL БД потому что нет противопоказаний. Реляционку мы выбираем
уже более 30 лет как default вариант и почти не ошибаемся.

Когда задача имеет признаки ярко выраженной high-load системы - мы делаем ей частичную денормализацию
и раскладываем ее в NoSQL Key-Value решение. Но это не про улучшение а это про неизбежность. У нас нет выхода просто.
Иначе мы клиенту не сможем быстро отдать какой-то резуальтат.

Когда задача имеет ярко выраженную документную природу (нет спецификации на values) - мы берем MongoDb/CouchDb.

Когда задача хранит граф и ищет в графе и вообще требует графовых алгоритмов - то мы берем Neo4j или ей подобные.

Когда задача хранит данные измерений (телеметрия) - то предпочтительно взять InfluxDb или ей подобные. Здесь-же мы предполагаем что у нас - не будет joins а будет только измерения в диапазоне времени.

Но в данном ТЗ и на картинке обычная SQL БД (MySQL/Postgres) вполне себе нормально справляется.

Планировщик задач, который по времени переключает режимы энергосбережения.
https://learn.microsoft.com/en-us/windows-hardware...

Никакую базу, имхо, не нужно использовать с "FTP через FUSE".

Ох и амбиции. И что за перфекционизм в отношении Postgresql?

Не знаю как автор посчитал миллиард. Это если все население планеты Земля составляет порядка 8 млрд.
И что мы возьмем целую страну и инвентаризируем ее чтоб получить такое число?

Для графовых БД существует не Postgresql а специальные БД типа Neo4j. Но еще до того как ты доберешся
до графовых БД - задание может многократно измениться и выйдет что граф - рудимент. Так часто бывало.
Вообще очень малое число задач требуют именно графов. Если табличка отражает семантику модели
то можно и ее использовать. Только с условием не решать в ней задачи о рукопожатиях.

По поводу того что в таблице что-то там кого-то убивает на 1 млрд. Я отвечу так что если вы строите OLTP
систему то в ней этот миллиард никогда не будет использоваться целиком. Там будут горячие области.
Их можно каким-то образом кешировать или алгоритмически пред-выбирать. Или брать key-value системы если ТЗ позволяет. Для них что миллиард что триллион все безразлично. Не забывайте только поднимать новые ноды и подкидывать диски в облачко. Или если речь идет
о BigData к примеру то там есть свой техно-стек. Например Apache Spark / GraphX. Хотя я с модулем GraphX
не работал ни разу. Но биг-дата запросы обычно никогда не запрашивают одного физ-лица или одну
единицу тех-средства. Биг дате ставят задачу собрать всё про всех и отгрузить отчет в виде другой таблички
или DataMart. И на это ей дадут пару часиков а то и день. Поэтому разговоры относительно убивания
производительности - очень можно смягчить.

Вообще такие сложные системы не обязаны строиться поверх Postgres или Neo или Spark. В их разработке
вполне можно использовать целый pipeline из технологий где например Postgres будет просто одним
из элементов. Или одним stage.