HighLoad++ Moscow 2018, зал «Конгресс-холл». 9 ноября, 15:00
Тезисы и презентация: http://www.highload.ru/moscow/2018/abstracts/4066
Юрий Насретдинов (ВКонтакте): в докладе будет рассказано об опыте внедрения ClickHouse в нашей компании – для чего он нам нужен, сколько мы храним данных, как их пишем и так далее.
Дополнительные материалы: использование Clickhouse в качестве замены ELK, Big Query и TimescaleDBЧитать полностью »
Часто в таблицах содержится большое количество логических полей, проиндексировать все из них нет возможности, да и эффективность такой индексации низка. Тем не менее, для работы с произвольными логическими выражениями в SQL пригоден механизм многомерной индексации о чем и пойдёт речь под катом.
Читать полностью »
Clickhouse — это столбцовая система управления базами данных для онлайн обработки аналитических запросов (OLAP) с открытым исходным кодом, созданная Яндексом. Ее используют Яндекс, CloudFlare, VK.com, Badoo и другие сервисы по всему миру для хранения действительно больших объемов данных (вставка тысяч строк в секунду или петабайты данных, хранящихся на диске).
В обычной, «строковой» СУБД, примерами которых служат MySQL, Postgres, MS SQL Server, данные хранятся в таком порядке:
При этом значения, относящиеся к одной строке, физически хранятся рядом. В столбцовых СУБД значения из разных столбцов хранятся отдельно, а данные одного столбца – вместе:
СУБД Postgres Pro Standard придумана для того, чтобы доставлять наши разработки пользователям быстрее, чем мы можем это сделать через PostgreSQL. Те фичи, которые еще не вошли в PostgreSQL, но находятся на твердом пути туда, мы включаем в Postgres Pro Standard. Также в Postgres Pro Standard входят некоторые расширения, которые востребованы нашими клиентами, но отсутствуют в обычной поставке PostgreSQL.
Иногда бывают исключения, когда в Postgres Pro Standard по просьбам юзеров и для их удовлетворения включаются и менее тривиальные фичи, которым по-хорошему место только в Postgres Pro Enterprise. В частности, это PTRACK, о нём ниже.
Не все, но изрядная доля дополнительных расширений и утилит, входящих в Standard, разработана в Postgres Professional. Все патчи Postgres Pro придуманы и реализованы нашими силами. Начнем с улучшений, потребовавших вмешательства в ядро СУБД.
Читать полностью »
«Покрывающий индекс» не просто еще одна фича, которая может пригодиться. Это вещь сугубо практичная. Без них Index Only Scan может не дать выигрыша. Хотя и покрывающий индекс в разных ситуациях эффективен по-разному.
Речь здесь будет не совсем о покрывающих индексах: строго говоря, в Postgres появились так называемые инклюзивные индексы. Но, по-порядку: покрывающий индекс — это индекс, который содержит все значения столбцов, необходимые запросу; при этом обращение к самой таблице уже не требуется. Почти. О «почти» и других нюансах можно прочитать в статье Егора Рогова, входящей в его индексный сериал из 10 (!) частей. А инклюзивный индекс создается специально для поиска по типичным запросам: к поисковому индексу добавляются значения полей, по которым искать нельзя, они нужны только для того, чтобы не обращаться лишний раз к таблице. Такие индексы формируются с ключевым словом INCLUDE.
Анастасия Лубенникова (Postgres Professional) доработала метод btree так, чтобы в индекс можно было включать дополнительные столбцы. Этот патч вошел в версию PostgreSQL 11. Но патчи для методов доступа GiST/SP-GiST не успели созреть до выхода этой версии. К 12-й GiST дозрел.
Читать полностью »
На Хабре есть дайджесты анонсов для Москвы и Санкт-Петербурга, а для Нижнего Новгорода пока почему-то нет, хотя здесь и IT-компаний много (очень много!), и событий хватает всех форматов и для любого стека, и читателей Хабра ого-го. Я для дайджестов слишком ленива занята, но отдельные события удивляют своей крутизной и скромностью освещения. Например, встреча с Петром Зайцевым, посвящённая СУБД. Что ж, будем исправляться.
Кстати, только-только отгремит очередной HighLoad++, так что у Петра можно спросить немного инсайтов по теме
Читать полностью »
Приятно видеть знакомые фамилии в списке Acknowledgments официального релиза PostgreSQL 12. Мы решили свести вместе попавшие в релиз новшества и некоторые багфиксы, над которыми трудились наши разработчики.
(В Release Notes это звучит как Add support for the SQL/JSON path language (Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova)
Сам этот патч, возможности JSONPath и история вопроса обсуждались в деталях в отдельной статье здесь на харбре. JSONPath — серьезное достижение Postgres Professional и одно из главных новшеств PostgreSQL 12 вообще.
В 2014 году А.Коротковым, О.Бартуновым и Ф.Сигаевым было разработано расширение jsquery, вошедшее в результате в версию Postgres Pro Standard 9.5 (и в более поздние версии Standard и Enterprise). Оно дает дополнительные, очень широкие возможности для работы с json(b).
Когда появился стандарт SQL:2016, оказалось, что его семантика не так уж сильно отличается от нашей в расширении jsquery. Не исключено, что авторы стандарта даже поглядывали на jsquery, изобретая JSONPath. Нашей команде пришлось реализовывать немного по-другому то, что у нас уже было и, конечно, много нового тоже.
Хотя специальный патч с функциями до сих пор не закоммичен, в патче JSONPath уже есть ключевые функции для работы с JSON(B), например:
jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)') возвращает 3, 4, 5
jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)') возвращает 0 записейКроме того, были оптимизированы и некоторые функции, которые уже работали с JSON раньше. Этим успешно занимался Никита Глухов.
Например, оператор #>>, соответствующий функциям jsonb_each_text() и jsonb_array_elements_text(), раньше достаточно быстро преобразовывал JsonbValue в text, но работал неторопливо с другими типами. Сейчас всё работает быстро.
Читать полностью »
Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.
Релиз-кандидат PostgreSQL 12
В релизе-кандидате вся функциональность идентична грядущему официальному релизу. Если вновь выявленные и недоисправленные баги будут закрыты в срок, то официальный релиз выйдет 3 октября. По сравнению с PG 12 beta 4 исправлено несколько багов, в основном связанных с ECPG — SQL, встраиваемом в C. Релиз-кандидат доступен.
Приглашаем вас на открытый митап, организованный совместно Райффайзенбанком и компанией Postgres Professional. Ждем вас 8 октября в нашем офисе в Нагатино.
FYI: this article is an expanded version of my talk at SQA Days #25.
Based on my experience with colleagues, I can state: DB code testing is not a widely spread practice. This can be potentially dangerous. DB logic is written by human beings just like all other «usual» code. So, there can be failures which can cause negative consequences for a product, business or users. Whether these are stored procedures helping backend or it is ETL modifying data in a warehouse — there is always a risk and testing helps to decrease it. I want to tell you what tSQLt is and how it helps us to test DB code.
