🚀 Hello World!

Первый пост в новом канале, это так волнительно

Вкратце что здесь планируется:
- Новости про Go конференции
- Новости и интересные штуки про сам Go
- Немного архитектуры
- Много духоты

О себе:
Go разраб, начал писать 9 лет назад и не могу соскочить
ex Positive Technologies
ex VK Tech

Вхожу в программный комитет конференции GoFunc и E-CODE.
Иногда являюсь спикером

Достаточно крутой доклад с осеннего GoFunc, про аллокации при работе со строками:

https://youtu.be/HDK3BPA-t68
https://vk.com/video-222141090_456239037

Конечно же он 🥁🥁🥁 мой

😀ЗАПУЩЕНО ПРИЛОЖЕНИЕ
😅ЗАПРОС ВЫПОЛНЯЕТСЯ БЕСКОНЕЧНО ДОЛГО
🥲ПО ЛОГАМ НЕ ПОНЯТНО ЧТО ПРИЛОЖЕНИЕ ЖДЕТ
🫡В ДЕБАГЕ ООЧЕНЬ МНОГО ГОРУТИН

Что делать?

pprof.Do() — позволит "пометить" горутины LabelSet(ом) внутри рантайма, с этими labels дружит как минимум профайлинг и дебаг в Jetbrains.

И достаточно важно, LabelSet наследуется на новые горутины.

Небольшой пример:

pprof.Do(
    ctx,
    pprof.Labels("path", r.URL.Path),
    func(ctx context.Context) {
       // next.ServeHTTP(w, r)
    },
)

В общем штука достаточно крутая, вижу следующие минусы:
- panic не пишет LabelSet горутины
- есть небольшой оверхед при создании горутины, но им можно пренебречь

Люблю когда простые вопросы заставляют копнуть вглубь какой-либо вещи

Простой вопрос:
Как посчитать длину строки?

len("👩🏻‍❤️‍👨🏻") // 28

Мы получили 28, хотя ожидали что получится 1

Вспоминаем что-то про UTF-8, понимаем что получили длину в байтах и идем в одноименный пакет:

utf8.RuneCountInString("👩🏻‍❤️‍👨🏻") // 8

Ближе, но все равно не то, у нас ведь 1 символ, а получили 8 чего-то. Судя по названию функции каких-то rune.

И тут достаем лопату ⛏️⛏️⛏️

Строки в Go поддерживают Unicode, используя кодировку UTF-8.

Unicode — это набор символов.
Code point — минимальная единица Unicode.
UTF-8 — кодировка для Unicode, один из способов хранения Unicode.
Графема — последовательность из одного и более code point, которая отображается как один графический элемент.
Глиф — конкретный рисунок шрифта, который отображает графему.

Rune это как раз code point, считаю несколько странным, что только в Go spec это есть

Code point может быть самодостаточным: а может быть дополняющим, к примеру глиф 👩🏻‍❤️‍👨🏻 комбинирует несколько code point:
1. couple with heart
2. woman
3. man
4. light skin tone
все кроме последнего code point являются так же и графемой, а ligth skin tone не может использоваться самостоятельно.

В итоге используя стандартную библиотеку utf8, мы посчитали количество code point.

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

uniseg.GraphemeClusterCount("👩🏻‍❤️‍👨🏻") // 1

И получаем 1, это то что мы хотели?

Не совсем, мы подсчитали количество графем, НО за количество глифов отвечает непосредственно тот, кто будет рендерить символы — браузер, терминал и так далее...

В итоге отвечая на вопрос: а количество чего именно мы хотим подсчитать в строке?

Продолжая тему кодировок и немного обещанной духоты.

ASCII фактически сейчас описывается не в ANSI X3.4-1968
А в Unicode, так как по ANSI это 7 битный код
На данный момент никто не отправляет 7 бит, ASCII по факту является 8 битной кодировкой, где старший бит помечен как: "reserved, do not use"

Дополнение к предыдущему посту.

Я не нашел PDF от 1968 года, только от 1977, но в самом документе сказано, что это версия от 1968.

Когда-то я напишу про то: почему в одном байте 8 бит, и почему ASCII 7 бит.

Каждый раз, когда заходит речь про JWT, Я вспоминаю эту схему, которую увидел аж в далёком 2021

В целом, отличный канал, советую подписаться:

Дежурное напоминание: пожалуйста, не используйте JWT вместо сессионных ключей, особенно если пользователь ходит буквально только до одного сервиса. Это не несёт вообще никаких плюшек и лишь усложняет логику аутенфикации. Проверка подписи на токене абсолютно бессмысленна, а хранить толстое состояние клиента в токене просто неразумно.

