BufWriter<Master<'_>> – Telegram
BufWriter<Master<'_>>
105 subscribers
451 photos
28 videos
34 files
1.7K links
https://www.patreon.com/alxe_master

Видео/статьи. Конспект и мои вольные комментарии по инженерии. тут только то, что считаю полезным для себя или других =)

#os, #cloud, #rust, #golang, #python, #javaScript, #cpp, etc
Download Telegram
HTTP/2
== Протокол HTTP/2: что это, преимущества и как им пользоваться
https://vps.ua/blog/protocol-http-2-benefits/

== Wiki HTTP/2
https://ru.wikipedia.org/wiki/HTTP/2

== Разъяснение http2
https://habr.com/ru/post/221427/

IETF и рабочая группа HTTPbis

Инженерный совет Интернета (IETF) – разрабатывает и продвигает интернет стандарты. на протокольном уровне. документирующих всё: от TCP, DNS, FTP до лучших практик, HTTP и множества вариантов протокола, которые нигде не были применены.

Рабочая группа HTTPbis сформирована в 2007 года и должна была обновить спецификацию HTTP 1.1 — отсюда и суффикс «bis». Обсуждение в группе новой версии HTTP протокола по-настоящему началось в конце 2012 года. Работа над обновлением HTTP 1.1 была завершена в начале 2014 года.

Заключительное совещание для рабочей группа HTTPbis перед ожидаемым финальным выпуском версии спецификации http2, пройдёт в Нью-Йорке в начале июня 2014 года.
Группа названа HTTPbis, где суффикс «bis» происходит от латинского наречия, которое означает «два». Бис часто используют как суффикс или часть имени внутри IETF для обновления или второй попыткой работы над спецификацией. Также, как в случае HTTP 1.1.

концепт новой версии хттп2:
- Она должна поддерживать парадигмы HTTP. Это по-прежнему протокол, где клиенты отправляют запросы на сервер поверх TCP.
- Ссылки http:// и https:// не могут быть изменены. Нельзя добавить новую схему или сделать что-нибудь подобное.
- HTTP1 серверы и клиенты будут существовать ещё десятилетия, мы должны иметь возможность проксировать их к http2-серверам.
- Следовательно, прокси должны быть способны конвертировать один в один возможности http2 в HTTP 1.1 для клиентов.
- Удалить или уменьшить число опциональных частей в протоколе. Это даже не столько требование, сколько мантра, пришедшая от SPDY и команды Google.
- Больше нет минорных версий. Было решено, что клиенты и серверы могут быть либо совместимы с http2, либо нет. Если окажется, что необходимо расширить протокол или изменить его, тогда появится http3. В http2 больше не будет минорных версий.

SPDY работал только поверх TLS и было сильное желание сделать TLS обязательным и для http2, но консенсус не был достигнут и http2 будет выпущен с опциональным TLS. Однако, Firefox и Chrome. заявили, что они будут реализовывать только http2 поверх TLS

http2 – это бинарный протокол.

Сотни одновременных потоков. Цена создания потока очень низкая. Каждый поток имеет приоритет

Вы можете просто отменить отправку и начать новое сообщение, отправляя http2-фрейма RST_STREAM,

Сервер-пуш

Сервер отправляет заголовок Alt-Svc (или ALTSVC-фрейм в http2), сообщая клиенту о наличии альтернативного хост и номер порта. Ожидается, что клиент попытается асинхронно подключиться и начать использовать

== Введение в HTTP/2
https://developers.google.com/web/fundamentals/performance/http2?hl=ru
HTTP/3

== Протокол HTTP-over-QUIC официально становится HTTP/3
https://habr.com/ru/company/globalsign/blog/429820/
https://habr.com/ru/company/globalsign/blog/429820/

== HTTP/3: разрушение основ и дивный новый мир https://habr.com/ru/company/dododev/blog/473930/
Pluralsight_20Patterns_ebook(1).pdf
9.2 MB
20 patterns to
watch for in your
engineering team

