Базы данных *

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

Хотя, подобные решения, не всегда хороши. В отличие от обыкновенных цифровых значений, которые легко кешировать и сортировать, UUID не так гибки в использовании. UUID версии 7 предназначен как раз для того, чтобы разобраться с подобными проблемами.

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

Чтобы мониторить сеть и сервера, можно использовать самый разный софт. Главное — быть уверенным: если что-то пойдет не так, то сработает алерт. Вы увидите уведомление и успеете все починить. У них же было свое представление о мониторинге. Представьте, несколько комнат со столами, стульями и огромными плазмами на стенах, внутри сидят почти два десятка человек. На каждый монитор выведены разноцветные графики и рядом приклеены бумажки с номерами телефонов.

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

Покупка компании обошлась недорого, но содержание такой инфраструктуры стоило заоблачных денег. Индусы использовали дорогущую Vertica, где, кроме оплаты железа, нужно было еще отстегивать за лицензию. Мы решили попробовать переезд на ClickHouse. Это практически бесплатный аналог Vertica. Оба продукта работают по схожему принципу: колоночное СУБД с шардированием, с партиционированием данных.

И это было то еще приключение.

Привет, Хабр! Приглашаем на бесплатный Demo-урок «Параллельный кластер CockroachDB», который пройдёт в рамках курса «PostgreSQL». Также публикуем перевод статьи Тома Брауна — Principal Systems Engineer at EnterpriseDB.

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

Добрый день. Прошло уже 2 года с момента написания последней статьи про парсинг Хабра, и некоторые моменты изменились.

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

В прошлой статье мы оптимизировали поиск в PostgreSQL стандартными средствами. В этой статье мы продолжим оптимизацию с помощью индекса RUM и проанализируем его плюсы и минусы в сравнении с GIN.

Выбираете между Tarantool и Redis или между Tarantool и Memcached? Давайте рассмотрим основные различия, чтобы вам легче было определиться.

• купить еще один такой же винчестер и объединить их в raid-0.
• купить небольшой SSD и организовать на нем быстрый кэш:
  
  • dm-cache. Был добавлен в ядро 3.9, ставится просто.
  • bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
  • EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании.

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

Да, здесь есть нюанс. Об этом нюансе, а также о том, зачем я написал в пятый раз кастомный ORM и будет эта статья. Эта разработка тесно переплетена с моей личной историей, когда я переходил с одной работы на другую, а затем был уволен. Я не хочу оставлять сухой технический текст, поэтому эта статья будет скорее рассказом моей работе в этой компании.

Код в статью я старался включать по минимуму. Он точно не полный и возможно ошибочный, потому что дорабатывался по мере написания статьи. Полный и исправленный вариант будет доступен по ссылке в конце статьи.

Меня зовут Олег, и в Яндексе мы с командой занимаемся Python-обвязкой вокруг нашей базы данных YDB. Python знаменит «батарейками в комплекте», широким ассортиментом библиотек на все случаи жизни, включая богатую экосистему для работы с базами данных. Есть свой интерфейс DBAPI (PEP-249), несколько конкурирующих ORM и многочисленные уровни абстракции между софтом и базами. В этой статье — о том, как мы делали полноценную интеграцию нашей базы данных с Apache Superset: чтобы достаточно было выбрать YDB из выпадающего меню и начать визуализировать аналитические данные.

Друзья, сегодня мы погрузимся в мир Pydantic 2 – мощного инструмента для валидации данных в Python! Узнаем, почему эта библиотека стала незаменимой в 30% Python-проектов и как она упрощает работу с данными. От базовых концепций до продвинутых техник – мы охватим всё, что нужно знать современному Python-разработчику. Готовьтесь к практике – ведь только так можно по-настоящему освоить Pydantic и сделать ваш код более надёжным и эффективным.