Daemon23RUS

В двоичном коде нет пробелов.
В одну переменную нельзя записать два числа.

Поэтому это не проблема двоичном системы, а проблема интерпретации входных данных.
Определяется постановкой задачи.

Также как с десятичной системой:

34 456
Это два числа или просто тысячи отделили пробелом для удобства чтения? Все определяется контекстом задачи...

Ну скорее всего никак. Кому надо тот всё равно запишет, так или иначе.
Например я могу запустить ОС в вриртуалке, открыть сайт, а видео записывать средствами управления виртуализацией.. например в Vbox такое есть)

Flash уже давно не поддерживается ни одним современным браузером.

Базы у вас нет ) Потому что это базовый вопрос даже не юнити и даже не c#, а основ программирования.

Вы правильно поняли что это связано с инкапсуляцией и сокрытием данных. Вот и развивайте эту тему для себя. Если ОЧЕНЬ кратко - это чтобы данные в одном классе не модифицировались (скрывались) от другого класса. Именно чистая безопасность когда разрабатывает больше одного человека - чтобы Вася не перетер данные в классе Пети., потому что потом Пете это разгребать.

Обычно если стоит выбор между TCP портом и unix socket'ом, то предпочтение стоит отдавать unix socket.

Выигрыш по производительности может быть небольшим, но обычно unix socket'ы более безопасны - доступом можно управлять по пользователям файловыми разрешениями и с unix socket'ом меньше вероятность получить эксплуатируемую уязвимость server side request forgery (SSRF) и обойти через нее, например, ограничения реализованные на nginx.

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

Как устроена команда git push?

вот так

Можете дать подобное описание для git push?

А что не так с описанием?

git push отправляет данные в удаленный репозиторий...

Тебе все ответили, тут два варианта - создавать в базе inmemory таблицу с одной колонкой и без индексов, и на ее основе уже делать

DELETE FROM A WHERE A.id NOT IN (SELECT id FROM B);

Либо написать скрипт, который выгрузит все id из базы, сравнит их (пока чисел не миллионы, это вообще не проблема) и сформирует список id которые нужно удалить (если всего 10к то их будет всего 3к), когда на десяток строк в любом языке программирования. Так как удаляются конкретные id то такой запрос будет работать быстрее чем delete where not in и возможно быстрее использования временной таблицы. Особых ограничений на количество id в where id in (...) я не нашел, если они есть то это проблема драйвера подключения к бд.

Есть еще третий вариант, который потребует изменения всего проекта, но заложит неплохие возможности. В базе данных нужно определить флаг - deleted (boolean), который устанавливать true если запись нужно удалить, это может быть дополнительное поле в каждой таблице где это имеет смысл, либо отдельная таблица (это эффективнее, если удаленные записи долго не нужно хранить) с единственным полем id, куда будут складываться идентификаторы записей на удаление. Естественно все запросы проекта нужно будет модифицировать с учетом этого поля/таблицы, чтобы пропускались записи, помеченные на удаление. Реальное же удаление проводить в момент наименьшей нагрузки на сервер или по другому критерию (например удаленные записи можно хранить для использования, к примеру отчетности). У метода есть подводные камни - например уникальные индексы/ограничения на другие поля нужно так же переделывать на сдвоенные с флагом удаленности, чтобы допускались записи с тем же значением что и удаленные.