== Базы данных. Лаборатория Tarantool. Введение в современные СУБД
https://youtu.be/ejS2DE-ar3A
достойный преподаватель из кор тимы Тарантула
acid - atomic, consistency, isolation, durability

== Базы данных. Лаборатория Tarantool. Современные алгоритмы для двухуровневой памяти
https://youtu.be/0A4_SdNEH8c
- диск-память-кэш-процессор
- стоимостная модель
- проблема memory-layout матрицы
- транспонирование матриц
- log-structured-merge дерево
- bloom фильтр
- двойная буфиризация (пишем в один, сбрасываем на диск второй, чередуем)
LSM БД юзаются для частого обновлеющихся данных
- Fractional Cascading - способ уменьшить затраты для упорядоченных структур
- bit-cask. Append only file (AOF) - нет спаек при записи как у LSM. Надо переписывать индекс каждый раз в конец вместе с изменениями
- page-index сохраняет мин-макс в ячейке, что бы сократить время поиска

== Базы данных. Лаборатория Tarantool. Кэширование
https://youtu.be/jhAOFFUVSjk

Least Recently Used - вытеснение давноиспользуемых (одновязанный список, например)
- былали изменена страница?
- завершена ли транзакция, кот модифицировала страницу ?
- физический порядок страниц на диске
- вытеснение осуществляется превентивно в другом потоке

для Index Scan лучше MRU

Midpoint insertion strategy
- LRU разбивается на тёплую и горячую зоны
- Граница между зонами плавающая
- index scan более не «вымывает» кэш

Идея
Балансировать между малыми и большими издержками до тех пор пока сумма малых издержек не превысит большие

LFD - longest forward distance (~clairvoyant algorithm, ~Belady's algorithm)
выталкиваем страницу которая будет запрошена позже всего в будущем

Для любого другого алгоритма А, cost(A) не ухудшается если мы, в случаях когда A отличается от LFD, выталкиваем страницу в
соответствии с LFD, а не с A

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

алгоритм консервативен если нет чтения когда работаем с элементами которые в памяти. так же увеличение кэша линейно увеличивает производительность (в лучшем случае линейно)

Рандомизированный алгоритм: MARK
- Помечает страницу при использовании (они не выталкиваются)
- Когда все страницы помечены, и нужна страница, все пометки снимаются (кроме пометки на новой странице)
- Для выталкивания выбирается случайная страница из непомеченных
====> const(MARK) = lg(k) * cost(LFD)

LRU таким образом в целом не хуже чем MARK (на случайных данных)

== Caching and Cache-Efficient Algorithms
https://youtu.be/xDKnMXtZKq8
Fully Associative Cache
Direct-Mapped Cache
Set-Associative Cache

Taxonomy of Cache Misses
- cold miss
- capacity miss
- conflict miss
- sharing miss
Conflict Misses for Submatrices

Ideal-Cache Model
How Reasonable Are Ideal Caches?
Cache-Miss Lemma
Tall Caches
What's Wrong with Short Caches?
Submatrix Caching Lemma
Multiply Square Matrices
Analysis of Cache Misses
Swapping Inner Loop Order
Tiled Matrix Multiplication
Two-Level Cache

тот момент когда лекции MIT оч хорошо рассказывают то где ты уже сьел целый выводок собак, но блять где вы были раньше ? )))

но насколько же круто они преподают... захотелось быть студентом у них на курсе

== Bit Hacks
https://youtu.be/ZusiKXcz_ac

0b10010110
signed int -106 = 2 + 4 + 16 - 128
unsigned int 150 = 2 + 4 + 16 + 128
0b11111111 => -1

x + ~x = -1
-x = ~x + 1



A    = 0b10110011
B    = 0b01101001
A&B = 0b00100001
A^B = 0b11011010
A|B = 0b11111011
A >> 3 = 0b00010110
A << 2 = 0b11001100

- set
- clear
- flip
- extract
- set x to y
- swap without temp var
(x ^ y) ^ y
- min x and y
m = y ^ ((x ^ y) & -(x < y))
NO BRANCHES -> no performance leaks!
- branchless merging sorted arrays
- power of 2
- kog base 2 of power of 2

