Армянское Радио

Шифруются все чаты, но P2P - только приватные.

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

Сделайте пайп, состоящий из архивации в tar и передачи по ssh, после завершения передачи одним усилием распакуете с другой стороны tar. Правда не уверен, что это будет быстрее rsync, который уже предложили выше, нужно мерять.

rsync --progress -avz -e ssh /что/ user@server:/куда/

т.к. я сижу сейчас на окладе, а если пересяду домой, то логично возникает почасовая оплата

Почему логично? Кто мешает оставаться на окладе, если это устраивает обе стороны?

Вообще существует куча таск-трекеров, начиная от простеньких, и заканчивая очень навороченными. Если доверия нет, и работодателю важны не результаты, а затраченные "жопочасы", то есть разнообразные "следилки".

Скорее всего энергосберегающий режим убивает фоновые процессы (не xiaomi случайно?). Должно всё работать, по крайней мере у меня вот Zаdarma SIP и Linphone отлично работают в фоне.

93 млн. - сама по себе смешная нагрузка для современных СУБД на современных компьютерах.
Выбор СУБД зависит от того - а что именно вы собираетесь с этой базой данных делать.- в вопросе это не указано.

Ну например, если ваша цель быстро искать в это БД товары, а ваши 30 колонок - это фильтры, то отлично подходит СУБД для именно что полнотекстового поиска (пусть вас не смущает название, для фасеточного поиска она тоже подходит отлично). Это, к примеру:

• если вы ориентированы на скорость SphinxSearch
  
• если вам нужен кластер, то это ElasticSearch
  
• если вам нужны традиционные инструменты типа SQL, - то это PostgreSQL, MySQL.
  

Если же задача другая - то идеальным выбором может быть и другая СУБД.
Нужны детали.

Думаю, дело в том, что вы увидели эти 90 млн. и решили, что нужно какое-то специфичное решение и не стали даже уточнять детали - а на деле, ничего такого в этих 90 млн. нет. А вот детали задачи - важны.

Рассмотрим задачу быстрой перезаписи - вы имели ввиду все 90 млн. перезаписывать целиком? Не частично. А вот это будет действительно проблемой. Мало какая из СУБД способна на быстрые изменения такого объема.

Ну и третий раз повангую - максимально быстрый доступ к данным - это если данные размещены в оперативной памяти. Один из наиболее развитых инструментов, с размещение в оперативной памяти и с функционалом СУБД - Tarantool. Быстрее, чем in-memory DB, к которым относится Tarantool - и вариантов нет.

Но понадобится соответствующее количество оперативки.

Если оперативки мало, то можно глянуть Aerospike. Это "почти in-memory DB". Но объемы данных могут быть огромны, при небольших запросах к оперативке. От оперативки требуется только целиком вмещать индексы, а не сами данные.

Короче, ванговать мне надоело.

У вас нет постановки задачи - ответить вам посему и нечего конкретного невозможно.

Из бесплатных PostgreSQL, оптимизируйте индексацию, систему хранения СУБД и дисковую подсистему ну и памяти в сервер добавьте, если нужно.
Вообще вопрос абстрактный.
Если вас не устраивает существующий вариант, то нужно найти что именно привело к этому - возможно какая-то конкретная операция (или несколько) заставляет тормозить сервер, нужно их найти и разбираться с ними.
Если просто заменить СУБД, оставив приложение в том же виде, то на новой СУБД вы скорее всего словите те же проблемы, возможно не сразу, а через какое-то время.

Слишком расплывчатое ТЗ. 93 млн в одной таблице? Колонки в таблице длинной 20 байт? Одна таблица в БД?
Вообщем наймите архитектора, что бы потом не мучится с низким быстродействием, внезапными блокировками и прочими прелестями ошибок в архитектуре.

y0 - yN > 0 => down
y0 - yN < 0 => up

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

klas=="231"

сравнение не будет работать так как вы ожидаете. Вы сравниваете указатели на строки (т.е. указатели на начало областей памяти, в которых хранятся строки). Т.к. вы хотите сравнить сами строки, т.е. содержимое вышеупомянутых областей памяти, вам нужно либо:
а) воспользоваться функцией strncmp или аналогичными (это путь языка Си).
б) воспользоваться классом std::string из стандартной библиотеки, и сравнивать объекты этого класса. Они уже сраниваются по содержимому (это путь языка C++)

Посмотрите в сторону NOTIFY/LISTEN: https://postgrespro.ru/docs/postgrespro/10/sql-notify

записей в таблице products очень много ( около 1млн )

это не много, это нормально

и запросы типа JOIN не предлагать, так как оно существенно влияет на производительность

а этот бред вы как догадались сюда приплести? У вас наоборот с выходом из внутренних джоинов выборка по ид будет сокращаться, в итоге по таблице продуктс будет только джоин нужных ид(что аналогично выборке where in, только с меньшими ограничениями, например ордер и лимит). По этому сджойнте мелкие таблицы, получите с них модел_ид, и по нему уже джоин продкут.
Я бы денормализовал продуктс, внес бы еще брэнд_ид в него, но это так, мелочи.

А индексы по foreign key построены? Миллион не такое количество, чтобы join работал плохо.

Альтернативный путь один - денормализация. Надо все сущности добавить прямо в таблицу products отдельными колонками. Чтобы селектить только из этой таблицы.

DevOps по-человечески звучит как "программист и сисадмин в одном лице".

Смотрите содержимое stdio и conio. Где-то в них подключается stdlib, не обязательно на первом уровне.