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

Нерешенная проблема, на которой мы остановились в прошлый раз, состоит в том, что неизвестно, с какого момента можно начинать проигрывание журнальных записей при восстановлении. Начать с начала, как советовал Король из Алисы, не получится: невозможно хранить все журнальные записи от старта сервера — это потенциально и огромный объем, и такое же огромное время восстановления. Нам нужна такая постепенно продвигающаяся вперед точка, с которой мы можем начинать восстановление (и, соответственно, можем безопасно удалять все предшествующие журнальные записи). Это и есть контрольная точка, о которой сегодня пойдет речь.

Контрольная точка

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

Много лет работая SQL Server DBA и занимаясь то администрированием серверов, то оптимизацией производительности. В общем, захотелось в свободное время сделать что-то полезное для Вселенной и коллег по цеху. Так в итоге получился небольшой опенсорс тул по обслуживанию индексов для SQL Server и Azure.

У нас был сервис на golang, отдельный топик kafka, clickhouse, gitlab-ci и падающий пайплайн, протухший ssh-ключ и вот это вот все, а еще сезон отпусков, жуткие ливни в городе, сломавшийся ноутбук, алерты по ночам, и горящий прод. Не то, чтобы это все было нужно для этой статьи, но раз показываешь типичные будни тестировщика, то иди в своем намерении до конца. Единственное, что меня беспокоило — это p0. В мире нет ничего более отчаянного, мрачного и подавленного, чем тестировщик, который пропустил это на прод. Но я знала, что довольно скоро я в это окунусь.

Привет!

24-25 июня в Новосибирске прошла конференция Highload++ Siberia 2019. Наши ребята тоже там были докладом «Контейнерные базы Oracle (CDB/PDB) и их практическое использование для разработки ПО», мы выложим текстовую версию немного позже. Было круто, спасибо olegbunin за организацию, а также всем, кто пришёл.


В этом посте мы хотели бы поделиться с вами задачами, которые были на нашем стенде, чтобы вы могли проверить свои знания в Oracle. Под катом — 8 задач, варианты ответов и объяснение.

LINQ вошел в .NET как новый мощный язык манипуляции с данными. LINQ to SQL как часть его позволяет достаточно удобно общаться с СУБД с помощью например Entity Framework. Однако, достаточно часто применяя его, разработчики забывают смотреть на то, какой именно SQL-запрос будет генерировать queryable provider, в вашем случае — Entity Framework.

Здравствуйте, в эфире опять Радио SQL! Сегодня у нас решение задачи, которую мы передавали в нашем предыдущем эфире, и обещали разобрать в следующий раз. И вот этот следующий раз наступил.

Задача вызвала живой отклик у гуманоидов галактики Млечный путь (и неудивительно, с их-то трудовым рабством, которое они до сих пор почитают за благо цивилизации). К сожалению, на третьей планете отложили запуск космической обсерватории «Спектр-РГ» в конце июля 2019 года РХ (летоисчисление местное), с помощью которого планировалось транслировать эту передачу. Пришлось искать альтернативные пути передачи, что привело к небольшому опозданию сигнала. Но всё хорошо, что хорошо кончается.

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

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

Журнал

Увы, чудес не бывает: чтобы пережить потерю информации в оперативной памяти, все необходимое должно быть своевременно записано на диск (или другое энергонезависимое устройство).

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

Чтобы это работало, журнальная запись в обязательном порядке должна попасть на диск до того, как туда попадет измененная страница. Отсюда и название: журнал предзаписи (write-ahead log).

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

Этот пост является третьей частью серии, посвященной операторам соединения (обязательно прочитайте часть 1 — nested loops joins, и часть 2 — merge joins). Перевод статьи подготовлен специально для студентов курса «MS SQL Server разработчик».

Hash Match Joins — это надежные рабочие лошадки физических операторов соединения.
В то время как Nested Loops Join завершится неудачей, если данных будет слишком много для того, чтобы поместить их в память, а Merge Join потребует, чтобы входные данные были отсортированы, Hash Match соединит любые данные, которые вы подадите на вход (при условии что для соединения выполняется предикат равенства и пока в вашем tempdb достаточно свободного места).

Мир баз данных давно захвачен реляционными СУБД, в которых используется язык SQL. Настолько сильно, что появляющиеся разновидности называют NoSQL. Им удалось отбить себе определенное место на этом рынке, но реляционные СУБД умирать не собираются, и продолжают активно использоваться для своих целей.

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

В последнее время на рынке появилось огромное количество новых языков программирования: Go, Swift, Rust, Dart, Julia, Kotlin, Hack, Bosque – и это только из числа тех, которые на слуху.
Ценность того, что эти языки привносят в мир программирования, тяжело переоценить, но, как правильно в прошлом году отмечал Y Combinator, говоря про инструменты разработки:

Фреймворки становятся лучше, языки немного умнее, но в основном мы делаем то же самое.

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