- Domain Champion
- Hoarding the Code
- Unusually High Churn
- Bullseye Commits
- Heroing
- Over Helping
- Clean As You Go
- In the Zone
- Bit Twiddling
- The Busy Body

- Scope Creep
- Flaky Product Ownership
- Expanding Refactor
- Just One More Thing
- Rubber Stamping
- Knowledge Silos
- Self-Merging PRs
- Long-Running PRs
- A High Bus Factor
- Sprint Retrospectives
== R.I.P. – ВСЕГО 1 ОТКАЗ, ПОХОРОНИВШИЙ INTEL...– [Кремниевые Секреты]
https://youtu.be/jK7GRnoJ11A
спойлер
отказались разрабатывать АРМ проц для эппла
12technologies.pptx
13 MB
преза по ИИ

то что будет развиваться:
1) Deep Learning
2) Capsule Neural Networks
3) Deep reinforcement learning (DRL)
4) Generative adversarial network (GAN)
5) Lean and augmented data
6) Probabilistic programming
7) Hybrid learning models
8) Automated machine learning (AutoML) 9) Digital twin
10) Explainable AI
11) AI Chatbots
12) AI Accelerators

Я боюсь не того компьютера, который пройдет тест Тьюринга, а того, который его намеренно завалит...

Обмануть нейросеть
- Adversarial training (состязательное обучение)
- вредоносные примеры
- универсальное искажение
- PIXEL attack for fooling deep neural networks
- The Adversarial Patch
- специальные очки
- Дорожные знаки - обманки

https://www.youtube.com/watch?v=IY69r79iIJU
Forwarded from Блог*
#prog #rust

Пара слов о трейте Copy.

Во-первых, это один из "магических" трейтов, помечен атрибутом #[lang = "copy"]. Компилятор проверяет, что если тип тем или иным способом задекларирован как Copy, то и всего его поля должны быть Copy. Следующий код не компилируется:

#[derive(Clone, Copy)]
struct StringHolder(String);

Ошибка:

error[E0204]: the trait `Copy` may not be implemented for this type
--> src/lib.rs:1:17
|
1 | #[derive(Clone, Copy)]
| ^^^^
2 | struct StringHolder(String);
| ------ this field does not implement `Copy`

Во-вторых, один и тот же тип не может реализовывать Copy и Drop одновременно. Скажем, следующий код не компилируется:

#[derive(Clone, Copy)]
struct Primitive;

impl Drop for Primitive {
fn drop(&mut self) {}
}

Ошибка:

error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
--> src/lib.rs:1:17
|
1 | #[derive(Clone, Copy)]
| ^^^^ Copy not allowed on types with destructors

Так как полноценных negative trait bounds в Rust всё ещё нет, ограничение Copy можно использовать как более сильную замену ограничению !Drop.

В-третьих, как сказано в документации к Copy, "Copies happen implicitly, for example as part of an assignment y = x. The behavior of Copy is not overloadable; it is always a simple bit-wise copy.". С другой стороны, Clone является супертрейтом Copy, и наличие реализации Copy не мешает вызывать .clone() явно. Однако, в отличие от Copy, Clone::clone в принципе может вызывать любой код. Поэтому, в частности, технически замена в итераторной цепочке .cloned() на .copied() является ломающим изменением, даже если элементы итератора реализуют Copy.

Продемонстрирую на примере:

use std::cell::Cell;

struct Counter<'a>(&'a Cell<u32>);

impl Clone for Counter<'_> {
fn clone(&self) -> Self {
self.0.set(self.0.get() + 1);
Self(self.0)
}
}

fn main() {
let n = Cell::new(0);
let arr = [Counter(&n), Counter(&n), Counter(&n)];
arr.iter().cloned().for_each(drop);
println!("`Counter::clone` called {} times", n.get());
}

Если запустить этот код, то он напечатает `Counter::clone` called 3 times. Теперь добавим к определению Counter аннотацию #[derive(Copy)] и допишем в main тот же код, что там есть, но с заменой .cloned() на copied():

