*Прямая ссылка на видео https://www.youtube.com/watch?v=KCQyMswxbxI
Пересказ видео
Нарушение правил программирования
- Не стоит изобретать велосипед и писать свою базу данных.
- Однако есть случаи, когда это может привести к невероятным результатам.
TER Bitle: новая база данных
- TER Bitle быстрее PostgreSQL в 1000 раз для транзакций.
- База данных разработана под конкретный кейс транзакций.
Оптимизации TER Bitle
- Логические оптимизации: объединение 10-20 запросов в один и батчирование запросов.
- Технические оптимизации: использование однопоточности для уменьшения задержки, новые IPI Линукса, минимизация алокаций.
Установка и запуск TER Bitle
- База данных написана на языке Zig и не имеет нормальной дистрибуции в Docker.
- Рекомендуется запускать на хостовой машине как бинарный файл.
Работа с TER Bitle
- Поддержка работы в режиме кластера, но в данном случае используется однопоточный режим.
- База данных позволяет создавать аккаунты и делать между ними трансферы.
Пример использования TER Bitle
- Создание двух аккаунтов и выполнение трансфера между ними.
- Обработка ошибок при создании аккаунтов.
Проблемы с оптимизацией базы данных
- База данных не оптимизирована под Макосим
- Это может быть причиной некоторых проблем
Создание аккаунтов
- Аккаунты созданы без ошибок
Создание массива с трансферами
- Указывается ID трансфера, аккаунты для добавления и снятия денег, сумма перевода
Создание трансферов
- Используется метод client create transfers
- Массив с трансферами передаётся в метод
Поиск по аккаунтам
- Берётся айдишник первого и второго аккаунта
- Вывод результатов в консоль
Анализ результатов
- Ответ неструктурированный
- Видятся числа, заполняются дебиты и кредиты
Завершение видео
- Спасибо за просмотр
- Призыв подписываться на Telegram-канал
- Надежда на хорошее будущее
Расшифровка видео
0:00
Не изобретай свой велосипед, не ссы
0:02
против ветра и не пиши свою базу данных.
0:06
Это заветы, которым учили нас наши
0:08
предки, наши отцы программирования. Но
0:11
сегодня я хотел бы поговорить о кейсе, в
0:13
котором последнее правило всё-таки можно
0:16
нарушать, в котором оно было нарушено и
0:18
привело к невероятным результатам. Я
0:20
наткнулся на новую базу данных, которая
0:23
называется TER биit. И она быстрее
0:27
постгреса в своём юзкейсе в 1ты000 раз.
0:31
Не в два раза, там не в 10, можно
0:34
подумать, в 1.000. Я предлагаю сначала
0:37
поговорить о том, как вообще возможно
0:38
было добиться такого результата, а потом
0:41
мы попробуем поиспользовать эту базу
0:42
данных в нашем коде, посмотреть, как с
0:45
ней работается, чего она стоит. Значит,
0:47
касательно того, как они вообще добились
0:50
этого результата, что эта база данных
0:52
может быть в тыся раз быстрее
0:54
аналогичного юзкейса на постгресе.
0:56
Начнём с того, что эта база данных
0:58
разработана конкретно
1:00
подкейс транзакций, денежных транзакций.
1:03
И очень конкретно, когда вам условно
1:05
нужно с одного счёта на другой счёт
1:07
перевести какое-то количество денег.
1:09
Тайдербитле ускоряется относительно
1:11
постгреса за счёт двух групп
1:12
оптимизаций. Первый — это логическая, и
1:15
вторая группа — это некоторые
1:18
технические оптимизации. И обе эти
1:20
группы
1:21
оптимизации возможны из-за того, что
1:24
база данных писалась под конкретный
1:26
кейс. Первая группа оптимизаций
1:29
заключается, во-первых, в том, что чтобы
1:31
вам условно провести, перевести кому-то
1:35
деньги в продакшн банковских системах,
1:38
может потребоваться до 10 запросов,
1:41
может быть 20 запросов. Это всё в
1:42
подгресс. Это всё ходит по сети, джоины,
1:46
селекты, инсорты и так далее. Но
1:48
благодаря тому, что база данных
1:50
разрабатывалась под конкретный casй, это
1:52
можно сделать одним запросом, и уже за
1:55
счёт этого достигается 10x оптимизация.
1:57
Но разработчики пошли немного дальше.
1:59
Помимо того, что они объединили вот эти
2:01
условные 10 запросов в одим, они также
2:04
батчем отправляют там 1.000 100
2:08
запросов, которые в один момент
2:10
обрабатываются этой базой. Вторая группа
2:12
оптимизаций заключается в некоторых
2:15
дизайн-решениях
2:17
технических, которые актуальны конкретно
2:20
для этого кейса. Первое, что вас может
2:25
немного удивить, вы спросите, почему они
2:26
так сделали, но эта база данных, она
2:30
сингл-тредовая. Сколько бы у вас не было
2:32
ядер на той машине, на том поде, на
2:35
котором вы запускаете эту базу данных,
2:37
она будет использовать только одно.
2:39
Почему это сделано так? Потому что в
2:42
транзакционных операциях очень важна
2:45
задержка. Цена на акции, цена на
2:47
Форексе, она может отличаться вплоть до
2:50
там секунды. Вот, например, трейдер
2:52
нажал купить сейчас, а через секунду,
2:55
когда эта информация уже дошла, там по
2:56
по всем системам прошла
2:58
по-попокросервисам, там в итоге в
3:00
какой-то баз данных, может пройти уже
3:01
секунда, и цена уже может значительно
3:03
измениться. Если мы делаем приложение,
3:06
которое использует несколько потоков
3:09
системных, то мы так или иначе
3:13
столкнёмся с тем, что у нас будет
3:15
задержка слегка повыше, поскольку пока
3:17
там будет переключаться контекст, пока
3:19
будет локаться какие-то там мьютексы,
3:22
передаваться информация между потоками,
3:24
это добавит, может быть, несколько
3:26
десятков миллисекунд к этому запросу. И
3:28
даже эти десятки миллисекунд могут уже
3:31
сделать недовольными некоторых людей.
3:33
Вторая оптимизация — это использование
3:35
новых IPI Линукса. То есть для i
3:38
операций там
3:39
используется ioюing, а не i Buffд. Я
3:42
здесь, если честно, не очень разбираюсь.
3:44
Я не системный программист, а на сишке
3:46
ничего не делал. Вот. Но это более новый
3:49
API. Старые базы данных, они используют
3:54
старые линуксовские IP, их не могут
3:56
поменять, потому что тогда упадёт
3:58
обратная совместимость этих баз
3:59
данданных. И использование этой новой
4:01
апшки также очень хорошо сказывается на
4:03
задержке. Ещё одна из очень важных
4:05
политик TERLE — это то, что они
4:06
стараются использовать как можно меньше
4:09
алокаций. Поскольку схема данных из-за
4:12
конкретного юзкейса, она очень узко
4:15
специфична, эту схему можно алоцировать
4:17
прямо на стаке. Для тех, кто не совсем
4:19
понимает, что такое стак, что такое хип,
4:21
а я, наверное, куда-нибудь там в
4:23
описании прикреплю ссылочку, статью, где
4:25
это можно почитать. Ну, а вкратце стак
4:28
ихип — это места, где вы выделяете
4:31
память для своей
4:32
программы. Стак он побыстрее, но вам
4:34
нужно обязательно знать, сколько ваши
4:35
данные, сколько сколько ваша переменной
4:37
займёт байт. Он будет работать
4:39
помедленнее, но там вам не обязательно
4:41
знать, сколько ваши данные будут
4:43
занимать место. А локации абсолютно в
4:45
любой программе, абсолютно в любом языке
4:46
программирования, они негативно влияют
4:48
на производительность программы, но это
4:50
терпят, потому что как бы это даёт
4:53
гораздо лучший девелопер experience. И и
4:55
опять же-таки не всегда мы можем знать,
4:57
сколько конкретно памяти мы хотим
4:59
выделить. Собственно, вот так вот
5:00
тайдеer битли добивается приросто в
5:02
1.000 раз по сравнению с подгрисом.
5:04
Также не могу не заметить то, что эта
5:06
база данных написана на языке Zig. Это
5:09
язык, который ещё более хайповый, чем
5:12
Rast. Я о нём говорил в своём видео про
5:14
терлист языков программирования. Если
5:16
кому-то интересно потыкать какой-нибудь
5:18
новый язык, то присмотритесь к зигу. Ну
5:21
ладно, не будем об этом долго. Давайте
5:23
попробуем потыкаться в клавиатуру вместе
5:25
с Тайдербитлем. Итак, мы в терминале, в
5:28
пустой директории. Первое, что нам нужно
5:31
сделать, это установить непосредственно
5:33
саму базу
5:34
данных. А здесь есть небольшой кэтч. А
5:39
дело в том, что нету нормальной
5:41
дистрибуции тайдербитли в докере. Сами
5:45
разработчики рекомендуют запускать её на
5:47
хостовой машине просто как бинарный
5:49
файл. Если что, бинарный файл, кстати,
5:51
весят 600 Кб. То есть вот это вот а вся
5:54
база данных. В принципе, мы берём просто
5:57
копируем необходимую строчку для нашей
6:00
операционной системы. В моём случае это
6:04
MKS. И ждём, пока она скачается. Итак, у
6:07
нас появился бинарник Thдр Bitlin. И
6:09
теперь нам нужно его запустить. Первое,
6:12
что мы делаем — это создаём как бы файл,
6:14
в котором будут храниться все
6:16
данные. У этого бинарника есть команда,
6:19
формат, собственно, запускается. И
6:21
теперь у нас создался файл с расширением
6:24
tйдеer биid. Потом мы запускаем кластер.
6:28
Потом мы можем, собственно, запускать
6:29
нашу базу данных, в которую указываем
6:31
порт, на котором она должна запускаться,
6:33
и
6:34
файл, в котором будут храниться все
6:38
данные. Итак, запустили. Вроде бы
6:41
никаких ошибок нету. Несмотря на свою
6:43
однопоточность, Tider Beitle также
6:45
поддерживает работу в режиме кластера.
6:47
Но мы сейчас этого касаться не будем. Мы
6:48
начнём писать какой-нибудь код. Давайте
6:50
на окошечке это сделаем.
6:52
[музыка]
6:54
Э, и я буду использовать редактор,
6:58
который называется Z. В последнее время
7:00
я его использую для голенских проектов.
7:03
Создадим наш main.
7:05
Файл. И нам нужно скачать саму
7:08
библиотечку для работы
7:13
сдербитле. Скачиваем наш пакет.
7:20
[музыка]
7:25
И добавляем импорт. Проверяем, что у нас
7:29
всё
7:29
работает. Go run
7:35
точечка. Ну понятно. Import
7:39
not. Теперь мы должны
7:40
проинициализировать клиент. Тут нам,
7:42
собственно,
7:44
даже подсказывают немножечко.
7:49
Абсолютно все
7:51
числа внутри тайте битли — это юинты
8:01
Так, ну, насколько мы помним, у
8:05
нас, собственно, адрес —
8:08
это local host
8:11
3.000. Можем просто вписать как бы порт.
8:18
И он уже проинтерпретируется как local
8:20
host
8:21
3.000. Давайте спаникуем и деферим
8:24
клиент. Итак, теперь у нас есть
8:27
подключение к TIDer Битле. Давайте
8:28
проверим, что всё
8:29
работает. Go
8:32
точечка. Так, ну, вроде он не
8:34
спаниковал, значит, всё хорошо. И тут
8:36
всё-таки стоит отметить, что Terрitle —
8:39
это у нас база данных, которая как бы
8:41
прилагается к основной базе данных.
8:46
И всё, что мы здесь можем делать — это
8:48
создавать
8:49
аккаунты, на которых будет написано,
8:51
сколько у этого аккаунта дебита, сколько
8:53
у этого аккаунта кредита, и делать между
8:55
ними трансферы. Поэтому сейчас мы
8:57
создадим два аккаунта и сделаем между
9:00
ними трансфер. Посмотрим, что у нас из
9:01
этого получится. Мы создаём две
9:03
переменные типа
9:05
аккаунт. Э, у нас есть здесь поле ID. Я
9:08
думаю, не надо объяснять, что это такое.
9:10
Ledger Code Fux — это, пожалуй,
9:13
достаточно глубокая тема, которую я не
9:15
хотел бы разбирать в рамках данного
9:16
ролика. Если кому-то будет супер
9:18
интересно, то я выпущу по этой теме пост
9:21
в своём Телеграме. Переходите, как бы,
9:23
подписывайтесь. Ну а пока что мы это
9:25
опустим. После того, как мы создали эти
9:27
переменные, мы с помощью client create
9:29
accounts передаём те аккаунты, которые
9:31
хотим создать. Он нам возвращает ошибку
9:34
в целом вот этого createuns и ошибку
9:36
касательно каждого аккаунта. То есть вот
9:38
эта ошибка может быть, например, что мы
9:40
потеряли подключение к кластеру,
9:42
произошло что-то подобное. А акаут error
9:44
это ошибка для каждого аккаунта.
9:46
Например, если аккаунт ноль уже
9:47
существует, аккаунта один ещё нету, то
9:49
будет ошибка только по аккаунту один.
9:52
Общей ошибки не будет, но нулевой
9:54
аккаунт
9:57
создастся. Так, чтобы у нас гошечка не
9:59
ругалась, это мы уберём.
10:13
И попробуем это
10:15
проранить. Так, вроде бы всё прошло. А
10:18
он у нас жалуется, что у нас был
10:19
медленный запрос на 600 мскунд. Но я так
10:22
полагаю, это связано с тем, что мы этого
10:23
раним на Макосим, а как бы эта база
10:27
данных абсолютно не оптимизирована под
10:29
Макосим. Но тем не менее аккаунты у нас
10:31
создались, никакой ошибки не произошло.
10:34
Ну, теперь мы создаём массив с
10:36
трансферами, в котором указываем ID
10:38
этого трансфера, аккаунт, которому мы
10:40
будем добавлять деньги, аккаунт, с
10:42
которого мы будем снимать деньги и,
10:43
собственно, сумму, которая будет
10:45
переводиться. После этого мы точно также
10:48
делаем
10:49
client create
10:52
transfers и передаём туда массив с
10:54
нашими трансферами. Извините,
10:56
слайснчики.
11:04
Ну и после этого мы проводим поиск по
11:07
аккаунтам. Берём айдишник первого
11:09
аккаунта, айдишник второго аккаунта и
11:11
выводим то, что у нас получилось
11:12
консоль. Как бы здесь достаточно
11:15
неструктурированный ответ, но в целом мы
11:18
видим, что какие-то числа помимо
11:21
там ленджера и кода у нас
11:24
появляются, заполняются дебиты и
11:26
кредиты. И вот как-то так это работает.
11:29
Спасибо, что досмотрели это видео до
11:30
конца. Призываю вас подписываться на мой
11:33
Telegram-канал. Надеюсь, что у всех всё
11:35
будет хорошо.