dev notes

2020-12-12 06:23:42 Как при анализе файла восхититься сортировкой, философией Unix и понять, где украл идеи пресловутый Agile

10-ая глава "Высоконагруженных приложений", помимо всего прочего, начинается с небольшого примера анализа файлов в Linux. Анализируем - стандартный nginx-лог файл:

cat /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -r -n | head -n 5

"На выходе получаем 5 самых запрашиваемых сайтов нашего веб-сервера" - говорит автор. Ради эксперимента подключился к рабочему ssh, выдал этой цепочке команд лог на 4гб - молниеносно получил ответ: 5 строк, на каждой сайт и цифра слева от него - число запросов, отсортированных в порядке убывания. Далее Клеппман описывает, почему ответ при анализе нескольких Гб получается так быстро, и резюмируя, вот почему:

Каждая из этих утилит в Linux выполняет ровно одну функцию, и выполняет её удивительно хорошо. Например, sort под капотом автоматически обрабатывает данные большого размера, умеет записывать их на диск, оптимизировать различными структурами и параллелить сортировку там, где это нужно по нескольким ядрам процессора. Всё это - следствие философии Unix.

Что такое философия Unix? Это набор правил, описанных сообществом разработки и пользователей Unix в 1978 году:
1. Каждая программа - делает что-то одно, но делает это хорошо. Для решения новой задачи напишите новую программу, а не усложняйте старую.
2. Выходные данные каждой программы могут быть входными следующей, которая заранее неизвестна. Не засоряйте выходные данные, возвращайте атомарные и чистые результаты.
3. Проектируйте и разрабатывайте программное обеспечиние, даже операционные системы, так, чтобы протестировать их можно было как можно раньше, в идеале - за пару недель. Если какая-либо часть ПО написана плохо - без колебаний выбрасывайте её и переписывайте.
4. Чтобы упростить программирование - используйте инструменты, вместо неквалифицированной помощи, даже если для их создания приходится отвлечься от разработки основной задачи, а впоследствии - отказаться от некоторых из них.

Ничего не напоминает? Автоматизация, быстрое прототипирование, инкрементная итерация, поощерение экспериментов, разбивка крупных проектов на управляемые блоки - привет, современный Agile. Теперь понятно, кем вдохновлялись ребята, подписывая Agile-манифест в 90-ых годах. Удивительно мало изменений за 40 лет. Открыть/Комментировать

2020-12-06 10:51:38 По моему опыту - многие не понимают, зачем нужны хранимые процедуры. Вот есть они, можно туда какой-то код унести, а зачем это всё?
Кто-то переписывает на них весь backend, ловя потом сотни ошибок (https://habr.com/ru/company/lingualeo/blog/515530/), кто-то использует их не по назначению, а кто-то не использует совсем.
И я тоже не понимал, где их можно применять, а сегодня как понял.
Клеппман в "Высоконагруженные приложения" приводит отличный пример их применения, и я попробую его кратко резюмировать:

Есть огромное количество ошибок, связанных с состоянием гонки в различных СУБД: грязное чтения и грязная запись, потерянное обновление, фантомные записи.
Всё это происходит из-за того, что 2 транзакции в конкурентном режиме, очень условно говоря - параллельно, выполняют запросы над одним объектом.
Как этого избежать?

Лет 30 назад умные ребята предложили избавиться от конкурентности и пускать всё в одном потоке, а все транзакции хранить в оперативной памяти и, очень быстро их оттуда доставая, применять.
Лет 15 назад оперативная память стала стоить настолько дешёво, что это удалось реализовать.

Но тут встал другой вопрос: часто сервера базы данных и сервера приложения физически располагаются в разных местах.
Приложение формирует запрос, скажем, включив туда 1.000.000 id пользователей, и отправляет эту огромную строку на сервер СУБД, где СУБД в однопоточном режиме пытается её считать, а потом применить.
Приём и передача данных по сети становится серьёзной проблемой, сильно аффектит скорость и выполнение в одном потоке становится невозможным.
Тут и приходят на помощь хранимки - формирование запроса можно унести в СУБД, а по сети передать только вызов хранимой процедуры из пары строк.

Таким образом: мы избавились от проблем конкурентного доступа и более-менее наладили скорость.

Сегодня несколько СУБД позволяют работать в таком режиме, одна из них, о которой ты скорее всего слышал - Redis. Но, надо помнить, что хранимки таят много проблем, которые нужно учитывать прежде чем применять такой радикальных подход.

На сегодня всё, мир Открыть/Комментировать

2020-12-05 08:35:04 ​​Книга "Высоконагруженные приложения: программирование, масштабирование, поддержка" Мартина Клеппмана оказалась скорее справочником, чем линейным пособием для изучения.
Много, нет, ОЧЕНЬ МНОГО сложных технических моментов, порой с переходом в математические абстракции, да так, что у меня флешбеки с универа начинали пролетать.
Некоторые главы главы забросил на середине, некоторые наоборот - читаются с огромным интересом за один подход.
Учитывая бэкграунд автора в Кэмбридже, литература у него получается вполне себе университетская :) Но, дочитаю обязательно. И, вероятно, некоторые главы буду
перечитывать второй раз уже с ручкой, чтобы лучше усвоить информацию.