ну просто шикарные преподы в MIT. даже то что знаешь хорошо просто приятно послушать

== Assembly Language & Computer Architecture
https://youtu.be/L1ung0wil9Y

data movement
- mov, cmov
- sigh or zero extension: movs, movz
- stack: push, pop
arithmetic and logic
- int logic: add, sub, mul, imul, div, idiv, lea, sal, sar, shl, shr, rol, ror, dec, neg
- bin logic: and, or, xor, not
- bool logic: test, cmp
Control transfer
- unconditional jump: jmp
- conditional jumps: j<condition>
- subroutines: call, ret

for fetching something from memory - x*100 тактов

compiler generates NOP lines for optimize instruction memory (code, size, alignment....)

SSE and AVX supports x64 fpu
sufixies: ss, sd, ps, pd

pipelininig improves processor throughput !
but
- structural hazard (one instruction for one tact)
- data hazard (depends from result):
- i writes a location that j reads
- j reads location that j writes
- i and j write to the same location
- control hazard (fetching/loading/storing etc operators)

== Seaborn - лучшая data science библиотека для визуализации на Python
https://youtu.be/gMSQMLeQ4UI

🆖 Nginx common useful configuration - вдруг кто-то найдёт для себя что-то полезное для работы с Nginx. Там ещё и ссылок приличное количество имеется, по ним тоже имеет смысл пройти.

#nginx #будничное

🆖 Comparing NGINX Performance in Bare Metal and Virtual Environments - сравнение производительности Nginx на голом железе и в виртуальном окружении.

#nginx #kubernetes #baremetal

у меня очередной небольшой виток в схемотехнику )

== Намотка импульсного трансформатора
https://youtu.be/gIacydXiF0o
нюансы импульсных блоков питания. особенности намотки трансформаторов для импульсников. разбор резонансов и параметров

== A power supply with voltage regulation
https://youtu.be/Wq0JFW2KhUo

== STM32 - программирование для начинающих. Пошагово. CubeMX CubeIDE
https://youtu.be/fxAsY0S2Xa0

#prog #python #meme

https://twitter.com/fasterthanlime/status/1248025337235210243

если чтото идет не так с маунтом то
sudo mount -a
оч помог в дебаге того что намутил в fstab

Сбор и хранение данных

SQL
- «SQL Problems and solutionsS», I. Moiseenko Интерактивный учебник по SQL
- ByteScout SQL Trainer Быстрый и приятный тренажер, усложняющийся по мере вашего продвижения.
- Simple SQL Queries Упражнения для Постгреса
- SQL Tutorial for Beginners: Database, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIKE, IN, BETWEEN
- Тренажер по SQL
- Как посчитать всё на свете одним SQL-запросом. Оконные функции PostgreSQL https://habr.com/ru/post/268983/
- Простенький тренажер с теорией https://sqlzoo.net/wiki/SQL_Tutorial
- Мануал по установке PostgreSQL в MacOS https://www.robinwieruch.de/postgres-sql-macos-setup
- Пример обращения к MySQL с помощью Python, используя библиотеку sqlalchemy https://pythondata.com/quick-tip-sqlalchemy-for-mysql-and-pandas/
- Пример обращения к PostgreSQL с помощью Python: https://khashtamov.com/ru/postgresql-python-psycopg2/
- window function - https://learnsql.com/course/window-functions
- window function - https://campus.datacamp.com/courses/intermediate-t-sql/window-functions?ex=4
- Хорошая статья об оконных функций SQL - https://khashtamov.com/ru/window-functions-sql/

Парсинг
- Русский перевод документации к BeautifulSoup Beautiful Soup — это библиотека Python для извлечения данных из файлов HTML и XML. Она работает с вашим любимым парсером, чтобы дать вам естественные способы навигации, поиска и изменения дерева разбора. Она обычно экономит программистам часы и дни работы.
- Статья с примером парсинга данных с веб-сайтов с применением BeautifulSoup Освещены все основные этапы: формирование запроса и получение странички с помощью requests, поиск нужного элемента в HTML через инспектор, выделение данных из элемента через методы BeautifulSoup.

