Базы данных *

В статье рассматривается как начать работать с графовой СУБД Neo4j, используя Neo4j Browser. Это руководство может быть полезным как дополнение к книге Редмонда и Уилсона "Семь баз данных за семь недель", так как рассматриваемый веб-интерфейс был полностью переработан, а также к книге "Графовые базы данных" (Робинсон, Вебер, Эифрем), так как в ней этот вопрос вообще не рассматривается. Статья рассчитана на приступающих к изучению Neo4j. Те, кто уже знаком с этой СУБД, могут смело её пропустить.

Довелось работать с IBM DB2. И на 1С, и сервер на Django использовал эту СУБД одно время, OLAP запросы довольно шустро обрабатывал (правда, требовалась ручная настройка индексов, ну и веб-сервера, конечно, чтобы отклик был в пределах 2 секунд). Году в 2015 подготовил эту небольшую инструкцию себе, чтоб не забыть. И как дополнение к резюме, возможно кто-то прочитал на бумаге, оставшиеся годы без дела пролежала. Некоторое обобщение моего опыта работы с DB2. Немного поправил и предлагаю прочесть здесь для расширения кругозора. Может кого-то заинтересует. Сразу скажу, что с тех пор с DB2 не работал, подзабылось всё, но кое-что ещё помню. Критика и уточнения приветствуются, но, поскольку уже не работаю, может, не мне, а кому-то ещё будут полезны.

Продолжаем голосовать за интересные доклады в секции «Хранилища данных (Storage)» на DevConfX, которая пройдет уже через неделю. Обратите внимание на доклад о сертификации специалистов PostgreSQL, оставайтесь всегда в курсе последних событий в мире баз данных.

Заявки на секцию Storage

• Предвкушая двенадцатый PostgreSQL (Иван Панченко)
• NoSQL + SQL = MySQL 8 Document Store! (Витторио Чиоэ)
• Tarantool 2.1. Добавляем SQL в noSQL СУБД (Кирилл Юхин)
• Хранилища данных на службе BI (Exasol и Hadoop) (Александр Крашенинников и Алексей Еремихин)
  
• ProxySQL 2.0 или ЗОЖ с MySQL (Владимир Федорков)
• Сертификация PostgreSQL. Вопросы и ответы (Павел Лузанов)
• Базы данных в IT индустрии сейчас и 10 лет назад (Владимир Федорков)

Успей зарегистрироваться до 15 июня на юбилейной DevConfX!

Снова продолжая тему обустройства Zero Touch PROD под RDS. Будущие DBA не будут иметь возможности подключиться к PROD серверам напрямую, но смогут использовать Jenkins jobs для ограниченного набора операций. DBA запускает job и через некоторое время получает письмо с отчетом о выполнении этой операции. Давайте рассмотрим способы презентации этих результатов пользователю.

С 1999 года для обслуживания бэк-офиса в нашем банке используется интегрированная банковская система БИСКВИТ на платформе Progress OpenEdge, которая достаточно широко используется во всем мире, в том числе и в финансовом секторе. Производительность данной СУБД позволяет читать до миллиона и более записей в секунду в одной базе базе данных (БД). У нас Progress OpenEdge обслуживает около 1,5 млн депозитов физических лиц и порядка 22,2 млн договоров по активным продуктам (автокредиты и ипотека), а также отвечает за все расчеты с регулятором (ЦБ) и SWIFT.



Используя Progress OpenEdge, мы столкнулись с тем, что нам необходимо подружить ее с СУБД Oracle. Изначально эта связка была «бутылочным горлышком» нашей инфраструктуры — до тех пор, пока мы не установили и не настроили Pro2 CDC — продукт Progress, который позволяет отправлять данные из СУБД Progress в СУБД Oracle напрямую, в онлайн-режиме. В этом посте мы подробно, со всеми подводными камнями расскажем, как эффективно подружить OpenEdge и Oracle.

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

Aliexpress уже стал именем нарицательным в всем мире. Но Alibaba Group это не только интернет-молл, но и сервис облачных вычислений №1 в Китае.

Интересующихся прошу под кат…

К сожалению в интернете довольно мало информации по миграции реальных приложений и продакшн эксплуатации Percona XtraDB Cluster (далее PXC). Своим рассказом я постараюсь исправить эту ситуацию и рассказать о нашем опыте. Тут не будет пошаговой инструкции по установке и статью следует рассматривать не как замену офф документации, а как сборник рекомендаций.

Про обновление систем «на лету» без их остановки (zero-downtime deployment) написано немало статей и многие аспекты этого подхода является достаточно очевидными. На мой взгляд, наиболее сложная часть деплоймента в этом случае — обновление хранилищ данных, в случае если их контракт (схема) изменился. Именно этот аспект я бы и хотел рассмотреть в этой статье.

Это вторая часть статьи, которая описывает пользовательские функции для работы с системными каталогами: pg_class, pg_attribute, pg_constraints и т.д.

В этой части статьи обсуждаются функции, возвращающие характеристики ограничений и индексов.

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

Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска.

Мы продолжаем цикл статей разработчиков приложений для баз данных — Часть 1. Условная компиляция PL/SQL. Эта статья затронет тему использования Tibero в Java приложениях использующих JDBC и Hibernate, а также фреймворк Spring Roo.

Предисловие

В Интернете можно найти достаточно много примеров по созданию резервных копий баз данных, а также по их восстановлению. Приведем еще один пример встроенными средствами в MS SQL Server.

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

