Мы уже рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и все основные методы доступа, как то: хеш-индексы, B-деревья, GiST, SP-GiST и GIN. А в этой части посмотрим на превращение джина в ром.

RUM

Хоть авторы и утверждают, что джин — могущественный дух, но тема напитков все-таки победила: GIN следующего поколения назвали RUM.

Этот метод доступа развивает идею, заложенную в GIN, и позволяет выполнять полнотекстовый поиск еще быстрее. Это единственный метод в этой серии статей, который не входит в стандартную поставку PostgreSQL и является сторонним расширением. Есть несколько вариантов его установки:

• Взять пакет yum или apt из репозитория PGDG. Например, если вы ставили PostgreSQL из пакета postgresql-10, то поставьте еще postgresql-10-rum.
• Самостоятельно собрать и установить из исходных кодов на github (инструкция там же).
• Пользоваться в составе Postgres Pro Enterprise (или хотя бы читать оттуда документацию).

Ограничения GIN

Какие ограничения индекса GIN позволяет преодолеть RUM?

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

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

Метод доступа RUM в первом приближении можно рассматривать как GIN, в который добавлена позиционная информация, и который поддерживает выдачу результата в нужном порядке (аналогично тому, как GiST умеет выдавать ближайших соседей). Пойдем по порядку.

Приветствую! Данная небольшая статья призвана осветить некоторые аспекты применения Bash для анализа файлов в SQL-стиле. Будет интересна для новичков, возможно, опытные пользователи также найдут для себя что-нибудь новое.

Структура задачи:

• projects
  
  1. project1/ — проекты
     
     • conf/
       
       • <run_configurations>*.conf — конфигурации построения отчетов по таблицам
     • reports/
       
       • <run_configurations>/
         • report1.json — сами отчеты, содержат статистику по таблицам Apache Hive
         • report2.json
  2. project2/
     ...

Надо: найти просроченные отчеты.

Итак, расчехляем Bash, открываем отдельный терминал для man-ов и приступаем)

Всех, кому интересно — прошу под кат.

Введение

На очередном собеседовании меня спросили о недостатках модели данных EAV (Entity Attribute Value), я не нашёл что сказать, на мой взгляд это идеальный способ хранения произвольных данных. После короткого раздумья, я сказал что единственная проблема это невозможность построить индексы для выборок.

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

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

Предисловие

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

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

Привет, Хабр! Такое понятие, как «Глубокое обучение», существует с 1986 года, когда его впервые употребила Рина Дехтер. Развитие технология получила в 2006 после выхода публикации Джеффри Хинтона об эффективном предобучении многослойной нейронной сети. Сегодня deep learning часто живет в связке с распознаванием речи, пониманием языка и компьютерным зрением. Под катом вы узнаете про использование алгоритмов глубокого обучения в SQL. Заглядывайте!

У одного из наших достаточно крупных клиентов, в системе электронного документооборота которого ежедневно одновременно работают более 10000 пользователей, были применены так называемые sparse-колонки или разреженные столбцы.

Статья – попытка свести предпосылки и результаты применения этой функциональности (и некоторых других настроек СУБД) в едином месте.

Предисловие

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

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

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

Пока все ждут новостей, появится и заберёт ли свой выигрыш житель Воронежа, сорвавший рекордный джекпот в 506 млн. рублей, мы расскажем вам о технической части решения, которое позволило одной из крупнейших компаний по продаже лотерейных билетов в России увеличить объём продаж в 3 раза.

Предисловие

Достаточно нередко можно встретить задачу об обеспечении отказоустойчивости СУБД MS SQL Server. Еще интереснее становится, когда нет лицензии Enterprise, а только Standard.

Сразу отметим, что рассматриваться лицензия Express не будет, т к по данному экземпляру есть существенные ограничения. Да, некоторые из них можно обойти. Например, максимальный размер БД в 10 ГБ легко решается путем декомпозиции большой БД на более маленькие (например, по какому-то признаку создавать новую БД, а в главной БД в представлениях объединять выборки из одних таблиц разных БД). Но отказоустойчивость в Express будет достигаться либо силами системного администратора, либо использованием собственно разработанного (или стороннего) ПО.

