А вы кэш почистили?

Давайте поговорим о кэшах, а то сколько можно терпеть тормоза этой базы😂

Помню, как в детстве, когда находил мамин тайник с конфетами, брал от туда конфет больше, чем нужно на одно чаепитие. Походу я уже тогда научился кэшировать 😁 Принцип простой: сохранить что-то важное поближе, чтобы быстрее к нему добраться.

Зачем это нужно?
Без кэширования каждый запрос к вашему веб-сайту или приложению требует времени и ресурсов для обработки. Это может быть не заметно, когда у вас пара пользователей, но когда их тысячи? Вот тут без кэша не обойтись. Туже самую сессию проверять надо очень часто и у всех, так какой смысл базу грузить постоянно.

Как это работает?
Допустим, вы запрашиваете страницу со списком последних новостей. В первый раз сервер обработает запрос, извлечет данные и вернет их вам. Но он также сохранит копию этих данных в кэше. Когда следующий пользователь запросит ту же страницу, сервер вместо обработки запроса с нуля просто выдаст копию из кэша. Быстро и эффективно.

Кроме такой схемы есть и другие. Можно помещать данные в кэш при записи, а не при чтении. К тому же важно подумать и политиках вытеснения данных из кэша и времени жизни.

Типы кэширования:
1. Кэширование на стороне клиента: когда данные сохраняются прямо в вашем браузере.
2. Кэширование на стороне сервера: когда данные хранятся на сервере или специальном кэширующем устройстве.
3. CDN (Сеть доставки содержимого): когда кэшируются статические ресурсы типа картинок, видосов или CSS файлов на распределенных серверах.

Почему это важно?
Без кэширования ваш сервер может стать узким местом, не способным обрабатывать все запросы. Это как попытаться налить воду из шланга в бутылку: если давление слишком велико, вода просто разольется. Вспоминая, как мы с батей бак в огороде набирали, могу увернно сказать, что эта вода ещё и вас обольет с ног до головы)))

P.S. На фото закэшированная версия меня. Сейчас то я уже веселый и отдохнувший:)

А вы чем баловались в кэшировании? Redis или что-то другое?

У нас прод упал, не поможете?

Был у меня период, когда я жил в Казахстане. Любовался горами Алматы и наслаждался местной кухней. И вот однажды произошел забавный слачай с моим соседом.

Он зашёл на сайт какого-то небольшого интернет-магазина и хотел сделать заказ. Заказ создался, деньги списались, но подтверждения, что заказ принят не последовало. Сосед решил позвонить в службу поддержки и узнать как там дела с заказом. Когда он дозвонился до них оказалось, что продакшн их сайта решил полежать😂 Сапорты сказали, что надо будет подождать.

Что было дальше я точно не помню, но он как-то сказал сапортам, что он программист, а те без коллебаний предложили ему помочь поднять их прод😂 После этого они скинули ему контакты их единственного программиста) Мы угорая от происходящего готовы были погрузится в код, но кто-то в управлении одумался. Неожиданно пришло осознание, что пускать рандомного чувака в свою систему такая себе идея😅 А мы то думали, что сейчас скидочку намутим)

Желаю вам видеть свой прод исключительно в стоячем состоянии!

Занятное дело:) Мне тут сейчас один человек написал благодарственные слова за курс и попутно признался, что спиратил его. А затем накинул вопросов, чтоб я ему помог с чем-то разобраться🤯

Я может чего не понимаю, но кажется это перебор) Сперва берешь без спросу, а потом ждешь хорошего отношения и задаешь вопросы:)

Что думаете?)

P.S. Сообщеньку он дропнул, даже заскринить не успел:(

Сегодня решил поразгонять про базы данных. Начнём с описания существующих видов.

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

Реляционные базы данных (RDBMS) используют табличный формат для организации данных. Они поддерживают операции SQL для запросов и обладают сильной схемой данных. Примеры включают PostgreSQL и MySQL. Они идеально подходят для сложных запросов и транзакций. ACID все дела.

Нереляционные базы данных (NoSQL) предлагают гибкость в хранении данных, не требуя строгой схемы. Они ещё и разные бывают:

* Документо-ориентированные базы данных (например, MongoDB), хранящие данные в формате JSON или XML. Они хороши для работы с иерархическими данными и JSON-структурами.
* Ключ-значение хранилища (например, Redis) предлагают простоту и скорость за счет хранения данных в парах ключ-значение. Они отлично подходят для кэширования и сессий.
* Колоночные базы данных (например, Clickhouse) поддерживают большие объемы данных, распределенные по множеству машин. Используются для больших, масштабируемых приложений.
* Графовые базы данных (например, Neo4j) сосредоточены на отношениях между объектами. Они идеальны для анализа связей, таких как социальные сети.

Базы данных временных рядов (например, InfluxDB) оптимизированы для хранения и анализа последовательностей данных во времени. Они подходят для мониторинга приложений, IoT и аналитики.

Выбор базы данных зависит от требований проекта, объема данных, необходимости масштабирования и типа хранимой информации.

P.S. На фотке я очевидно вспомнил историю знакомого из вк про neo4j и взглядом выражаю сочувствие:) как им было больно с ней работать даже слушать было грустно😁