API
Работа с первичной аналитикой: выгружаем сырые данные из Метрики с помощью скрипта

То чувство, когда Telegram начинает тестировать рекламные сообщения... но не на твоем канале. Потому что и Дурову ты не нужен.

забавный редактор для 3D
https://www.tinkercad.com
забавно что построено это немного по другому принципу, нежели в солидворкс. очень напомнило флэш в логике создания обьектов
сложных инженерных штук мне кажется сделать будет нереально но для 3д принтера накидать побыстрому чтото простое очень даже в тему. онлайн это плюс

​Юлий Цезарь в мире ИИ:  Google разрабатывает многозадачную ИИ-модель Pathways

Корпорация Google заявила о начале работы над проектом из сферы ИИ, в рамках которого корпорация планирует создавать комплексные нейросети. Они, по словам разработчиков, смогут одновременно работать над решением тысяч или даже миллионов разных тасков одновременно. Проект получил название Pathways.

#ai #google

ARIES (1/8)

Введение.

ARIES — алгоритм записи и восстановления данных в транзакционных системах, основанный на write-ahead logging (WAL). Он поддерживает как полный, так и частичный роллбек транзакций, подходит для разных политик buffer manager (часть БД, отвечающая за запись данных с памяти в диск и обратно. Подробнее — ниже), а также позволяет использовать гранулярные блокировки вплоть до блокировки отдельных строк. ARIES основан на полном повторе истории при восстановлении. Другими словами, он не делает разницы между транзакциям, которые успели сделать коммит до начала рестарта, и теми что не успели. ARIES сначала всегда восстанавливает состояние базы до того, каким оно было перед рестартом, а лишь затем откатывает неуспешные транзакции. Такой подход позволяет значительно упростить алгоритм восстановления, особенно если первый его запуск завершился неуспешно. ARIES работает даже при множественных рестартах.

Довольно сложно найти 100% подтверждения, какие базы и когда использовали ARIES. В разных источниках к ним добавляют и Oracle DBMS, и Microsoft SQL server, и IBM DB2. Часто в документациях не пишут, что БД использует ARIES напрямую, но похожие идеи всё равно просачиваются.

ACID и ARIES.

ARIES частично связан с понятием ACID — четырьмя важными свойствами любой транзакционной системы. Поскольку ARIES отвечает за запись и восстановление, он является частью A — Atomicity и D — Durability из ACID. Опосредованно ARIES позволяет делать гранулярные локи, т.е. влияет и на I — Isolation.

Если на чистоту, акроним ACID не особо-то и удачный, в основном из-за путаницы в определениях, которую он создает. К примеру, atomicity здесь не имеет отношение к атомарным операциям в языках программирования и ОС. В ACID, A — это возможность прервать транзакции в любой момент до её полного окончания. Consistency часто не относится к самой БД, а скорее к тому, как данные внутри неё используются приложением. И уж точно consistency в БД и consistency в CAP к примеру — совершенно разные вещи. С Isolation ещё сложнее. Изоляция говорит о том, как БД работает с конкурентными операциями. Фактически, уровень изоляции задаёт, какие ошибки и ситуации можно, а какие нельзя считать корректными. Это определение очень похоже на модели консистентности, но C в ACID уже есть... Хоть c durability вроде как проблем не возникает.

Ещё одна причина, почему ACID несёт больше семантики, чем настоящего смысла заключается в том, что в БД все эти свойства обеспечиваются одновременно. Нет отдельной подсистемы, отвечающий только за durability или только за atomicity, это всё алгоритмы и структуры данных.

ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) — один из самых влиятельных и дремучих алгоритмов записи и восстановления данных. Работа (пдф) датируется 1992 годом, но похожие алгоритмы существуют примерно с 60-70-ых, когда первые базы данных только появились. Идеи из ARIES всё ещё используются повсеместно, а сама работа уже цитировалась более 1500 раз (по google scholar)! Практически любой другой труд про транзакционность или восстановление упоминает ARIES.