Предисловие

Часто возникает потребность в создании такого индикатора производительности, который бы показывал состояние СУБД относительно предыдущего периода или конкретного дня. В статье Реализация индикатора производительности запросов, хранимых процедур и триггеров в MS SQL Server. Автотрассировка был предложен пример по реализации такого индикатора. Здесь же опишем еще один более простой способ, который ко всему прочему позволяет посмотреть исторически не просто за сколько выполнился запрос, но и как выполнился, а также получить планы выполнения на каждый момент времени.

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

В данной статье будет рассмотрен пример реализации такого общего индикатора, где в качестве меры будет браться все время выполнения запросов (Total Elapsed Time).

Некоторое время назад я восхитился от команды Facebook-а, запилившей для целей мониторинга специальную базу — RocksDB. При внимательном рассмотрении оказалось, что оно форк более раннего гугловского проекта, оно архивирует данные налету и оно, будучи «в душе» NoSQL, стыкуется к MySQL как storage engine.

Дальше прилетела новость, что MariaDB включили этот движок в upstream с версии 10.2. Ништяки вроде архивирования на лету и ttl на отдельные строки под капотом так и манили попробовать это на чем-то подходящем…

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

Источник

Друзья, всех с прошедшим вчера Днем программиста! Жизни без багов и красивейшего кода!)

Мы продолжаем разбор облачных сервисов Техносерв Cloud и сегодня детально разложим, из чего состоит наша облачная база данных. Если заглянуть в результаты исследования, проведенного IDG Connect по заказу Oracle, увидим, что DBaaS скоро будет самым востребованным сервисом частного облака. Растет и число публичных сервисов DBaaS.

Снижение затрат за счет консолидации ресурсов, масштабирование по мере необходимости, контроль расходов, доступ к данным из любого места – всё это факторы, влияющие на выбор в пользу облачной базы данных. На рынке облачных услуг свои базы данных предлагают его ведущие игроки – Amazon Web Services, IBM, Microsoft и Oracle. Но есть одна проблема — все они разворачивают БД за пределами России, более того, далеко не все из них предлагают сервис – администрирование, управление производительностью, круглосуточную техническую поддержку (желательно на русском языке), – а только платформу.

Чтобы ответить на этот запрос рынка, мы запустили свой сервис и стали единственным российским облачный провайдером, работающим с четырьмя основными базами данных под ФЗ-152 и ФЗ-242.

В Яндекс.Деньгах хранится масса важной для комфортной работы пользователя информации. Настройки профилей и подписки на штрафы тоже нужно бэкапить, чем и занимается у нас связка из Barman Backup & Recovery for PostgreSQL и pg_receivexlog.

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

Кнопка уже несколько лет для работы с бухгалтерскими базами использует технологию публикаций 1C Fresh. Мы уже недавно писали о нашем опыте эксплуатации. Использование нами в качестве СУБД PostgreSQL вызвало интерес и ряд вопросов, поэтому мы решили рассказать об этом подробнее.

В первой части статьи «Ускоряем восстановление бэкапов в Postgres» я рассказал о предпринятых шагах по уменьшению времени восстановления в локальном окружении. Мы начали с простого: pg_dump-пили (а есть ли такое слово?), паковали gzip-ом, распаковывали и направляли вывод в psql < file.sql. На восстановление уходило около 30 минут. В итоге мы остановились на настраиваемом (custom) формате Postgres и применили аргумент -j, добившись уменьшения времени до 16 минут.

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

Друзья, сегодняшняя публикация открывает новую рубрику в блоге конференции PG Day Russia: интервью со специалистами в области эксплуатации баз данных. Беседа с профессионалом — отличная возможность приоткрыть завесу тайны, узнать секреты профессии, выяснить чем и как зарабатывают коллеги, посвятившие свою жизнь работе с СУБД. Мы надеемся, что предстоящие выпуски помогут вам взглянуть на рабочий процесс с новой стороны, дадут возможность задать волнующий вас вопрос, получить совет или же сориентироваться в дальнейших шагах по собственной карьерной лестнице.

В нашем пилотном интервью мы поговорили с Алексеем Лесовским, DBA компании Data Egret (бывш. PostgreSQL-Consulting). Алексей является специалистом с многолетним стажем в области администрирования PostgreSQL. Регулярные посетители технических конференций знают не по наслышке, что его доклады и мастер-классы славятся глубиной проработки и вниманием к деталям.

PG Day: Леша, давай начнем с вводной информации. Расскажи в двух словах про себя, как ты решил стать DBA и как ты вообще до такой жизни, что называется, докатился.

АЛ: Вообще, идеи стать DBA изначально у меня не было. Я к этому не стремился. Я работал системным администратором в компании, которая занималась веб проектами, администрировал линуксовые сервера, занимался виртуализацией. Весь их стек был построен на современных технологиях. Там были рельсы, там были мемкэши, редисы и был Postgres.

Предисловие

Часто возникает потребность каким-либо способом сообщать администраторам о проблемах, возникших на сервере. Причем уведомления в большинстве своем делятся на 2 типа:

1) реального времени, т. е. те, которые должны приходить сразу при возникновении проблемы
2) отложенного времени, т. е. те, которые приходят через достаточно продолжительное время (более 1 часа) после возникновения проблемы.

В моей работе было необходимо расширить функционал обычного Database Mail.

В данной статье будет рассмотрен пример того, как формировать уведомления в HTML-таблицы с последующей отправкой по почте администраторам.