Что из этого вам приходилось юзать? Что-то экзотическое было?

Вернемся к базам

Последнее время работа и всякие выступления захватили мое время и не удавалось сюда ничего написать( Буду исправлять

В прошлый раз я широким мазком накинул про разные виды баз данных, а сегодня углубимся в один из видов - реляционки. Почти всегда жизнь сводила меня с Postgres, так что буду ссылаться на него)

Реляционки это базы, в которых данные лежат в виде табличек, которые могут иметь какие-то отношения, но не половые😂 конечно в тот же постгрес завезли возможность хранить неструктурированные данные, но это уже для зумеров) Дефолтно были таблички)

Реляционки по кайфу юзать, когда данные имеют четкую схему, которая часто меняться не будет и сущности переплетены связями:) Например, хранишь ты в одной табличке юзеров, в другой список чатов, а в третей инфу о том, кто в каком чате сидит:)

Еще крутая фича у таких баз - это транзакции и поддержка ACID. И нет это не кислотная вечеринка, это механизм которые помогает бабки у вас на счету сохранить:)

Сидишь ты такой зпкшки с двух работ ждешь и тут бац банк события об обоих зпешках одновременно получает. В двух запросах берет баланс и накидывает по зпешке. И вот когда транзакций нет, он тебе только одну зпешку начислит, а вторую себе оставит😂 Ибо прибавит то к изначальному балансу, а то что параллельно еще начисления иду и невдомек)

Транзакции также могут обеспечить целостность данных. Например, надо тебе две операции провернуть с базой атомарно, чтоб ничего не разломало. Берешь транзакцию и кайфуешь. Там либо обе выполнятся корректно, либо ни одна :)

Был у меня как-то забавный момент с постгресом. Перед базой обычно ставят пуллер конектов, чтобы на каждый запрос соединение не плодить. Этот пуллер держит штук 20 конектов открытых и перешаривает между запросами из сервиса) И вот я как-то навалил в прод кода, где забыл возвращать конект в пул после запроса) В итоге после 20го дерганья ручки она переставала работать😂 конекты тупо заканчивались в пуле( Я тогда не один час потратил на поиски проблемы, ибо ошибка была не информативной) так что будьте внимательны)

Пост лимиты имеет, всего и не впихнёшь о реляционках, поэтому поделитесь чего хорошего вы в них видите:)

Вы хотели новостей с курса, я принёт) а в следующем посте поговорим о уровнях транзакции в бдшках

Вчера стартовала 4-я неделя курса, уже почти половина прошла. Прогресс ребят можете видеть на картинке.

За это время:
- Мы три раза созванивались на 2 часа, чтоб обсудить все вопросики
- Я проверил почти 40 пул реквестов и записал дофига голосовых ахаха
- Один человек ушёл в академ и вернется на курс в следующем потоке, так как сейчас резко возник дефицит времени
- Один человек вернул курс, так как резко понадобились деньги. Я даже специально уточнил не говно ли мой курс на его вкус. Сказал всё чётко, просто бабло понадобилось

В целом всё идёт своим чередом. Код пилится, ребята учатся. В чатике очень крутая активность, друг другу помогают и всё такое. Я вроде тоже не особо устал проверять домашки, так что 20 человек с проверкой вполне норм темп получается. В понедельник у нас будет созвончик с Любой, которая расскажи об ошибках в составлении резюмешек на примере резюмех некоторых ребят с курса. Думаю будет весело и полезно.

Если у вас есть какие-то вопросики о том что и как у нас проходит, то задавайте, а то сложно прикинуть, что вам интересно узнать)

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

