Всем привет.

Я написал статью о том, как «за бесплатно», системными методами, сделать так, чтобы логи писали себя сами. Статья описывает как сделать так чтобы в логах отражались аргументы вызова метода и возвращаемый результат, при этом не обработанные исключения, тоже будут попадать в логи.

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

Ниже я подробно опишу применение этого способа автоматического логирования.

Всем привет.

Пару лет назад мне пришлось заняться интеграцией СБП с АБС банка, писать надо было на C#. Первое о чём я подумал, конечно, это было логирование. Писать логи руками это конечно не мой выбор. Конечно хотелось чтобы при вызове метода в логи записывались его входные аргументы и выходные результаты и конечно эксепшены.

В C#, на тот момент (конец 2023 года), для этого надо было делать обёртку над классом, пример обёртки я приведу ниже.

Всем привет! Расскажу о большом обновлении в пакете sbwerewolf/language-specific.

Для тех, кто не знаком с этим пакетом, коротко опишу его назначение.

Допустим, вы по API получили JSON с большой вложенностью, и вам нужно достать из JSON какое то значение которое зарыто поглубже. Что делать ? конечно преобразовать JSON строку в ассоциативный массив, а дальше что делать ? Конечно прописать все индексы до искомого элемента, получиться что то такое:

response["response"]["GeoObjectCollection"]["featureMember"]
[0]["GeoObject"]["metaDataProperty"]["GeocoderMetaData"]["Address"]["formatted"]
?? "Адрес не найден";

Получилась строка кода длиной 200 символов. Не очень удобное такое читать. Самое неприятное, что элемента с индексом 0 может и не быть, то есть сначала надо проверить, что он есть, а потом уже идти по массиву дальше, и каждый раз придётся приписывать весь это хвост из индексов, поэтому код будет заграмождён индексами, работать с таким кодом не удобно.

Пакет sbwerewolf/language-specific , позволяет избавить код от сплошного перечисления индексов, замороченных выражений, скобочек и операторов ??.

Казалось бы если ФИАС содержит эти данные, то просто выгрузи их ? Но не тут то было, дело в том что почтовые индексы есть у домов, но почтовых индексов нет у населённых пунктов, при этом населённые пункты через произвольное количество своёв "абстракции" связаны с домами. Эта связь записана в таблицу ADM_HIERARCHY - группировка по административному делению.

Собственно задача состоит в том что бы сгруппировать почтовые индексы всех домов и взять минимальный индекс как индекс собственно населённого пункта (индекс населённого пункта обычно заканчивается нолями, у "подчинённых" почтовых отделений индексы заканчиваются цифрами от 1 до 9).

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

О том как это сделать и решить проблему с выборкой будет эта статья-инструкция.

На виртуалке кончилось место ? Не беда, у нас виртуалка - увеличим диск. Не хотим размещать файлы на основном диске ? Не беда у нас виртуалка - добавим новый диск.

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

Эта инструкция будет о том как настроить операционную систему Ubunta, для управления новым железом (в нашем случае дисковым пространством).

Будет три части:

Как расширить раздел (увеличить диск)

Как добавить новый диск

Как создать базу данных на новом диске

Никогда не используйте MySQL, всегда используйте PostgreSQL

И вот почему, по результатам нагрузочного тестирования:

PostgreSQL в два раза меньше потребляет ресурса CPU, PostgreSQL в два раза меньше потребляет ресурса RAM, PostgreSQL в полтора раза меньше потребляет ресурса HDD (storage), PostgreSQL в три раза быстрее выполняет запросы, PostgreSQL после выполнения команды очистки (TRUNCATE TABLE) полностью очистил диск , MySQL очистил диск только наполовину.

Наверное MySQL надо уметь готовить ? Наверное. Если кто то напишет рецепт в комментариях, то благодарное человечество, в лице меня лично, скажет большое спасибо.

Одновременно с этим есть PostgreSQL, который можно не уметь готовить и иметь большую (такую же?) эффективность, стоит ли связываться с MySQL ?

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

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

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

То есть запрос вида:

select a.id from auth.public.user a join trade.public.tenders t on a.id = t.user_id;

Вызовет ошибку "[0A000] ERROR: cross-database references are not implemented".

Что делать ?

Год назад ФНС прекратила выкладывать базу ФИАС в формате DBF, теперь база доступна только в формате XML. Данные из DBF можно было вставлять в базу как есть, с XML так не получается, перед вставкой в базу, XML надо парсить, и это занимает время. Полная база ФИАС занимает 290 GB, парсинг такого объёма занимает значительное время.

Это время можно сократить, если парсинг распараллелить. Для этого надо разделить файлы на группы и каждую группу обрабатывать отдельно, но одновременно (процессоры давно многоядерные, надо не забывать этим пользоваться). Кроме того, конечно, надо использовать потоковый парсер, что бы не ждать полной загрузки файла в оперативную память.

Я разработал несколько скриптов для создания и импорта базы. Эта статья будет о том как с помощью этих скриптов развернуть базу ФИАС за 9 часов на 6-ти ядерном процессоре.

Всем привет.

Хочу поделиться с вами опытом в парсинге XML файлов размером до четырёх гигабайт. Что бы это происходило быстро, мы читаем файл последовательно, частями, парсим только нужные нам элементы.

В двух словах для быстрого парсинга файлов надо пользоваться XMLReader в связке с yield.

О моей реализации этой связки читайте ниже.

Всем привет.