Самый нормальный случай использования токена -- это oauth с третьесторонними сервисами авторизации типа google.

А в эту пятницу хочу поделиться легендарным видео: первой презентацией Docker

Docker родился и использовался внутри компании dotCloud (облачная платформа для разворачивания приложений)

В 2013 году Docker был презентован миру, при том что во время небольшой сессии lightning talks на PyCon US 2013

Docker на тот период был оберткой над LXC, 10 марта 2014 года уже научился напрямик использовать cgroups, namespcases и другими функциями ядра

Для понимания, как было до Docker:
1. Создать LXC.
2. Создать новую файловую систему.
3. Подмаунтить RW слой.
4. Создать нетворк.
5. Назначить IP для контейнера.
6. Настроить NAT.
7. Выполнить процесс в контейнере и захватить его output.

После: на видео видно, как легко запустить контейнер.


https://youtu.be/wW9CAH9nSLs

А на выходных поговорю подушню про B-tree.

Когда спрашивал у кандидатов, во время интервью про индексы в PostgreSQL, кандидаты вспоминали про B-tree, но очень часто ошибочно придают смысл букве B: Balanced или Binary.

Почему это не верно:
- Balanced tree — сбалансированность это свойство дерева.
- Binary tree — другой тип данных.

B-tree было создано в Boing в 1970 году, над созданием работали: Rudolf Bayer и Edward M. McCreight.
И вроде B может значит: или Bayer, или Boing :)

Но нет, буква B не значит ничего, в документе, где впервые рассказали про B-tree нет ни слова про то: что же значит буква B.

Микро факты:
- B-tree создан не совсем в Boing, а в Boeing Research Lab.

- Rudolf Bayer не связан с компаний Bayer :)

- Rudolf Bayer был причастен к созданию:
🤯 UB-tree (ломающее мозг дерево), надеюсь не нужно будет с ним работать;
👩🏻‍💻 Red-black tree (красно-черное дерево) самобалансирующееся бинарное дерево поиска.

В PostgreSQL нет B-tree

Да, в документации описан именно B-tree

Но PostgreSQL на самом деле использует Lehman and Yao's high-concurrency B-tree, в дальнейшем эту структуру данных буду называть как: B*-tree, так как в описании Lehman и Yao используют именно это определение.

В чем разница?

Как выглядит B-Tree:

     +------+      
     |11  13|      
  +--+--+---+--+   
  |     |      |   
+-v--+ +v-+ +--v--+
|9 10| |12| |14 15|
+----+ +--+ +-----+

Так выглядит B*-tree:

           +----+                  
      +----+ 11 +-----+            
      |    +----+     |            
      |               |            
    +-v+---------->+--v---+        
  +-|10|+      +---|12  13|---+    
  | +--+|      |   +--+---+   |    
  |     |      |      |       |    
+-v+  +-v-+  +-v-+  +-v-+  +--v---+ 
|9 |--> 10|--> 11|--> 12|--> 13 14|
+--+  +---+  +---+  +---+  +------+

У B-tree и у B*-tree есть параметр: k.

И в одной вершине содержится от k до 2k значений.
А это значит что для вставки возможно нужно как бы расщеплить/разделить вершину.

Видно по структуре B-tree что поиск ведется сверху-вниз, в связи с этим при вставке, путь до нужной вершины может поменяться во время вставки данных.

А вот в B*-tree есть возможность вести поиск сверху-вниз, слева-направо. В связи с этим можно осуществлять поиск без read locks.

N.B.
Разработчики PostgreSQL (PostgreSQL Global Development Group) реализовали B*-tree с изменениями.

Так какие изменения были внесены B*-tree командой PostgreSQL?

Не хочу сильно углубляться во внутренних изменения.
(Когда и какие локи применяются, расщепляется ли корень при переполнении и так далее)

Расскажу вот о чем:
Для нижних узлов добавили связь справа-налево:

+--<--+---<--+---<--+---<--+------+
|9 |  | 10|  | 11|  | 12|  | 13 14|
+--+-->---+-->---+-->---+-->------+

Что позволяет использовать index scan backward, для агрегатной функции max или ускорить обратную сортировку.

TIP_0:
PostgreSQL позволяет указать в каком порядке хранить данные в индексе (пока что поддерживается только B-tree)
При создании индекса можно указать ASC | DESC, на больших данных или в составных индексах это может сильно ускорить запрос, особенно при ORDER BY в сочетании с LIMIT n.

TIP_1:
PostgreSQL поддерживает Index-Only Scans — возможность выполнения SELECT обращаясь только к индексу, без обращения к страницам таблицы.