Данная статья является четвёртой частью перевода руководства по повышению производительности Firebird за авторством А.Ковязина и Э.Грегорио от 23.05.2024 (и потому продолжается сквозная нумерация пунктов), а так же текстовой расшифровкой соответствующего видео.
Ваша база данных Firebird организована таким образом, что она разделена на отдельные части, каждая из которых имеет одинаковый размер. Эти части называются страницами. Размер каждой страницы напрямую влияет на производительность базы данных и её взаимодействие с операционной системой и оборудованием компьютера. Размер страницы может варьироваться в зависимости от конкретной версии Firebird, которую вы используете.
Хранение денежных сумм в базах данных и API: анализ подходов платежных систем
Хранение денег — вещь только на первый взгляд простая, а на деле содержит множество подводных камней. Выбрав не тот тип данных, можно получить неточности в расчётах, возможна путаница при переводе суммы из одной валюты в другую. А если ещё и подключать внешние API, у каждого из которых своя точность для одних и тех же валют, уследить за совместимостью еще труднее.
Разбираем, как решают эти проблемы Stripe, PayPal, Google Wallet и другие платежные системы. Сравниваем три основных подхода: Integer minor units, Decimal base units и String base units.
В проектах по разработке ML-моделей я регулярно сталкиваюсь с тем, что значительная часть времени уходит не на саму модель, а на приведение данных в нужный формат: очистку, трансформацию, агрегацию.
Этот этап требует не только времени, но и вычислительных ресурсов, особенно когда речь идет о больших объемах информации. В этой статье я расскажу о своем небольшом исследовании DuckDB — инструменте, который может значительно упростить и ускорить работу с данными.
В статье рассматриваются особенности типов данных для хранения вещественных чисел в PostgreSQL.
Типы данных PostgreSQL для работы с вещественными числами:
1) float4, синоним real, синоним float(1..24)
2) float8, синоним float, синоним double precision, синоним float(25..53)
3) numeric синоним decimal. Диапазон для этого типа значительный: 131072 цифр до точки и 16383 цифр после точки. Но если при определении типа указать numeric(точность, масштаб), то максимальные значения точности и масштаба 1000. numeric можно объявить с отрицательным масштабом: значения могут округляться десятков, сотен, тысяч.
Кроме чисел и null поддерживаются значения Infinity, -Infinity, NaN.
Поля типов данных фиксированной длины не могут вытесняться в TOSAT-таблицу, переменной длины (numeric) могут.
float4 обеспечивает точность 6 разрядов (значащих чисел в десятичной системе счисления), float8 обеспечивает точность 15 разрядов. Последний разряд округляется:
Apache Spark — это мощный фреймворк для распределённой обработки больших объёмов данных, позволяющий выполнять сложные вычисления на кластерах компьютеров с высокой производительностью и гибкостью.
И вот 23 мая 2025 года компания Apache выпустила новую версию Spark 4.
Стоит отметить, что Apache Spark — масштабный фреймворк с широким функционалом. В данной статье я сосредоточусь на нововведениях, которые в первую очередь затронут пользователей Spark SQL и PySpark.
Недавно вышла отличная книга PostgreSQL Mistakes and How to Avoid Them от Jimmy Angelakos — системного архитектора, практика и давнего участника сообщества PostgreSQL. Книга подробно разбирает распространённые ошибки, с которыми сталкиваются разработчики и администраторы при работе с PostgreSQL, и предлагает практичные решения: от тонкостей конфигурации и миграции до антипаттернов в SQL и выбора типов данных.
Я перевёл одну из ключевых глав этой книги — про неправильное использование типов данных. В ней подробно объясняется, почему, например:
timestamp without time zone может ломать логику расчёта интервалов;
money — это не то, чем кажется (и почему он опасен);
char(n) и varchar(n) не дают ожидаемой экономии и даже вредны;
serial — это прошлый век, а identity — настоящее.
Глава будет полезна всем, кто работает с PostgreSQL в проде — особенно backend-разработчикам, независимо от языка и фреймворка. Если вы проектируете схемы БД, пишете SQL-запросы или просто хотите избежать неприятных грабель — стоит прочитать.
Меня зовут Екатерина Петрова, я автор медиа «вАЙТИ» и аналитик. Перечитывая свой любимый роман И. Ильфа и Е. Петрова «Двенадцать стульев», а именно сцену с архивариусом Коробейниковым, я вдруг поняла: его бумажный архив ордеров на имущество бывших дворян не что иное, как идеальный пример реляционной базы данных. Алфавитные указатели — это индексы, книги учета — таблицы с первичными ключами, ордера — настоящие транзакции.
Привет, Хабр! В аналитическом языке DAX одной из важных функций является SUMMARIZECOLUMNS. Эта функция готовит данные для дашбордов, также реализует декартово произведение полей группировки (если поля группировки из разных таблиц). Для понимания DAX полезно ознакомиться с особенностями SUMMARIZECOLUMNS, интересующимся деталями SUMMARIZECOLUMNS — добро пожаловать под кат :)
Современная наука невозможна без компьютерных вычислений — от обработки результатов измерений до моделирования процессов. Одним из наиболее широко используемых инструментов для вычислений в ядерной физике и физике высоких энергий является фреймворк ROOT, разрабатываемый в CERN.
Собственная архитектура e2k с очень длинной машинной командой VLIW не позволяет отечественным процессорам Эльбрус без портирования нативно запускать программное обеспечение, в том числе и ROOT.
В статье рассмотрим "айсберг" проблем, с которыми пришлось столкнуться в ходе портирования ROOT, а такжк сферу и примеры его применения.
В послевоенное советское время убивали словом, по крайней мере, так было принято в кругу друзей прекрасного поэта Шефнера. Никакой крамолы, но это только полуправда: в Люблино уже тогда куда больше ценилась финка за голенищем, но оставим былое.
Как говорят нам опытные инфоцыгане коучи в модно-стильно-молодежно снятых роликах на YouTube RuTube — сейчас время data driven подхода! А значит убивают нынче цифрой. Я, если кому-то интересно, предпочитаю, семерку, она более всего походит на старый добрый мушкет или, на крайний случай, серп.
Шутки в сторону. В современном мире, когда каждая наша «улыбка» — не более чем поток единиц и нулей, который позволяет системе распознавания лиц списать с нас 67 рублей за проезд, цифры, действительно, определяют многое. Раньше обидным было слышать про небольшой размер достоинства, теперь, у топ-менеджмента корпораций досаду, гнев и злость вызывать маленькая EBITDA или ROI. О времена! О нравы! Да простит меня Александр Сергеевич.
10 лет назад я впервые познал силу цифр. До того момента я думал, что аналитика — это красивые отчеты, за которые платят много денег западным консалтинговым компаниям ради имиджа. Функциональное назначение трудов PWC, Mckinsey и прочих сильных мира сего ограничивалось следующим: орудие для удара по голове нерадивому сотруднику, оконный ограничитель летом в душном офисе, ну и, конечно, подставка под шатающийся стул. Все. То есть совсем все. Ни разу не видел, чтобы кто-то открыл их для того, чтобы принять какое-то важное решение, по крайней мере, так не везло мне. Творцы этих шедевров: несчастные стажеры, дизайнеры и прочие ребята в красивых костюмах с очень утомленными лицами и натянутыми улыбками, за которые тогда хотя бы не списывали деньги, сами в кулуарах признавали тщетность своих мук. Впрочем, это не мешало им продолжать ночами повторять сизифов труд, чтобы потом потратить заработанное на волшебные таблетки самого разного цвета и магических свойств.
1. Тревожный звонок
Был хмурый лондонский вечер, когда в нашу скромную квартиру на Бейкер-стрит ворвался взволнованный инспектор Лестрейд.
— Холмс! Нам срочно нужна ваша помощь! — воскликнул он, сбрасывая с плеч дождевик. — В городе орудует хитрый вор. Он крадёт предметы, но уносит их только в одном рюкзаке ограниченной вместимости. Нам нужно вычислить, какие именно вещи он унесёт, чтобы максимизировать свою добычу!
Привет! Сегодня я продолжаю тему сравнения систем и движков массивных параллельных вычислений. В прошлой публикации я раскрыл основные принципы проведения тестирования, которыми руководствуется наша команда, и привел результаты как реальных промышленных сценариев, так и синтетических тестов. Материал вызвал интерес и дискуссию: значит, он актуальный и полезный. Для кого-то факты стали убедительными, а кто-то усомнился в объективности результатов, поэтому, как и было обещано, я делюсь материалами сравнительного тестирования, выполненного по общепринятому стандарту TPC-DS. Сегодня вы узнаете, повлияла ли смена методики на результаты.
Мы продолжаем свое участие в международной олимпиаде «IT-Планета». Как и в прошлые годы, проводился конкурс по SQL, состоящий из трех этапов: теоретический и практический туры, проходящие онлайн, и финальный очный тур.
В первом туре участвовало свыше 4 500 человек, из которых 245 были отобраны во второй. В этом году я занимался разработкой задач и проведением первых двух туров. Предлагаю перейти к рассмотрению задач практического этапа.
Привет, Хабр!
В этой статье разбираем один из самых коварных способов убить базу — плохие JOIN'ы. Казалось бы, простое дело: связать пару таблиц — и вперёд. Но если в ON засунуть LOWER(email), забыть про индексы или перепутать LEFT JOIN с INNER — сервер мигом начнет дышать на ладан.
pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.
Всем привет! На связи снова Илья Криволапов — системный аналитик в SENSE, где мы трудимся на проекте одного из цветных банков РФ. Работаю в профессии уже пятый год и, несмотря на мою фамилию, с продом у нас в целом тёплые отношения.
Помимо боевых задач, я преподаю курс «Хранение и обработка больших объемов данных» и за это время накопил немало практических кейсов и наблюдений. Всё это добро я решил не держать при себе и собрал самое полезное в виде ультимативного гайда по оптимизации и грамотному проектированию баз данных с расчетом на масштабирование, который сейчас публикую на Хабре.
Цикл состоит из 3 частей. В первой мы обсудили два базовых подхода к масштабированию БД: вертикальный и горизонтальный. Поговорили о плюсах, минусах и о том, как делать точно не стоит.
Во второй части – то есть сейчас – мы нырнём глубже в мир горизонтального масштабирования и разберем три первых способа шардирования: по диапазону, по хэшу и по географическим зонам. Я расскажу, как каждый из них работает, где пригодится и в каких случаях может дать сбой.
Материал по-прежнему будет полезен всем, кто заботится о «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.
Готовы продолжать? Тогда поехали!
KafkaRail гудел на фоне.
Паб The Broken Tag, где начиналось утро героев, только просыпался — запах старого эля, крошки лог‑файлов, и бильярдный стол под тусклым светом прожектора. Через узел маршрута /corp/news метропоезд пронёсся, как push‑уведомление на рассвете. День в Киберляндии начинался.
JSON откинул капюшон куртки BitStone Protocol с QR‑патчем на рукаве, кивнул Mr. Parseley и заказал, как обычно, Schema Fresca. Он прошёл к бильярдному столу английского пула, стоявшему под старым плакатом «Keep Calm and Close Tags», где RAMmy спорил с TryCatch о синтаксисе ударов.
Привет, Хабр! На связи Антон Прыгин, аналитик данных в Garage Eight. Расскажу, как с помощью простых SQL-запросов и базовых математических методов получилось построить систему ежедневного мониторинга и алертинга маркетинговых метрик, которая работает в связке с таск-трекером.
Я отчётливо помню, как сидел на втором курсе на лабах по БД и долго и мучительно методом научного тыка подбирал порядок слов в SELECT-запросе с GROUP BY, чтобы он вернул нужный мне преподу результат. Потому что я не понимал, как работает SELECT, хотя был прилежным (на программистских курсах) студентом, ходил на все лекции и делал лабы за себя и пару "тех парней".
Двадцать лет спустя, когда я встал по ту сторону баррикад и начал сам вести лабы по БД, я столкнулся с той же самой проблемой уже у своих студентов. И, так как за двадцать лет я всё-таки понял, как работает SELECT, то придумал для них способ объяснения, который работает хорошо (в моей практике).