В данной статье будут вкратце разобраны все существующие стандартные технологии отказоустойчивости для MS SQL Server 2017 и будет рассмотрен пример реализации отказа наиболее подходящего унифицированного из них в лицензии Standard.

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

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

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

В кубе, для адресации ячейки в пространстве, у нас есть понятие кортежа. Ось в кортеже устанавливает координаты. Если у нас есть единственный кортеж, то результат — содержание соответствующей ячейки в кубе. Поскольку у атрибутов куба есть элемент All, который служит значением по умолчанию (в большинстве случаев), если атрибут не был включен в кортеж, то мы выполняем агрегацию также, как если бы он там был. Например, следующий кортеж возвращает (агрегированный) объем продаж за 2013 год

(Date.Calendar.[Calendar Year].&[2013], Measures.[Internet Sales Amount])

Мы уже познакомились с механизмом индексирования PostgreSQL и с интерфейсом методов доступа, и рассмотрели хеш-индексы, B-деревья, индексы GiST и SP-GiST. А в этой части займемся индексом GIN.

GIN

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

Лазарь Лагин, «Старик Хоттабыч».

Gin stands for Generalized Inverted Index and should be considered as a genie, not a drink.

README

Общая идея

GIN расшифровывается как Generalized Inverted Index — это так называемый обратный индекс. Он работает с типами данных, значения которых не являются атомарными, а состоят из элементов. При этом индексируются не сами значения, а отдельные элементы; каждый элемент ссылается на те значения, в которых он встречается.

Хорошая аналогия для этого метода — алфавитный указатель в конце книги, где для каждого термина приведен список страниц, где этот термин упоминается. Как и указатель в книге, индексный метод должен обеспечивать быстрый поиск проиндексированных элементов. Для этого они хранятся в виде уже знакомого нам B-дерева (для него используется другая, более простая, реализация, но в данном случае это несущественно). К каждому элементу привязан упорядоченный набор ссылок на строки таблицы, содержащие значения с этим элементом. Упорядоченность не принципиальна для выборки данных (порядок сортировки TID-ов не несет в себе особого смысла), но важна с точки зрения внутреннего устройства индекса.

Администраторы баз данных и разработчики часто сталкиваются с ситуациями, когда необходимо данные из разных баз сравнивать и синхронизировать, либо просто перенести их в другую рабочую базу. В этом случае очень важно выбрать правильный инструмент, который поможет справиться с этой задачей быстро и эффективно. Для PostgreSQL на рынке существует несколько готовых инструментов, которые позволяют находить различия и выполнять синхронизацию данных. В этой статье проведем небольшой обзор особенностей этих инструментов, а именно продукты таких компаний как Devart, SQL Maestro Group, Navicat и Altova.

Предисловие

Довольно часто бывает необходимо перенести задания Агента на другой экземпляр MS SQL Server. Восстановление базы данных msdb невсегда именно то решение, которое подойдет, т к нередки случаи, когда нужно перенести именно только задания Агента, а также при переходе на более новую версию MS SQL Server. Так как же можно перенести задания Агента без восстановления базы данных msdb?

В данной статье будет разобран пример реализации скрипта T-SQL, который копирует задания Агента с одного экземпляра MS SQL Server на другой. Данное решение было опробовано при переносе заданий Агента с MS SQL Server 2012-2016 на MS SQL Server 2017.

Предположим, нужно собрать персональную информацию, например, дни рождения, имя, пол, количество детей и т.п., а также некоторые маркетинговые данные — как часто пользователи используют кнопки в корзине мобильного приложения и т.п. У нас уже есть приложение на базе SQL, но (как мы увидим дальше) продолжать использовать SQL для поиска — не лучшая идея. Для поиска придется прикрутить какой-то NoSQL движок.

Как совместить миры SQL и NoSQL? В этой статье будет несколько живых примеров интеграции продвинутого поискового движка Elasticsearch в устаревшие приложения, работающие с RestX, Hibernate и PostgreSQL/MySQL.