А в качестве бонуса вот тебе список из 4-х пунктов, старательно собранных в первой половине книги, и объясняющих, почему стоит забыть MySQL в пользу других реляционных баз данных:
1. Большинство реляционных БД выполняют оператор ALTER TABLE за доли секунд, работая с указателями.
MySQL - полностью копирует таблицу, изменяет её, и записывает назад, что порой занимает несколько часов.

2. Репликация - мастхэв для больших проектов, и вероятно у тебя на проекте есть что-то подобное.
Так вот MySQL не умеет делать снимок состояния ведущего узла, а многие другие СУБД, например Postgres, - умеют.

3. Изоляция снимков состояния - тема, которая, вероятно, много раз спасала твою задницу от ошибок, а ты об этом даже не знал, потому что эта технология поддерживается автоматически
некоторыми СУБД. Но если из MySQL убрать подсистему хранения InnoDB - MySQL и тут ничего не сможет.

4. Есть такой приятный механизм - автоматическое обнаружение потери обновлений. Это когда 2 процесса в один момент прочитали из базы, а затем, например, делают инкримент прочитанного значения.
Один сделал быстрее, второй - медленнее. И второй перетёр то, что записал первый, таким образом мы увеличили значение не на 2, а на 1.
Postgres и другие умные пацаны умеют решать такие проблемы автоматом: они повторяют цикл чтения - записи и не теряют обновления. А MySQL что? Правильно, а MySQL не умеет.

Чем этот список полезен? Ну, во-первых, у меня как-то проект прогорел из-за того, что MySQL не справлялся с данными и ALERT TABLE вешал таблицу на пару часов. Во-вторых, многие (например S7)
спрашивают на собесе, чем плох MySQL. Полезно подготовиться и набросать так, чтобы после этого вопроса тебя сразу взяли :D

Вообще, автор не очень жалует MySQL, так что к концу книги, думаю, найдётся ещё пара-тройка пунктов, почему MySQL - не тру, которыми я обязательно поделюсь. Открыть/Комментировать

2020-11-26 21:38:33 PHP 8.0 релизнут!

https://www.php.net/releases/8.0/ru.php?lang=ru

Основные изменения:

• Именованные аргументы
• Атрибуты
• Объединенные типы
• Объявление свойств в конструкторе
• Выражение match
• Оператор nullsafe
• Улучшенное сравнение строк и чисел
• Ошибки согласованности типов для встроенных функций
• JIT

В релизе еще много других фич, а также улучшений синтаксиса, консистентности и обработки ошибок.

Подробно: php.watch/versions/8.0
Видео на русском: обзор Валентина Удальцова
Полный список изменений: php-8.0.0/UPGRADING Открыть/Комментировать

2020-11-19 06:10:59 ​​Пока мы ждём релиз PHP 8, перевёл для вас небольшую статью о том, почему объявление свойств в конструкторе - круто, удобно и заслуживает внимания - itxor.info/constructor-property-promotion Открыть/Комментировать

2020-11-13 07:05:04 Стрим с PHP-митапа Нижнего Новгорода

- 14 ноября (суббота)
- Старт в 11:00
- Пройдет по ссылке

3 доклада: про MySQL vs Postgres, причины успеха пхп-проектов и полезные привычки программистов.

Можно будет включиться в эфир текстом или голосом из браузера, а еще сыграть в квиз (и даже выиграть билет на PHP Russia или лицензию от JetBrains). Подробнее о митапе Открыть/Комментировать

2020-11-11 17:58:35 Ребята из ВКонтакте заопенсорсили свой компилятор — KPHP. Как и 6 лет назад.

Разработчики рассказывают, что он долгое время не развивался, а 2 года назад его решили возродить. Успели сделать кучу всего — догнать синтаксис современного PHP (приблизительно на уровне PHP 7.2), покрыть ООП и даже плагин для PhpStorm написать. На синтетических тестах KPHP быстрее PHP 7.4 в 5–7 раз.

При этом ребята открыто признаются, что "в бою" вне ВКонтакте он всё ещё неприменим, потому что поддерживает только ВК-шные движки, а стандартные базы данных им никогда не были нужны. Но планируют развивать это направление, чтобы KPHP стал полезным инструментом и вне VK.

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

