Как стать автором
Поиск
Написать публикацию
Обновить
98.75

SQL *

Формальный непроцедурный язык программирования

Сначала показывать
Период
Уровень сложности

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

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров27K

Хранение денежных сумм в базах данных и API: анализ подходов платежных систем

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

Разбираем, как решают эти проблемы Stripe, PayPal, Google Wallet и другие платежные системы. Сравниваем три основных подхода: Integer minor units, Decimal base units и String base units.

Читать далее

Новости

Изучение Python за 2 недели через боль и дедлайн: личная история

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров23K

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

Читать далее

Решаем загадку Джиндоша из Dishonored 2 на SQL перебором с возвратом

Уровень сложностиСредний
Время на прочтение18 мин
Количество просмотров16K


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

Сегодня мы рассмотрим решение непростой загадки Джиндоша из замечательной игры Dishonored 2 с помощью SQL.
SQL Может Многое!

Оптимизация SQL запросов

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров38K

Оптимизация SQL-запросов является одной из ключевых задач при работе с реляционными базами данных. Эффективные SQL-запросы позволяют значительно улучшить производительность приложений и обеспечить более быстрый доступ к данным. В данной статье мы рассмотрим как переписать запрос, чтобы выполнялся быстрее. В статье пойдет речь о PostgreSQL, хотя применять данные советы к любой базе данных SQL Ниже будут представлены термины и операторы, о которых пойдет в данной статье.

Читать про оптимизацию

Как я сделал PR на 14К строк в проект YDB будучи студентом

Время на прочтение12 мин
Количество просмотров13K

В этой статье я хотел бы рассказать о задаче, решение которой легло в основу моей дипломной работы. На момент ноября 2023 года я был студентом Физтеха — учился на базовой кафедре Яндекса, программа обучения которой реализуется совместно с ШАДом. Задача заключалась в переводе парсера языка запросов YQL (диалект SQL для YDB и YTsaurus) с ANTLR3 на ANTLR4. Мой наставник в ШАД и руководитель команды разработки клиентских библиотек YDB в Яндексе к. т. н. Алексей Мясников @asmyasnikovотметил еёе как особо сложную. Но меня это не отпугнуло:, тема работы из всех тем, предложенных в ШАД, эта показалась самой интересной и близкой мне.

Читать далее

Будущее PostgreSQL: как 64-битный счетчик транзакций решает проблему масштабирования

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров13K

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

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

Читать далее

Как небольшой команде переехать на ClickHouse: на какие грабли мы наступили и о каких фишках не знали

Уровень сложностиПростой
Время на прочтение21 мин
Количество просмотров17K

Привет, Хабр!

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

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

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

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.

Читать далее

Миграция с Firebird на PostgreSQL. Что может пойти не так? Часть 1

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров7.9K

Не секрет, что в последние годы различные компании достаточно часто принимают решение о миграции работающей информационной системы с Firebird на PostgreSQL.

Типичная ситуация выглядит так:

Проект работает несколько лет. Заказчик «верит», что проблема не в проекте, а в СУБД. Firebird — «плохая» СУБД.

Читать далее

Почему СУБД такие медленные

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров39K


Недавно на Хабре публиковался перевод статьи «Просто выберите Postgres» (оригинал, англ. яз) с аргументами, что Postgres — оптимальная БД для десктопных и мобильных приложений. Аналогичное мнение высказывают в других популярных статьях вроде «До свидания MongoDB, здравствуй PostgreSQL». Главным недостатком SQLite называют то, что данные хранятся в одном файле, а MongoDB (а также DynamoDB и Cassandra) — низкую производительность:

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

…Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных».

Более производительные резидентные БД хранят данные в памяти (Redis, Valkey), но их использование ограничено объёмом ОЗУ.

После такого заявления интересно посмотреть на независимые тесты производительности разных СУБД.
Читать дальше →

Катастрофическое падение производительности из-за hyperthreading

Время на прочтение4 мин
Количество просмотров29K

Недавно я писал статью - что такое 50% cpu? На системах с hyperthreading 50% cpu по метрикам означает, что большая часть ресурсов сервера уже использована. То есть cpu>50% - это уже "желтая зона", и мы ожидаем замедление всего, чего можно. Но я никогда не думал до экспериментов, что падение может быть столь катастрофическим.

Для экспериментов я использую MSSQL. Если вы не связаны с базами, прочитайте первую часть по диагонали до выводов.

Читать далее

Запросто собираем базу данных при помощи команд Linux

Время на прочтение6 мин
Количество просмотров14K

База данных — это сердце многих приложений, от полнофункциональных корпоративных сайтов до сравнительно простых инструментов, например, для ведения списков покупок и финансовых трекеров. Популярны реляционные базы данных на основе SQL, но в Linux можно собрать более простую и прозрачную альтернативную базу данных.

Читать далее

Ускоряем запросы в PostgreSQL, оптимизируя оператор GROUP BY

Уровень сложностиСложный
Время на прочтение9 мин
Количество просмотров20K

Пользователи PostgreSQL нередко оперируют аналитическими запросами, при выполнении которых данные сортируются и группируются по разным правилам. За счёт оптимизации вычисления агрегатов и сортировок можно значительно сократить время и стоимость выполнения запросов. Об одной из таких оптимизаций — выборе порядка колонок в выражении GROUP BY — расскажем в этой статье.

Postgres уже умеет перестраивать список группируемых выражений в соответствии с порядком колонок из условия ORDER BY, чтобы исключить дополнительную сортировку и сэкономить вычислительные ресурсы. Мы пошли дальше, реализовали свою идею в дистрибутивах Postgres Pro Standard и Enterprise и вынесли патчи на обсуждение сообщества Postgres (первое и второе) в надежде, что они войдут в ближайшую версию ванильного PostgreSQL.