Предыдущий цикл был посвящен изоляции и многоверсионности PostgreSQL, а сегодня мы начинаем новый — о механизме журналирования (write-ahead logging). Напомню, что материал основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.

Этот цикл будет состоять из четырех частей:

• Буферный кеш (эта статья);
• Журнал предзаписи — как устроен и как используется при восстановлении;
• Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
• Настройка журнала — уровни и решаемые задачи, надежность и производительность.

Читайте и другие серии.

Индексы:

1. Механизм индексирования;
2. Интерфейс метода доступа, классы и семейства операторов;
3. Hash;
4. B-tree;
5. GiST;
6. SP-GiST;
7. GIN;
8. RUM;
9. BRIN;
10. Bloom.

Изоляция и многоверсионность:

1. Изоляция, как ее понимают стандарт и PostgreSQL;
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Блокировки:

1. Блокировки отношений;
2. Блокировки строк;
3. Блокировки других объектов и предикатные блокировки;
4. Блокировки в оперативной памяти.

Цели и требования к тестированию «1С Бухгалтерии»

Основной целью проводимого тестирования является сравнение поведения системы 1С на двух разных СУБД при прочих одинаковых условиях. Т.е. конфигурация баз данных 1С и первоначальная заполненность данными должны быть одинаковыми при проведении каждого тестирования.

Основными параметрами, которые должны быть получены при тестировании:

• Время выполнения каждого теста (снимается отделом Разработки 1С)
• Нагрузка на СУБД и серверное окружение во время выполнения теста снимается- администраторами СУБД, а также по серверному окружению системными администраторами

Тестирование системы 1С должно выполняться с учетом клиент-серверной архитектуры, поэтому необходимо произвести полноценную эмуляцию работы пользователя или нескольких пользователей в системе с отработкой ввода информации в интерфейсе и сохранением этой информации в базе данных. При этом, необходимо, чтобы большой объем периодической информации был разнесен по большому отрезку времени для создания итогов в регистрах накопления.

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

Описание настроек и характеристик тестируемых сред

Мы в компании Fortis решили перепроверить результаты, в том числе с помощью известного теста Гилева.

Также нас подстегнуло к тестированию в том числе и некоторые публикации по результатам изменения производительности при переходе от MS SQL Server к PostgreSQL. Такие как: 1С Батл: PostgreSQL 9,10 vs MS SQL 2016.

Возможно, вы что-то уже знаете про open source библиотеку Celesta. Если нет — не беда, сейчас всё расскажем. Прошёл ещё один год, вышла версия 7.x, много чего изменилось, и настала пора изменения подытожить, а заодно и напомнить о том, что такое Celesta вообще.

В эфире опять Радио SQL! Сегодня у нас совсем краткий выпуск, посвящённый подведению итогов решения задачки участниками хабросообщества. Я обещал разыграть небольшой приз, так что подвести итоги лучше небольшой, но всё же статьёй. Дописать строчку в оригинальную статью (что я, впрочем, тоже сделал) — было явно недостаточно, заинтересованные лица могут пропустить такое подведение итогов. Поэтому подстраивайте свои ложементы и вытягивайте омматофоры, мы начинаем!

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

В статье будут рассмотрены возможности, предоставляемые встроенным или декларативным секционированием в 12 версии PostgreSQL. Демонстрация подготовлена для одноименного доклада на конференции HighLoad++Siberia 2019 (upd: появилось видео с докладом).

Все примеры выполнены на недавно появившейся бета-версии:

=> SELECT version();

                                                     version                                                      
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12beta1 on i686-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 32-bit
(1 row)

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

Для меня написанное ниже является именно такой отправной точкой. Путь будет не близкий…

Мы начали с вопросов, связанных с изоляцией, сделали отступление про организацию данных на низком уровне, подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.

Затем мы рассмотрели разные виды очистки: внутристраничную (вместе с HOT-обновлениями), обычную и автоматическую.

И добрались до последней темы этого цикла. Сегодня мы поговорим о проблеме переполнения счетчика транзакций (transaction id wraparound) и заморозке.

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

Предыстория

Чтобы было понятно о чём речь, я расскажу совсем немного о VWO. Это платформа, с помощью которой можно запускать разные таргетированные кампании на своих сайтах: проводить A/B эксперименты, отслеживать посетителей и конверсии, делать анализ воронки продаж, отображать тепловые карты и проигрывать записи визитов.

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

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

Показать все клики на странице "abc.com"
ОТ <даты d1> ДО <даты d2>
для людей, которые
использовали Chrome ИЛИ
(находились в Европе И использовали iPhone)

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

Медленный запрос

Клиент, о котором идет речь, пытался сделать что-то, что интуитивно должно работать быстро:

Покажи все записи сессий
для пользователей посетивших любую страницу
с урлом, где есть "/jobs"

На этом сайте было огромное количество трафика, и мы хранили более миллиона уникальных URL-адресов только для него. И они хотели найти довольно простой шаблон урла, относящегося к их бизнес-модели.

Продолжаем голосовать за интересные доклады в секции «Хранилища данных (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!