Расскажет об этом Дэвид Пилато (David Pilato) — эксперт компании Elastic (это те ребята, что сделали Elasticsearch, Kibana, Beats, and Logstash — то есть, Elastic Stack). У Дэвида есть огромный опыт проведения докладов о продуктах Elastic (конференции Devoxx в Англии, Бельгии и Франции, всевозможные JUG, Web5, Agile France, Mix-IT, Javazone, доклады для конкретных компаний, и так далее). Иначе говоря, излагает Дэвид весьма понятно и доходчиво, а его доклады заменяют тренинги за сотни нефти.

В основе этой публикации — доклад Дэвида на конференции Joker 2016, которая прошла в Санкт-Петербурге в минувшем октябре. Тем не менее, обсуждаемые темы за прошедший год никак не потеряли актуальности.

Статья доступна в двух вариантах: видеозапись доклада и полная текстовая расшифровка (жмите кнопку «читать дальше»  ⇩). В текстовом варианте все необходимые данные представлены в виде скриншотов, так что вы ничего не потеряете.

Кто-то задал такой вопрос:

Мне нужно создать таблицу group со столбцом code. Можно ли добавить ограничение на столбец, которое допускало бы только буквенные символы (D, M, O, P или T) с последующими двумя цифровыми символами?

Ему ответили:

Вы не можете этого сделать обычным способом — MS SQL Server поддерживает проверку ограничений, но лишь в виде мин/макс значения INT, длины строки и т.п. То, что вам нужно, — проверка на основе регулярного выражения, которую SQL Server не поддерживает. Теоретически можно сделать .NET вставку, развернуть на SQL Server и заставить его использовать такую проверку — нетривиальная задача.

Попробуем разобраться

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

[DMOPT][0-9][0-9]

Оно допускает только буквенные символы (D, M, O, P или T) с последующими двумя цифровыми символами. Ладно, хватит разговоров, давайте перейдем к коду

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

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

Данный материал будет полезен тем, кто полностью освоил базовые навыки SQL и желает учиться дальше. Советую выполнять и экспериментировать с примерами в pgAdmin'e, я сделал все SQL-запросы выполнимыми без разворачивания каких-либо дампов.

Поехали!

В продолжение темы «доступным языком про Ignite / GridGain», начатой в предыдущем посте (Для чего нужен Apache Ignite), давайте рассмотрим примеры использования продукта «для простых смертных».

Терабайты данных, кластеры на сотни машин, big data, high load, machine learning, микросервисы и прочие страшные слова — всё это доступно Ignite. Но это не значит, что он не годится для менее масштабных целей.

Сегодня мы рассмотрим, как Ignite может легко хранить любые ваши объекты, обмениваться ими по сети и обеспечивать взаимодействие .NET и Java.

SQL пробуждается и наносит ответный удар силам тьмы — NoSQL

С самого начала компьютерной эры человечество собирает экспоненциально растущие объемы данных, и вместе с этим растут требования к системам хранения, обработки и анализа данных. Из-за этого в последнее десятилетие разработчики ПО отказались от SQL как от устаревшей технологии, которая не могла масштабироваться вместе с растущими объемами данных — и в результате появились базы данных NoSQL: MapReduce и Bigtable, Cassandra, MongoDB и другие.

Однако сейчас SQL возрождается. Все основные поставщики облачных услуг предлагают популярные управляемые сервисы реляционных баз данных: Amazon RDS, Google Cloud SQL, база данных Azure для PostgreSQL (запущена буквально в этом году) и другие. Если верить компании Amazon, ее совместимая с PostgreSQL и MySQL база данных Aurora стала «самым быстрорастущим сервисом в истории AWS». Не теряют популярности и SQL-интерфейсы поверх платформ Hadoop и Spark. А в прошлом месяце поддержку SQL запустила и Kafka. Авторы статьи скромно признаются, что и сами разрабатывают новую базу данных временных рядов, которая полностью поддерживает SQL.

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

Переведено в Alconost

Часть 1. Новая надежда

Привет, Хабр! Представляю вашему вниманию перевод статьи SQL Server Insert Performance for Clustered Indexes vs. Heap Tables

Вопрос

Я прочел множество различной документации по современным методам работы с SQL Server, утверждающей, что каждая таблица должна иметь кластеризованный индекс и не быть кучей с некаластеризованными индексами. Большинство источников отмечает административную выгоду от использования кластеризованных индексов. Но есть ли в этом какое-то влияние на производительность и другие положительные или отрицательные стороны?