fn main() {
// ...

let n = Cell::new(0);
let arr = [Counter(&n), Counter(&n), Counter(&n)];
arr.iter().copied().for_each(drop); // изменение в этой строке
println!("`Counter::clone` called {} times", n.get());
}

Код теперь выводит:

`Counter::clone` called 3 times
`Counter::clone` called 0 times

Берегите себя и не пишите, пожалуйста, в Clone::clone что-то помимо собственно клонирования.
https://habr.com/ru/post/240405/ старая статья голопом по европам про хадуп и почти всю его инфру
- HDFS
- MapReduce, Spark, Tez
- Hive, Impala, Shark, Spark SQL, Drill, HBase
- Kafka
- Spark Streaming
- Mahout, MLlib
- Parquet, ORC, Thrift, Avro
- ZooKeeper
- Hue
- Flume
- Sqoop
- Oozie
- Azkaban
== Форматы файлов в больших данных: краткий ликбез
https://habr.com/ru/company/mailru/blog/504952/
- Avro VS Parquet
Avro = хранит по строкам
Parquet = хранит по столбцам
Parquet лучше подходит для аналитики, = чтение эффективнее чем запись.
Avro записывает эффективней чем Parquet.
Avro лучше с эволюцией схем. Parquet поддерживает только добавление схемы
Parquet идеально подходит для запроса подмножества столбцов в многоколоночной таблице.
Avro подходит для операций ETL, где мы запрашиваем все столбцы.
- ORC VS Parquet
Parquet лучше хранит вложенные данные.
ORC лучше приспособлен к проталкиванию предикатов (predicate pushdown).
ORC поддерживает свойства ACID.
ORC лучше сжимает данные.
== Базы данных в современной IIoT-платформе
https://www.youtube.com/watch?v=wigSv2_zWBU&feature=youtu.be

прототип
* tarantool as db + app seerver
* lua - как язык для хранимые процедуры
* все данные в памяти

код как хранимые процедуры
- нельзя обновить приложение без обновления БД. может вызвать непрогнозируемые проблемы.
- нельзя динамически масштабировать нагрузку

новая версия
- kubernates
- микросервисы
- стэйтлес и стейтфул приложения

требования к базе:
- ACID + строгая консистентность
- горизонтальное масштабирование на запись и чтение
- высокая доступность
- хранение больших обьемов данных
- хорошая производительность

Метаинформация (реляционные, правятся редко = CA = один мастер, много слэйвов)
* метаинформация, устройства, настройки, правила
* нужна поддержка деревьев с произвольной длиной и шириной
* нужна транзакционная модификация
* быстрый обход
=> Tarantool = это фрэймворк для построения базы данных в нужном виде

Данные от устройств (AP)
* показания датчиков, телеметрия. служебная информация
* Time Series
* OpenSource
* Бесплатный кластер
* хорошее сжатие
* успешная эксплуатация
=> Clickhouse

Clickhouse
= колоночная база данных
= кластер
= шардирование
= SQL
+ успешный опыт
- производительность на запись => буферизация записи и батч запись => Задержки
- производительность на чтение => кэш для данных за период

требования к Кэш бд = AP = много мастеров
- производительность
- горизонтальное масштабирование на чтение и на запись
- высокая доступность
- средства аналитики
- ттл
- персистентность
=> Tarantool + устаревание данных на хранимых процедурах

Требования к БД для состояний
- горизонтальное масштабирование на чтение и на запись
- высокая доступность
- отказоустойчивость
- консистентность на уровне документа
- можно пожертвовать общей консистентностью
- можно пожертвовать ACID транзакциями
=> MongoDB, Redis, Tarantool

Tarantool
= быстрое хранилище K-V
= фрэймворк для создания бд
= хранимые процедуры

= кафка как буфер перед кликхаусом. раз в секунду пушат в бд из буфера
== Greenplum: от двух до сотен серверов
https://youtu.be/FXij7xWqlsc

Greenplum = аналитическая СУБД
* Postgres based
* Opensource