Время поговорить об уровнях изоляции транзакций в реляционках. Удобнее всего разложить за эти уровни на примере бабла и то, как вы можете его потерять, если выберете не тот уровень изоляции.

Для начало небольшой ликбез. Транзакция это набор действий, которые выполняются атомарно, то есть либо все, либо никто. Когда транзакция заканчивается успешно, внесенные ею изменения фиксируются операцией комит. А если всё пошло по бороде, тогда вызывается ролбек и всё откатывает.

А теперь к уровням. Сегодня начнём с самого мягкого и безумного.

READ UNCOMMITTED (Чтение незакомиченых данных)

Есть у меня корефан Лёха и как-то раз он решил перевести своей подружане Маше 100$. Вспомнил, что SWIFT не работает и пошёл искать рублёвую копилку))) Найдя, он наконец то закинул Маше перевод.

Но всё было не так-то просто. Маша уже увидела, как баланс пополнился лёхиными деньгами и побежала делать покупки, но транзакция ещё не завершилась - ну вы знаете эти банки))) И пока Маша заказывала себе новую книженцию по Go, Лёхин банк лаганул и отменил транзакцию аккурат в момент, когда Маша платила за книгу. И в итоге у неё возник отрицательны баланс.

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

Кстати, в postgres этот уровень отключен к чертям. Видать создатели не любят ЗП раньше времени получать.

А вы когда нить юзали это уровень в проектах?

Что делать, если случайно удалил свой код, который долго писал?

Недельку назад я делал очередную таску на работе, долго писал рутинный код и часика через 3-4 закончил это дело. В этот момент серверная версия ветки обновилась перед тем, как я запушил. Поэтому мне нужно было стянуть изменения с сервака, смерджить со своими и пушить. Я уж не помню что я сделал, чисто на автомате тыкал, но я затер локальную ветку серверной и все мои старания пошли лесом.

Сперва я естественно покричал в стенку ахахха Думал уже начинать всё заново писать, но неожиданно вспомнил... В гите же ничего просто так не удаляется сразу. Гугланул как называется команда, которая сможет обернуть время вспять и моё душевное спокойствие было восстановлено))

А теперь небольшая инструкция для тех, у кого кот бегает по клаве или руки кривые, как у меня😂
Есть такая кайфовая команда git reflog. Она покажет вам список всех ваших коммитом, даже тех что вы дропнули. Ищите желанный коммит и прыгаете на него по хэшу - git checkout <sha value>

Тут можно подробнее почитать: https://rewind.com/blog/how-to-restore-deleted-branch-commit-git-reflog

А вы так когда-нить спасали свой код?

P.S. Задний фон на фотке иллюстрирует мою любовь к этой команде аххаха

Погнали в Авито работать?

Я тут регулярно вкидываю, что мне работа ща по кайфу идёт и тут у вас варик возник попробовать побыстрому залететь в Авито. Если всё выгорит, то будете обмазываться кайфовыми процессами и общаться с интересными людьми.

13 и 14 апреля намечается Weekend Offer для Go-разработчиков.
Флоу такой:
* Подаёте заявку до 11 апреля
* Решаете тест до 12 апреля
* Проходите телефонное интервью до 12 апреля
* Проходите собеседования онлайн
* Получаете оффер
* Кайфуете!

Регаться и узнать детали можно тут -> Weekend Offer от Avito

P.S. Если есть вопросы пишите)

ГДЕ МОИ ДЕНЬГИ, POSTGRES?

Слушайте, вот вам казус из жизни. Хотел я тут заплатить за аренду квартиры. Переважу лавеху арендодателю, Михал Степанычу. Вроде всё просто, но есть нюанс. Давайте обкашляем вопросики с точки зрения базы данных.

Напомню, что в мире баз данных транзакция — это не просто перевод денег, это целая цепочка операций, которая может включать в себя несколько шагов. Если всё идёт гладко, транзакция завершается операцией комит, и ваши изменения остаются в системе навсегда. А если что-то идёт не так? Тогда надо откатываться операцией ролбек.

Так вот, есть такой уровень изоляции транзакций как READ COMMITTED. Он часто юзается многими бдшками по умолчанию. Под этим уровнем, данные, которые вы читаете в рамках транзакции, уже должны быть закомичены. Иными словами, вы НЕ увидите изменений, пока они официально не войдут в базу данных, через операцию коммит.