Авторы рассказывают не только о проблемах восстановления данных, но также о том, какое влияние алгоритм записи оказывает на возможность БД обеспечивать гранулярность локов (чем меньше данных закрывает один лок, тем больше данных можно менять параллельно), как реализовывать лишь частичный роллбек данных, что делать если процесс восстановления прервётся, и как одновременно принимать новые транзакции, пока старые ещё не восстановились. Здесь же приводится сравнение с существующими на тот момент решениями, и показывается чем они хуже. Последнюю часть я опущу, но это тоже очень любопытное чтиво. Кстати, из-за постоянных сравнений с другими базами и алгоритмами, эту работу читать очень тяжело, хотя сам алгоритм довольно простой.

Вторая-третья часть поста посвящена работе памяти и дисков в БД и подходу write-ahead logging. Само описание ARIES начинается с четвёртого поста и продолжается до конца.

ARIES (2/8)

БД с высоты птичьего полёта. Работа с памятью и диском.

Для начала несколько параграфов о том, как БД работают, если смотреть очень издалека, но чуть ближе, чем при работа с клиентами БД в языках программирования. Фундаментально БД — это точно такой же процесс или группа процессов, запущенных на операционной системе, как наши с вами любимые веб-серверы или приложения на телефоне. Распределённые БД опустим, там всё тоже самое, только в миллиард раз сложнее. Для начала про память и диск в БД, а затем как БД предотвращают потерю данных за счёт логирования.

Как и в любом другом процесс, часть данных БД находится в энергозависимой памяти, она же RAM, она же просто «память». При этом основная задача базы данных — сохранять данные в энергонезависимую память: на HDD, SDD, ленточные накопители (tape drive) в зависимости от того, что у вас там есть под рукой и какой сейчас год. Энергонезависимые устройства обычно сильно медленнее читают, и уж тем более записывают данные, чем память. Настолько медленно, что у БД нет совершенно никакой возможности транслировать запросы на чтения и записи напрямую в диск. Получается дилемма. С одной стороны, БД должна всё сохранять в диск, чтобы данные не терялись. С другой, часть данных нужно хранить в памяти, потому что диски слишком медленные. А информация из памяти пропадает сразу, как только выключается свет или умирает процесс с БД.

Самый прямолинейный выход из такой ситуации: хранить в БД буфер памяти (memory buffer), отображаемый периодически один-к-одному на диск. Решение не идеальное, поскольку объём дисков обычно многократно больше объёма памяти, всё хранить не получится. К тому же записывать и читать прямо весь буфер сразу — затратно. Не синхронизировать же в самом деле по 32+ ГБ RAM за раз. Но выход есть: хранить только какое-то количество страниц (page) в памяти. Страницы обычно делают одинакового размера — так с ними проще работать. Здесь мы исходит из предложения, что все данные разом скорее всего не нужны, поэтому можно хранить только ту часть, с которой сейчас идёт работа.

Выходит, в БД хранится некий набор страниц, отображаемых 1-к-1 на участки диска. А теперь финт ушами. Вот мы вытащили страницу из диска и храним её в памяти. Поскольку единственный способ поменять содержимое диска — записать страницу, пока этого не произошло, наша страница — это точное отображение данных на диске. И она хранится в памяти. Значит любой запрос к данным на диске можно адресовать к этой самой странице в памяти. Это от нескольких раз до нескольких порядков быстрее!

Теперь про запись. Пока данные на странице не поменялись, т.е. пока страница остаётся «чистой» — можно даже не ходить в диск, так как данные есть в памяти. Как только данные на странице поменялись, она становится «грязной» (dirty page). Такую страницу нужно запись на жёсткий диск, чтобы она снова стала чистой. Записью и чтением страниц из памяти и наоборот в БД занимается компонент под названием buffer manager (Далее — BM). Кстати, если вам кажется, что вы что-то такое про страницы и синхронизации уже слышали, то как оно и есть! Виртуальная память в ОС работает довольно похожим образом, правда у ОС не стоит задачи все данные впихнуть в диск, а ещё есть аппаратная поддержка. Тем не менее, подходы и даже терминология очень схожи.