https://habr.com/ru/company/vk/blog/527420/ Открыть/Комментировать

2020-11-06 06:07:58 ​​Читаю книгу Мартина Клеппмана "Высоконагруженные приложения. Программирование, масштабирование, поддержка" и решил поделится интересными выводами, которые лично у меня структурировали знания о том, как и в какой ситуации выбирать СУБД для проекта или задачи.

Если модель данных подразумевает небольшое количество связей один-ко-многим (или большое, но логика приложения подразумевает, что документ загружается сразу, без или с минимальным количеством дополнительных запросов) - можно рассмотреть документоориентированные СУБД, где на хайпе до сих пор MongoDB. Ключевое слово тут - небольшое, потому что Mongo будет дублировать данные, из-за чего база будет денормализованной. Например, храним мы документы с пользователями, где к каждому пользователю опционально привязаны машины, которыми он пользуется, если они у него есть. Маловероятно, что у пользователя может быть большое количество машин, поэтому сохранить машины в документе, обернув их в json - может быть неплохой идеей. Дублировать нам придётся машины, потому что ссылаться на тачку, которая добавлена где-то в другом документе мы не можем так же, как можем это делать в реляционных базах, только искусственно. Если модель данных в принципе не подразумевает связей один-ко-многим, то документы - отличный выбор.
Тем не менее, развитие NoSQL породило множество СУБД, некоторые из которых, например, пытаются решить проблему ссылок и тем самым показать, что их можно использовать для большого количества связей один-ко-многим, например - RethinkDB и некоторые драйверы для MongoDB.

Если же связей один-ко-многим у нас много, но при этом немного связей многие-ко-многим, отличный выбор реляционные СУБД. Из-за встроенного механизма ссылок и индексов поиск будет быстрее; внутренний оптимизатор, реализованный в реляционных СУБД, отработает гораздо эффективнее и раскидает запросы лучше, чем если бы мы это делали руками в документоориентированных базах.

Если же проект подразумевает большое количество связей многие-ко-многим - стоит посмотреть в сторону графовых баз данных, потому что большое количество связей хорошо ложится на графовую модель. Реляционная база тоже позволит хранить такие данные, но работать с ними будет гораздо сложнее, и в книге приводятся несколько сравнений запросов для одной и той же схемы данных в графовом представлении и в реляционном: запрос, занимающий 2-3 строчки в графовой модели может занять 20-25 в реляционной.

Конечно, это очень общее и поверхностное описание, и стоит учитывать множество других моментов, например важен ли контроль схемы данных на стороне СУБД, как часто будут меняться данные, какой объём данных обрабатывается и как. Но в общем и целом, как первичные маркеры для выбора - подходит. Открыть/Комментировать

2020-11-01 16:35:59 Кто из нас не любит сюрпризы? :) Вот и я люблю. Сегодня встретил 2 ошибки, которые едва не поломали прод - благо, успели вовремя отменить деплой и исправить. Теперь о том, что никогда нельзя делать:

1. Переопределение стандартного geter'а в сущности и использование в нём инициализированного по-умолчанию параметра. Я много читал о том, как кто-то попадал на большие суммы из-за ошибок с копейками и рублями. И сегодня чуть не попал сам: когда-то давно в одной из сущностей по неизвестной мне причине добавили в один из get-методов параметр, по-умолчанию равный true. Если он равен true - внутри метода подразумевается возврат значения. Если false - деление значения на 100 и возврат результата. true - работа с копейками, false - с рублями. Затем по-историческим причинам этот метод везде вызывался с параметром false, чего я конечно же не знал. Если бы не успели исправить - это бы привело к ошибке у огромного количества пользователей, и ошибка связана с суммами. Добавлять такие параметры - точно не нужно :)

2. Пустая строка в конце crontab файла. Раньше я не знал, что crontab -e всегда добавляет в конце файла пустую строку, а если же её не добавить - будет ошибка во время попытки запустить задания. IDE автоматом отформатировала код и убрала пустую строку, затем код через CI/CD улетел в crontab-конфигурацию и весело выбросил ошибку, чуть не поломав деплой.

Вот такие вот интересные баги :) Открыть/Комментировать

2020-10-30 19:25:13 ​​Нашёл сайт, где можно попробовать все фишки грядущего PHP 8 - https://pociot.dev/32-php-8-try-out-all-new-features

Каждая фича кратко описана, ссылаясь на соответствующий RFC, и ниже представлен редактор кода, где реализован пример её использования, который можно запустить! Наглядно и круто, заходи и оценивай :) Открыть/Комментировать