Читать далее

Как не облажаться с типами данных в PostgreSQL

Уровень сложностиСредний
Время на прочтение19 мин
Количество просмотров11K

Недавно вышла отличная книга 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-запросы или просто хотите избежать неприятных грабель — стоит прочитать.

Читать далее

Ближайшие события

25 лет Firebird

Уровень сложностиСредний
Время на прочтение35 мин
Количество просмотров5K

Сегодня памятная дата — прошло 25 лет с момента начала проекта Firebird.

Напомним как это начиналось. Многие кто работает с СУБД Firebird до 2000 года скорее всего использовали СУБД InterBase, из исходных кодов которого и появился Firebird. В 2000 году компания Borland приняла решение продолжить развитие InterBase как OpenSource продукт и открыла исходные коды своей СУБД, которой на тот момент пользовалось огромное количество программистов. Планировалось, что будет создана отдельная компания InterBase Software Corporation (ISC), которая будет заниматься развитием СУБД InterBase OpenSource отдельно от Borland, но в итоге от этой идеи отказались. Поэтому появился форк InterBase 6.0, а компания ISC переродилась в IBPhoenix. Символично название проекта — Феникс, восставший из пепла InterBase.

С 31 июля 2000 начинается история СУБД Firebird. И первое с чего начался проект это было исправление багов — версия InterBase 6.0.0.627 по количеству багов могла вполне считаться пре‑релизом. Теперь все исправления легли на плечи программистов Firebird. Поэтому первый релиз вышел только в 2001 году, до этого одной из альфа‑версий Firebird 0.95 достаточно активно пользовались.

Firebird был создан как форк InterBase и как это очень часто бывает тоже стал основой для другого форка. В конце 2001 года в результате объединения усилий группы российских разработчиков, использующих InterBase на Windows, на свет появился проект Yaffil.

После выхода Firebird 1.0 к участникам проекта пришло понимание, что дальше развивать проект на языке С будет не очень удобно и возникло решение переписать проект на С++. Firebird был переписан на C++ и под версией 1.5 вышел в 2004 году.

Читать далее

Маскирование данных от А до Я

Уровень сложностиПростой
Время на прочтение14 мин
Количество просмотров7.5K

Всем привет! Меня зовут Светлана Анохина, я младший бизнес-партнёр по информационной безопасности в Ozon. Несмотря на небольшой стаж, опыт работы у меня довольно разносторонний, ведь моя роль предполагает участие практически во всех аспектах безопасности (если интересно, кто такие бизнес-партнёры по ИБ, то рекомендую почитать статьи моих коллег Даши или Максима на эту тему).

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

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

Но всё изменилось, когда я впервые устроилась работать в команду безопасности данных крупной компании. Я увидела, как это выглядит в реальной жизни: настоящие утечки, реальные данные и конкретные последствия. Тогда я осознала, что даже самая простая ошибка или недосмотр могут привести к тому, что чья-то личная информация окажется у злоумышленников, и защита данных — это не прихоть, а насущная необходимость. Каждая строка кода, каждое принятое решение могут стать барьером между безопасностью и катастрофой.

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

За время своей работы в e-commerce-компаниях я собрала некоторый перечень подходов и инструментов защиты, которые реализую в своём направлении. Сегодня я хочу рассказать о маскировании вам, моим коллегам, которые так же, как и я, стремятся сделать данные безопасными, а жизнь пользователей — спокойной.

Читать далее

Плохие JOIN’ы: приемы, которые (нечаянно) кладут прод

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров27K

Привет, Хабр!

В этой статье разбираем один из самых коварных способов убить базу — плохие JOIN'ы. Казалось бы, простое дело: связать пару таблиц — и вперёд. Но если в ON засунуть LOWER(email), забыть про индексы или перепутать LEFT JOIN с INNER — сервер мигом начнет дышать на ладан.

Читать далее

Оптимизация хранения данных в PostgreSQL

Уровень сложностиСредний
Время на прочтение39 мин
Количество просмотров17K

Всем привет. Меня зовут Сергей, я — эксперт компании Bercut. За плечами — более 20 лет работы с различными СУБД (PostgreSQL, Oracle, MS Access, MS FoxPro, Borland InterBase) и высоконагруженными системами на их основе.

В Bercut мы занимаемся разработкой и развитием IT‑продуктов, решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24×7x365 в режиме онлайн сотни миллионов абонентов.

Сегодня поговорим о том, как оптимизировать хранение данных в PostgreSQL, снизив объем дискового пространства, потребляемого таблицами и ускорить выборку данных. Это может быть особенно актуально после перевода информационной системы с другой СУБД на PostgreSQL.

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

Читать далее

PostgreSQL Antipatterns: устраняем вложенные интервалы

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров7.9K

Недавно попался на глаза запрос, которым хотели отобрать в таблице (очевидно, для последующего удаления) все id записей интервалов, которые полностью перекрыты каким-то другим интервалом того же owner'а.

Но self-JOIN показал себя не лучшим образом...

Как сделать эффективнее?

Выбор индексов в базах данных для highload-систем

Уровень сложностиСложный
Время на прочтение27 мин
Количество просмотров15K

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

Читать далее

Переливаем таблицы БД между средами: быстро и без боли на примере MS SQL

Уровень сложностиСредний
Время на прочтение21 мин
Количество просмотров7.2K

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

Меня зовут Евгений Грибков. Я ведущий программист в центре технологий VK. В этой статье мы рассмотрим одно из возможных решений создания скрипта перезаливки заданных таблиц из одной БД в другую на примере MS SQL.

Читать далее
1
23 ...

Вклад авторов