User
Меня зовут Якупов Азат, я дата-архитектор Quadcode. В индустрии я больше 20 лет, из них больше 6 лет — в архитектуре. Эта статья — немного сокращенный пересказ моего выступления на митапе по теме «Heap Table в PostgreSQL».
Речь в тексте пойдет об обычных таблицах, с которых начинается вся дата-инженерия. Посмотрим на то, как метаданные располагаются в Postgres, разберемся, что такое table page и fillfactor, а также поближе познакомимся с TOAST-таблицами.
У любого современного продукта — если он успешен — есть тот момент жизни, когда он из гадкого стартапа вдруг становится вполне себе прекрасным “энтерпрайз монолит платформ систем легаси”. Без тестов, без мониторинга, с highload и, конечно же, уймой родовых травм, вызванных быстрым развитием.
На критическую бизнес логику тесты будут написаны сами, без них никуда. Мониторинг и хайлоад — это курица и яйцо. После того, как у вас появится кто-то один из этой пары, на горизонте появится и второй. А вот все те, казалось бы, “удачные” и “быстрые” решения, заложенные при рождении, придётся исправлять. И если кодовую базу можно спокойно переписать (ну или хотя бы закидать костылями), то вот база данных — это одна сплошная горячая точка. Запросы и миграции, которые легко проходили на момент становления вашего продукта, легко могут сейчас положить прод, потому что ваша база теперь под постоянной нагрузкой, а ещё она неприлично раздулась.
Привет! Меня зовут Константин, и в Каруне я работаю backend-разработчиком. Данная статья — компиляция ряда сложностей, с которыми мы столкнулись, и методик для их решения. Вся проблема громоздких таблиц в том, что они, как визит к стоматологу — неожиданно, дорого, больно и ужасно вариативно.
Мой скрипт, с помощью которого я делаю бэкапы в Linux
Обожаю UNIX-way, тут бэкапы можно делать значительно более гибкими.
Для бэкапа home директории я использую обычный tar с инкрементацией и шифрую его своим gpg ключом.
Для других файлов, например, для бэкапов моих видео, которые я записываю для ютуба я использую rsync. RSYNC более рационально использовать, когда не критична синхронизация большого количества файлов
Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:
• состояли из 3-10 JOIN-ов по коррелирующим запросам;
• уielded от 10 до 1,000,000 строк;
• должны были выполняться в течение времени, определенного UX-ом;
• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;
• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.
Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.
У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.
Роли LSA довольно подробно разобраны в разных источниках: router LSA описывает узлы графа, network LSA предназначен для широковещательных сегментов сети, summary LSA обеспечивает взаимодействие разных зон между собой… Однако собрать эти структуры данных воедино в целостный граф кажется мне достаточно нетривиальной задачей. Безусловно, RFC является источником абсолютного знания в такого рода вопросах, но лично мне сравнительно долго не удавалось его полноценно осознать. В этой статье я хотел бы поделиться своим представлением о назначении типов LSA, а также процессом построения графа на основе LSDB.
Сегодня SQL используют уже буквально все на свете: и аналитики, и программисты, и тестировщики, и т.д. Отчасти это связано с тем, что базовые возможности этого языка легко освоить.
Однако работая с большим количеством junior-ов, мы раз от раза находим в их решениях одни и те же ошибки. Реально — иногда просто создается ощущение, что они копируют друг у друга код.
Кстати, иногда такая же участь постигает и специалистов более высокого полета.
Сегодня мы решили собрать 7 таких ошибок в одном месте, чтобы как можно меньше людей их совершали.
В моей практике ускорения SQL-запросов для PostgreSQL, в большинстве случаев, все сводится к применению типовых методик - их не особенно-то и много, и прочитать про большинство из них можно в моем профиле.
Но иногда обнаруживаются очень странные вещи в поведении этой, безусловно, отличной СУБД.
Все началось с запроса, который мне показали с диагнозом "необъяснимо тормозит"...
В комментариях к недавней статье оказалось что, во-первых, этот вопрос кому-то да и интересен, и, во-вторых, существует некоторое количество заблуждений на эту тему.
Вводные: нам нужен таймер, на Windows, с точностью порядка 1мс, драйвер при этом мы писать не хотим и решения при исполнении которых процессор попытается радикально ускорить глобальное потепление не приемлем.
Есть ли такое решение? Из коробки - нету, но при помощи нехитрых приспособлений наше досадное недоразумение превращается... в точный таймер, конечно же.
Использовать стандартные библиотеки и общеизвестные реализации алгоритмов — признак хорошего тона. Вместо изобретения своего алгоритма шифрования данных или своей хэш функции лучше взять уже готовое решение. Избегаем ошибок и не изобретаем велосипед заново. Но что если готового решения нет? В наше время это что-то невероятное. Есть github.com, есть набор платных решений.Тем интереснее обсудить необычную проблему. В данной статье расскажу о своем опыте оптимизации работы с данными, которые по своей природе представляют граф. А точнее сеть — разновидность графов.
Приветствую, меня зовут Иван, я системный администратор. Решил попробовать писать такие вот заметки на задачи, которые делаю редко, чтобы потом вспомнить, если понадобится. Надеюсь и ещё кому-то пригодится.
Все пути и имена разделов мои, меняйте соответственно на своё. Все действия на свой страх и риск, делайте бэкапы.
Задача следующая. Есть виртуалка, к ней подключен виртуальный диск, на нём система Debian 10, разметка сделана автоматически с LVM, отдельные разделы /var, /tmp, /home и т.д. Требуется расширить существующий раздел /root не добавляя дополнительный том в LVM.
(И да, если вам удобнее - есть возможность расширять разделы LVM добавляя дополнительные физически тома в группу томов, я такой способ сейчас не описываю, у меня немного другая задача).
Примитивный запрос - простой джойн и группировка. Традиционные методы оптимизации - казалось бы, что могло пойти не так?..
Небольшой эксперимент, на тему необходимости проверки любых гипотез в конкретных условиях.
Развитие происходит по спирали: когда-то люди не умели правильно индексировать, потом (в основном) научились, потом пришли noSQL и все снова забыли знание древних. Что вы будете делать, когда последние из старых DBA отплывут в Валинор?
Снова и снова и сталкиваюсь с полным набором антипаттернов индексирования. Я их перечислю, но! Для каждого антипаттерна есть исключение, когда именно это и стоит делать. Поэтому кликбейтно сформулированное правило верно в 95% случаях, но если вы хотите копнуть глубже, то прочитайте про исключения.
И в конце полезные скрипты для MSSQL, Postgres и MySQL.
В PostgreSQL есть два типа данных: JSON и JSONB. Первый формат является текстовым хранилищем, в котором json хранится "as is", второй — бинарным, в нем ключи отсортированы (сначала по длине ключа, а потом по его названию), дубликаты удалены, а пробелы удалены.
Тип JSONB имеет богатую поддержку, облегчающую работу разработчиков приложений, для него есть встроенные индексы, кроме того, существует расширение Jsquery, в котором реализован язык запросов к JSONB и дополнительные индексы. Когда у меня спрашивают, чем пользоваться, я всегда советую JSONB, так как он позволяет работать очень эффективно.
Однако у постгреса есть серьёзная проблема, которая сказывается и на производительности JSONB — это TOAST, и о ней я говорил в первой части. Сегодня я расскажу о том, как мы улучшили JSONB для того, чтобы существенно повысить его производительность.
Для систем управления бизнесом часто приходится решать очень похожий класс задач по вычислению количества уникальных объектов на произвольном временном интервале. В контексте CRM это могут быть "пользователи, обращавшиеся на горячую линию на прошлой неделе", "контрагенты, оплатившие за последние 30 дней" или "потенциальные клиенты, с кем был контакт в этом квартале".
Искать в большом количестве фактов «уники» — всегда сложно и долго, если их достаточно много. Если интервалы фиксированы (календарные месяц/квартал/год), можно материализовывать такие агрегаты заранее. А если интервал — произвольный, как тогда эффективно найти ответ?
Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это пятая статья из серии, список предыдущих статей приведен в конце в разделе 6. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Эта статья посвящена ссылкам и ссылочным типам в C++.
Термин «ссылка» широко используется и в обыденной жизни, в компьютерных и других науках и поэтому его смысл сильно зависит от контекста использования. В языках программирования под ссылкой понимают небольшой объект, главная задача которого обеспечить доступ к другому объекту, расположенному в другом месте, имеющему другой размер и т.д. Объекты ссылки удобно использовать на стеке, они легко копируются, что позволяет получить доступ к объекту, на который эта ссылка ссылается, из разных точек кода. В той или иной форме ссылки поддерживаются во всех языках программирования. В ряде языков программирования, таких как C#, Java, Pyton и многих других, ссылки, по существу, являются концептуальным ядром.
В C роль ссылок играют указатели, но работать с ними не очень удобно и в C++ появилась отдельная сущность — ссылка (reference). В C++11 ссылки получили дальнейшее развитие, появились rvalue-ссылки, универсальные (передаваемые) ссылки, которые играют ключевую роль в реализации семантики перемещения — одном из самых значительных нововведений C++11.
Итак, попробуем рассказать о ссылках в C++ максимально подробно.
Статья для тех, кто боится слова template в C++. Вводная информация с примерами и их подробным разбором.
К старту курса по разработке на Python делимся детальным руководством по работе с современным PyQt для новичков. Чтобы читать было удобнее, мы объединили несколько статей в одну:
3. Виджеты
За подробностями приглашаем под кат.