Сергей Соловьев

Если перейти по ссылке на сайте, то можно увидеть, что для хранения используется LowDB.
Ответ: хранится все в JSON файле в денормализованном виде

Для решения этой задачи подходит векторизация.
Вкратце, слово представляется вектором из других слов (базовых) его описывающих. Тогда близость слов можно описать близостью векторов, его описывающих (косинусная близость). Это была теория.
Практика здесь:
- Обзор различных техник этого метода
- Ссылки на питоновские библиотеки
- Есть уже готовые фреймворки и предобученные модели

1. Написание e > 0 - почти всегда означает бесконечно малое число. Брать такие большие числа как 10 для данной леммы не имеет смысла.
2. В лемме ясно говорится о вещественных числах - ты в пример берешь целые. Т.е. дискретные вместо непрерывных

Суть этой леммы такова - если для каждой пары s и s' , разница между которыми бесконечно мала есть 2 числа, которые всегда окажутся между ними, то эти 2 числа равны.
Это полезно для чисел с плавающей точкой в программировании (double, float). Проверка равенства для них должна выполняться через эту лемму, но немного измененную: abs(a - b) < eps - означает что a и b равны

1. Создаешь свою базу данных городов (названия, расположения)
2. Находишь API, которое по положению отдает погоду в нем
3. Делаешь окно выбора города
4. Когда пользователь выбрал город делаешь запрос на API (шаг 2) и показываешь результат

На твое усмотрение:
- Как будет выглядеть морда (UI)
- Где хранится БД городов будет (загружаться во время старта, в txt/json файле, отдельная БД (sqlite, postgres))
- Какой API погоды использовать

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

create view points_difference as
    (
        select first.names as name1, second.names as name2, first.points - second.points as points from user_points first 
            join user_points second 
                on first.id <> second.id
        
    );

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

Это задача NLP - Natural Language Processing
Если вкратце, то работа ведется в несколько этапов:
1. Преобразование звука в текст
2. С помощью NLP этот текст обогащается:
- Форматируется
- Убирается мусор
- Выделяются ключевые слова
3. Готовый текст подается на вход другой нейронке, которая используя свою базу данных (история, контекст) понимает немерение

Собственно, сама работа ведется в последней части. Как эти нейронки работают - другой вопрос. Просто обучают на своих наборах данных

Пусть у каждого объекта будет свой штамп времени - когда он протухает.
В Update() проверяешь текущее время и время протухания - если превышено (и при этом предыдущее состояние не протухло), то меняешь вид/представление.
Этакая машина состояний

P.S. я не unity разраб., возможно во фреймворке уже есть готовые решения для такого

Допускает ли High Availability полный отказ системы или только отказ каких-то компонент с точки зрения функциональности, а не экземпляров?

Доступность исчисляется относительно внешнего клиента - может или нет получить доступ к сервису. Здесь без разницы, что для этого используется кластеризация, бэкапы, стендбаи и т.д.
Главное - это то, как систему видит пользователь. Собственно, все SLA на так и рассчитываются.

Какая правильная и полная формулировка Availability из CAP?

На сколько я помню, эту теорему в свое время критиковали и продолжают за неясность определения. Но если в кратце, доступность здесь означает, что ты получишь ответ, даже если связь с другими узлами кластера пропадет. Если в кратце, доступность = можешь получить ответ хоть когда-нибудь.
Пример:
1. Есть кластер из 2 Postgres мастеров. Связь между ними пропадает и запросы они принимать не могут. Это НЕ Availability, т.к. нам важна консистентность
2. Если кластер из 2 Postgres узлов - мастер и слейв. Даже если связь между ними пропадет, то запросы они принимать смогут, но данные могут быть в не согласованном состоянии (мастер принял несколько UPDATE/INSERT/DELETE, а слейв о них не знает). Это Availability, но Consistency мы потеряли
3. Если кластер из 2 Mongo узлов. Там используется свой протокол, который позволяет системе быть доступной, даже если связь между мастерами потеряется. Это Availability, но согласованность может потеряться
P.S. в последнем используются специальные распределенные структуры данных (чтобы каждый узел мог модифицировать свою версию, а потом смержить с другими узлами)

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

Отказоустойчивость - это не дискретная (0 или 1), а непрерывная характеристика. Здесь лучше думать в ключе SLA (99, 99.9, 99.999 т.д.), т.к. никакая система не может быть полностью отказоустойчивой. Но в целом да - отказоустойчивость значит, что функциональность должна работать и клиент может ее использовать.

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

1+ слово - тестирование (нагрузочное, объемное и т.д.)
Здесь нельзя вычислить формулами, сколько и что сможем обслужить. Только экспериментом числа получать.

UPD: если хочешь призму, чтобы смотреть на распределенные системы, то вот тут скачай "Распределенные системы" от Таненбаума - https://www.distributed-systems.net/index.php/book...

С# работает на виртуальной архитектуре

Правильнее говорить: имеет собственный байт код. Приложения .NET не запускаются в виртуальной машине! Они компилируются JIT'ом и просто могут взаимодействовать с платформой, но нет никакой ВМ (например, песочница как в JVM отсутствует - ты видишь обычный процесс.

Почему так?

Потому что C# (и .NET Framework в частности) был ориентирован для работы под Windows и там очень много специфичных для нее деталей есть (взять ту же концепцию COM объектов).
Java изначально поддерживала другую стратегию + была поддержка Linux (на котором сидели энтузиасты), что в итоге вылилось в то, что эти самые энтузиасты полюбили Java и начали писать на ней везде (а для этого надо было иметь реализацию JVM под нужную платформу)
Сейчас ситуация меняется: .NET есть под MacOS, Linux и Windows. Это не полная кроссплатформенность, но философия другая: мы будем поддерживать несколько платформ, но делать это качественно. Сейчас упор делается в Linux и веб в частности.
Дополнительно:
- Спецификация открытая и ничто не мешает реализовать под свои платформы. Взять тот же .net nanoFramework, mono, unity
- Mono вышел в 2004 году, а значит еще с тех пор .NET был кроссплатформенным