+ сложные запросы, обрабатывающие большие обьемы, без знания какие запросы будет делать аналитик
+ ETL/ELT
+ Эффективное соединение больших таблиц = Ad-hoc запросы
+ Работа с индексами
+ Дата сайнс
+ Аналитические функция на PL
+ Ad-hoc аналитика
+ скорость при подключении нового кластера не падает, а ростет
+ партиционирование
+ одна таблица может содержать несколько партиций
+ партиции могут быть находится на разных устройствах, разного типа, сжатия и тп
+ транзакционирование на уровне БД
+ само разбивает на разные стораджи и строит внутренние запросы и само ходит в разные системы
== КлАССИЧЕСКИЙ МАП РЕДЬЮС НО
+ в транзакциях
+ SQL
+ и в разы проще для пользователя, так как он и не знает что это мап-редьюс
+ выделение ресурсов ядра под конкретные процессы явно, для конкретных юзверей
+ безопасность, группы, роли, права на обьекты
+ LDAP
+ SSL - от клиента к мастеру и от мастера к сегментам
+ Row-Level security
+ бэкапы делаются паралельно на всех сегментах

Схемы хранения данных
+ звезда
+ снежинка
+ Data Vault

Гринплан не ГЕО-распределенная система. он должен стоять в одном ЦОДе

Консистентность самое главное для гринплам

РАзрабатывался как замена терадаты, терадата быстрей, но все с терадаты уходят

Когда говорим про то что хватит ли этой СУБД для этой задачи, в основном мы говорим про диски. про их компрессию, про то как оно с ним работает, и как хранит
== Безопасность и СУБД
https://youtu.be/n-54j9FHaMU

1) защищаем подключение

Сначала надо выяснить:
- 1 бизнес пользователь = 1пользователь в СУБД ?
- доступ к данным только через апи ?
- СУБД выделена в отдельный сетевой сегмент ?
- использует пулл соединений ?

первое что можно поменять
- db firewall
- парольные политики
- обогащайте контекст сессии в нужной иформации
- SSL (если нет сетевого разграничения)

Почему SSL Не оч хорошо:
- нагрузка на ЦПУ
- увеличение таймингов
- уменьшение TLS
=> На самом деле небольшие нагрузки не дают оверхэда
- Trust, md5 аутентификация

2) Аудит
для Postgres есть дефолтный
но есть и`pgaudit`
обязательно смотрим на pgbench

3) ограничение доступа к данным
- шифрование и обфускация процедур и функций (Wrapping)
- ограничение видимости данных по строкам (RLS)
- редактирование отображаемых данных (masking)
- разграничение доступа Security DBA / app dba/ dba
- ограничение доступа к файлам на уровне ФС
- мандантный доступ
- очистка паматия
- end2end шифрования
- шифрование данных

pgcrypto
- взять ключ на сервере
- взять ОДНУ колонку из бд
- зашифровать
=> замедляется запрос в ~50раз
- НЕ серебренная пуля!!!

лучше end-to-end шифрование

в энтерпрайзе все решалось уже давно
в опенсорсе мало чего есть
== Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
https://youtu.be/NEgm1nsv-qg

просто хороший доклад про то как ребята варили с3 в майлРу

nginx
api
meta db = tarantool
fs = paired files storage
pair db = tarantool

bucket
-- project
-- segment
-- credentials
-- billing
-- obj

!!! рейтлимиты
!!! кэш
!!! автофэйловер
!!! масштабирование
!!! шардинг тарантула с обьектами + прокси для шардирования
!!! корзина
!!! версионирование данных
!!! работа через балансировку
!!! отдельный сервис для билинга

кастомная функция шардирования
- все обьекты бакета будут лежать в одном сабсете
- нужно много делать мапредьюс и поэтому листинг будет быстрым если в одном сабсете
- решардинга хочется избежать!!!
= снижается нагрузка влияния одного бакета на другие

Nginx
- через луа расширения для выделения отдельных сертификатов