Я люблю базы данных, люблю строить запросы, люблю проектировать БД. Раскладывать по полочка, систематизировать это моё любимое занятие. Конечно первые годы я проектировал таблицы БД как меня научили в ВУЗе - каждому свойству отдельная колонка.

Но этот подход отстал от жизни, то есть он удобен если ваша бизнес логика работает на хранимых процедурах. Тогда действительно, записи таблицы это готовые объекты вашей бизнес логики.

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

(Проходит год, на Хабре публикуют перевод статьи: "Пока-пока, MongoDB: почему компании переходят на PostgreSQL", ровно о том же, документарные БД легко сделать на колонке с типом JSON)

Речь конечно об Online Transaction Processing (OLTP). Когда нам надо получить данные по одной сущности, например, показать профиль пользователя, или показать товарные позиции определённого заказа.

Ниже я расскажу о продвинутом способе хранения данных.

Я разрабатываю библиотеку для работы с Entity Attribute Value (репозиторий), сокращенно EAV (структура базы данных для хранения произвольных данных). В конце прошлой статьи я спросил у вас о чём мне ещё надо написать, вы попросили показать пример использования и сделать замеры быстродействия. Про замеры быстродействия статья была, эта будет о примере использования.

Назначение библиотеки

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

Для этих двух целей применяется EAV, но он существенно замедляется при увеличении объёма данных, и главная цель библиотеки это сделать скорость работы с данными независимой от объёма данных.

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

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

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

Всем привет.

Я разрабатываю библиотеку для работы с Entity Attribute Value (репозиторий), сокращенно EAV (модель базы данных для хранения произвольных данных). В конце прошлой статьи я спросил у вас о чём мне ещё надо написать, вы попросили показать пример использования и сделать замеры быстродействия.

Что для нас важно при работе с данными ? Скорость записи (добавления или обновления) и скорость чтения (конкретно - фильтрации по моделям одной сущности). При чём скорость поиска в приоритете, потому что записываем мы один раз в цать дней, а читаем каждую минуту/секунду и даже не один раз, а может быть и не одну сотню раз.

Фишка библиотеки в том что бы работать не с представлением построенном на базовых таблицах EAV, а работать с небольшой частью этих данных записанных в отдельное материализованное представление или в отдельную таблицу.

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

Что будем измерять ?

Чтение:

Время вычитывания всех позиций категории

Время формирования параметров фильтрации

Время фильтрации

Запись:

Время добавления новой характеристики (атрибута)

Время добавления новой товарной позиции (модели)

Время обновления товарной позиции

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

XML ещё жив и иногда его приходиться парсить. Особенно если вы работаете со СМЭВ (привет всем ребятам для которых "ФОИВ" не пустой звук :) ).

Цели у такого парсинга могут быть самые разные, от банального ответа на вопрос какое пространство имён используется в xml-документе, до необходимости получить структурированное представление для документа вцелом.

Инструмент для каждой цели будет свой. Пространство имён можно найти поиском подстроки или регулярным выражением. Что бы сделать из xml-документа структурированное представление (DTO) - придётся писать парсер.

Для работы с XML в PHP есть пара встроенных классов. Это XMLReader и SimpleXMLElement.

Всем привет. Некоторое время назад пришлось разбираться в ФИАСе, хочу поделиться своими наработками. Эта статья расскажет о том как базу развернуть, как её обновлять и как ей пользоваться.

К счастью мне не пришлось во всём разбираться самому, потому что на Хабре есть хорошая серия статей о ФИАС (Адреса ФИАС в среде PostgreSQL), и у этих статей не менее ценные коменты. На их основе у меня получилось написать скрипты и написать Докер образ, всё опубликовано на ГитХабе.

Как работать с образом описано в README.md, здесь я распишу всё тоже самое но более подробно.

Всем привет.

У меня было несколько публикаций по теме Entity Attribute Value, сокращенно EAV (паттерн программирования для хранения произвольных данных). За прошедшее время я допилил библиотеку для работы с EAV, и хотел бы поделиться с вами своими наработками.

В библиотеке реализован базовый сценарий:

Всем привет.

Первые пять лет своей карьеры программиста, я работал над in-house проектом, следующие семь лет я работал в разных стартапах, с командой максимум из пяти разработчиков.

Сейчас я пару месяцев работаю над проектом где 20+ разработчиков, работа одновременно ведётся в примерно 30-ти ветках, имеется пять сред для отработки кода (драфт, дев, тестинг, хотфикс, прод), у каждой среды своя БД (перед выкаткой камита на стенд/среду, происходит проверочная выкатка с использованием отдельной БД, то есть на пять сред мы имеем 10 отдельных баз данных).

Вести разработку в нескольких ветках мне не в новинку, всегда так делал. Открытием для меня стало, то что версия кода и версия схемы базы данных ни как не синхронизируются. В маленьком проекте, не проблема дропнуть схему целиком, и целиком её накатить, это занимает считанные минуты, в этом проекте накатить схему с нуля с посевом занимает от часа.

Есть большая проблема с тем как синхронизировать версию кода и версию схемы базы данных.

Ниже я расскажу о правилах которые я принял для себя и буду рад если вы поделитесь своими приёмами и техниками, которые помогают вам справиться с этой бедой.

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

На днях расширил функционал парой методов, и хочу поделиться с вами этими новостями.

И конечно я напишу о работе над ошибками.

Постановка задачи

• аутентификация пользователей
• система хранения данных (EAV)
• редактор данных
• обработчики событий аудита
• ролевая модель для авторизации действий пользователей
• управление пользователями
• работа со справочниками

Введение