Вернёмся к оплате за хату. Пока я переводил кровно заработанные деньги Степанычу, он уже начал их тратить. Я хз, может он шопоголик или что похуже, но прекол вот в чём. Когда он собрался сливать бабки, он уже расчитывал на то, что деньги от меня до него долетели, но транзакция чё-то подвисла и ещё не успела закоммититься. По итогу, купить он ничего не смог, так как его транзакция видела лишь старый баланс, где был шишь без масла ахах и это хорошо, потому что предотвращает ряд возможных проблем, типа тех, что случились с Машей из предыдущей истории. Степаныч в кой века в долги не залезат благодаря рид комитеду)))

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

А как вы платите за аренду хаты налом или мутите мутки со своим Степаныче по сети? ахаха

P.S. Шлем надел для безопасности, а то говорят же, что надо заботится о безопасности при разработке!)

ГДЕ МОЙ СТОЛИК, REPEATABLE READ?

Вы же знаете секрет успеха с девушкой? Её надо накормить, а то будет злая и ты резко из нормального парня рискуешь стать бесячим объектом ахахах Стало быть надо бронирования столика в каком-нить заведении. И всё кажется довольно обыденно, пара кликов и столик твой, ноооооо есть нюанс😂

Твою бронь ж надо положить в базу, а то забуд все про тебя. А в базах опять эти транзакции. Надо ж как-то обесопасить рестик от ситуации, когда один и тот же стол бронят несколько человек. А то приходишь на ужин, а там вместо любимой девушки, питонист сидит😨

У транзакции обычно есть два стула или всё приходит идеально, или ничего не выходит. Если всё идёт по плану, транзакция фиксируется операцией коммит, и изменения становятся постоянными. Если что-то идёт не так — в игру вступает ролбек, и всё возвращается на свои места.

На уровне изоляции REPEATABLE READ каждый раз, когда вы запрашиваете данные в рамках одной транзакции, они остаются неизменными, независимо от того, что происходит снаружи этой транзакции.

Хотел я как-то забронировать столик в модном заведении. Открыл приложение, выбрал столик у окна, который был свободен, и перешёл к бронированию. А по сторонам гляжу, стоит рядом зумерок и бронит тот же столик, паразит. Я уж право дело думал система то тупанёт и едовать еду буду с ним. Но нет!

Благодаря уровню изоляции REPEATABLE READ, моя сессия "запомнила" информацию о том, что столик был свободен в момент начала моей транзакции. И пока я завершал бронирование, для меня столик оставался доступным, несмотря на попытки других клиентов его занять. Я успешно завершил бронь, и когда я закончил, система уже показывала следующим клиентам, что столик занят.

Этот уровень изоляции защищает от "неповторяемого чтения", когда данные изменяются другими операциями в базе данных во время вашей транзакции. Таким образом, вы получаете стабильный и предсказуемый результат.

Однако у уровня изоляции REPEATABLE READ и проблем хватает:

Проблема блокировок и долгое выполнение транзакций
REPEATABLE READ удерживает же блокировку на прочитанные данные до конца транзакции, стало быть все остальные запросы, кто хочет эти данные почитать тупо заблочены и ждут. А значит и время ответа в таких запросах будет расти, что конечно печально.

Потенциальные deadlock'и
Ну это классика, когда логики наворатили кучу и получилось, что первая транзакция заблочила вторую, а вторая первую и всё, шах и мат постгресмены ахахах Хлопот новых прибавится в миг.

Увеличение сложности управления
Про дополнительные хлопоты я уже говорил. С таким уровнем изоляции надо заранее подумать о подводных камнях и всяких внештатных ситуациях. Ну и на проде потом сидеть и ловить какие-нить приколы типо дедлоков.

Тем не менее, несмотря на эти сложности, уровень изоляции REPEATABLE READ помог миллениалам вновь победить зумеров и забронить столик ахахаха

Юзаете этот уровень изоляции или рид комитедов обходитесь?

P.S. Судя по фотке выше я таки ничего не забронил)))

Сегодня в 19мск мутим стрим, подключайтесь:)

Начинаем прямой эфир:)
Комменты и вопросы пишите в комменты к этому посту:)

Расскажу вам чего-нить занятного о разработке, новостях курса, психологии и просто поотвечаю на вопросы:) Короч, как обычно, наимпровизируем чего-нить:) Сегодня уличный стрим, я тут в парке тусую) Надеюсь инет не лаганет)