Сперва строят цоды в жарком и сухом регионе, потом удивляются, что на охлаждение уходит много ресурсов, а с водой напряг.
По цод в космосе:
Охлаждение через излучение - это самый херовый тип охлаждения, достаточно вспомнить устройство термоса (сосуда Дьюара) чтобы понять.
По сути, мы получаем полностью необслуживаемый цод, который в случае мелкой проблемы может, в лучшем случае, деградировать по мощности, а то и выйти из строя. Причём эта проблема решилась бы на Земле руками за 30 минут.
Гео - это не только города в разных частях планеты, но и разные ДЦ в одном регионе. Например, в Московской области, где между ДЦ будет RTT 3-5 мс. Каждый ДЦ - свой кладун. Мы же не хотим побить пользовательские данные? Тогда нам не подходят асинхронные репликации в бд и общем сторадже -> получаем неприемлимые тормоза на сколько-нибудь значимых объёмах записи. Конечно, можно написать, что "у вас будут разные балансировщики", т.е. балансировщик на уровне Мск, который отправит на нужный (ближайший или менее загруженный) кладун в регионе, то тогда чем эта схема отличается от схемы Яндекса?)
но при условии, что у всех кладунов есть общее хранилище (например nfs, главное, что бы у всех кладунов в группе было оно общим, а так же общая БД).
И вот это условие убивает на корню геораспределённые системы.
И из статьи не понятно, но думаю, что "кладун" - это не один сервер с одним диском на который заливается объект целиком, а распределённое хранилище, которое при заливке "нарезает" объёкт, управляет репликацией и т.д.
Как работает приложение Яндекс Диск на компе - не подскажу, не пользуюсь. Вот подключение Яндекс диска через webdav работает полноценно только на чтение и то с проблемами.
Как обычно, сравнение тёплого с мягким. Я возьму сильно фичастый и обмазаный проверками http nginx и код который в тупую отдаёт ответ. Плюс тестировать буду в облаке, где то одно порезали, то другое не работает.
То что с 1 ядра при помощи spdk/dpdk можно обработать ~ 1М iops/packets известно давно.
Требовалось обеспечить минимальный лаг репликации при большой нагрузке (< 1с.).
Дело в том, что даже при штатной репликации изменения применяются последовательно, и поэтому даже при средних нагрузках бывает, что возникает неприятный лаг. Хотелось сделать так, чтобы это работало быстрее.
Стоит учесть, что debezium поддерживает только одну версию репликации = 1 (proto_version = 1) из 4, pg wiki. В этой версии данные оправляются реплике только после завершения транзакции. Если мы захотим залить большое количество данных за одну транзакцию, например, через insert select или copy, то: 1. Все таблицы в этой бд (в той, которой происходила заливка) получат лаг, т.к. публикация была сделана одна с добавлением таблиц в дальнейшем; 2. Лаг может быть очень большой, т.к. процесс разбора wal для публикации на стороне пг однопоточный (для версии 1); 3. Большой лаг -> много wal на сервере.
И вакуум между стенками совсем не причём.
Сперва строят цоды в жарком и сухом регионе, потом удивляются, что на охлаждение уходит много ресурсов, а с водой напряг.
По цод в космосе:
Охлаждение через излучение - это самый херовый тип охлаждения, достаточно вспомнить устройство термоса (сосуда Дьюара) чтобы понять.
По сути, мы получаем полностью необслуживаемый цод, который в случае мелкой проблемы может, в лучшем случае, деградировать по мощности, а то и выйти из строя. Причём эта проблема решилась бы на Земле руками за 30 минут.
Интересно, интел и амд вернутся к разработке архитектуры x86s? На таких процах явно легаси запускать не будут.
Можно писать в вектор через сокет, а он отправит куда нужно.
https://habr.com/ru/news/1039864/comments/#comment_30027514
К слову, у них заявлен
TBW 585 TB для 256 GB (нашёл в гугле), DWPD 3.56 (указано на никсе).
Сата модели с такими характеристиками относятся к серверным и ценник у них +/- такой же (а то и выше), пишу про российский рынок.
UPD.
Ради интереса поискал похожую модель
Samsung PM893 MZ7L3240HCHQ-00A07
В РФ его стоимость 20к + (хотя где-то, якобы, он и дешевле есть, но, скорее всего, в наличии будет 1-3 штуки), в иностранных магазинах от 200 евро.
Гео - это не только города в разных частях планеты, но и разные ДЦ в одном регионе.
Например, в Московской области, где между ДЦ будет RTT 3-5 мс. Каждый ДЦ - свой кладун.
Мы же не хотим побить пользовательские данные? Тогда нам не подходят асинхронные репликации в бд и общем сторадже -> получаем неприемлимые тормоза на сколько-нибудь значимых объёмах записи.
Конечно, можно написать, что "у вас будут разные балансировщики", т.е. балансировщик на уровне Мск, который отправит на нужный (ближайший или менее загруженный) кладун в регионе, то тогда чем эта схема отличается от схемы Яндекса?)
Техножрецы. Начало.
OSM наполняется добровольцами, полно местных дорог (без асфальта), которых там нет.
И вот это условие убивает на корню геораспределённые системы.
И из статьи не понятно, но думаю, что "кладун" - это не один сервер с одним диском на который заливается объект целиком, а распределённое хранилище, которое при заливке "нарезает" объёкт, управляет репликацией и т.д.
Как работает приложение Яндекс Диск на компе - не подскажу, не пользуюсь.
Вот подключение Яндекс диска через webdav работает полноценно только на чтение и то с проблемами.
Только нормально оно не работает.
Странная логика. Если людям хорошо, то зачем им критиковать власть, которая делает хорошо?
И, вроде бы, статья про esim, но как же не приплести СССР?
spotify не забудь скачать.
Проблема параллельной работы приложений получается.
Т.е. никакой телеги через впн + условный, мах.
Да, для шпионской камеры с впн будет проблемой, что приложение от Сбера/Яндекса/ВБ детектит впн.
Как обычно, сравнение тёплого с мягким.
Я возьму сильно фичастый и обмазаный проверками http nginx и код который в тупую отдаёт ответ. Плюс тестировать буду в облаке, где то одно порезали, то другое не работает.
То что с 1 ядра при помощи spdk/dpdk можно обработать ~ 1М iops/packets известно давно.
Зато какая памятка про push/pull!)
Стоит учесть, что debezium поддерживает только одну версию репликации = 1 (proto_version = 1) из 4, pg wiki.
В этой версии данные оправляются реплике только после завершения транзакции.
Если мы захотим залить большое количество данных за одну транзакцию, например, через insert select или copy, то:
1. Все таблицы в этой бд (в той, которой происходила заливка) получат лаг, т.к. публикация была сделана одна с добавлением таблиц в дальнейшем;
2. Лаг может быть очень большой, т.к. процесс разбора wal для публикации на стороне пг однопоточный (для версии 1);
3. Большой лаг -> много wal на сервере.