SQL *

Сегодня мы предлагаем вашему вниманию отрывок из книги Сергея Тарасова «Дефрагментация мозга. Софтостроение изнутри», которая готовится к выходу в нашем издательстве.

Сокрытие базы данных или как скрестить ёжа с ужом

Упомянув один из крупнейших столпов современного софтостроения — мир ООП, нельзя обойти вниманием и другой — мир реляционных баз данных. Я намеренно вставил прилагательное «реляционные» применительно ко всем основным СУБД, хотя ещё в 1970-х годах такое обобщение было бы неправомерным.

Тем не менее, именно реляционным СУБД удалось в 1980-х годах освободить программистов от знания ненужных деталей организации физического хранения данных, отгородившись от них структурами логического уровня и стандартизованным языком SQL для доступа к информации. Также оказалось, что большинство форматов данных, которыми оперируют программы, хорошо ложатся на модель двумерных таблиц и связей между ними. Эти два фактора предопределили успех реляционных СУБД, а в качестве поощрительной премии сообщество получило строгую математическую теорию в основании технологии.

Каждые полчаса появляется новая статья с кричащим лозунгом Большие данные — «новая нефть»!. Просто находка для маркетинговых текстов. Большие Данные = Большая Нефть = Профит. Откуда взялось данное утверждение? Давайте выйдем за рамки штампа и копнем чуть глубже:
Одним из первых его употребил Майкл Палмер[1] еще в 2006 году:

Данные это просто сырая нефть. Она ценна, но без переработки она не может быть по-настоящему использована. Она должна быть превращена в газ, пластик, химикаты, и т.д., чтобы создать ценность, влекущую прибыльность; так и данные нужно проанализировать и «раскусить», чтобы они стали ценными.

Такое понимание трендового «Большие данные — новая нефть!» ближе к реальности чем к маркетингу. И совсем не отменяет высказывания Дизраели:
«Существуют три вида лжи: Есть ложь, наглая ложь и статистика».
Данная статья является продолжением топика Data Mining: Первичная обработка данных при помощи СУБД. Часть 1
Продолжим добычу!

О чем статья

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

С этой точки зрения, очень интересным будет ресурс Kaggle[1], который превращает исследование данных в спорт. Там проводят соревнования по анализу данных. Некоторые соревнования — с обучающими материалами и предназначены для начинающих. Вот именно обучению анализу данных, на примере решения одной из обучающих задач, и будет посвящён цикл статей. Первая статья будет о подготовке данных и использованию СУБД для этой цели. Собственно, о том, как и с чего начать. Предполагается что читатель понимает SQL.

Когда вопрос заходит о хранении в БД гибких (заранее не известных, часто изменяемых) структур данных, разработчики обычно обращаются к «великому и ужасному» EAV-паттерну, либо к ныне модным NOSQL базам данных.
Не так давно такая задача стала и передо мной.
— EAV. Вызывает у меня стойкую неприязнь, да и сказано и написано об этом было очень много всего негативного (Кайт, Фаулер, Карвин, Горман). Главный минус в том, что при написании запросов приходится оперировать уже не реальными сущностями («Сотрудник», «Дом», «Клиент», то для чего и предназначен SQL), а объектами, орагнизованными на более низком уровне (извините за сумбур). Поэтому это был самый не желательный вариант.
— NOSQL. Поначалу очень заинтересовал этот вариант (в частности MongoDB). После продолжительного использования реляционок, первое время начинаешь испытывать чувство тотальной свободы, от которого захватывает дыхание. Хранение документов любой структуры, моментальное создание новых коллекций, запросы к ним — красота! Но после непродолжительного использования эйфория начала спадать, а проблемы обнаруживаться:
— Бедный язык запросов (ИМХО) + отсутствие джойнов;
— Отсутствие схем (хорошая статья недавно была на эту тему (и не только на эту) habrahabr.ru/post/164361);
— Отсутствие встроенной поддержки ссылочной целостности;
— Отсутствие прибамбасов в виде хранимых процедур/функций, триггеров, представлений и многого другого.
— В моем приложении помимо данных с гибкой(изменяемой) структурой также необходимо хранить обычные статические данные — таблица пользователей, посещений, сотрудников и т.д. Работать с которыми (опять же имхо) гораздо проще и (самое главное) надежнее в обычной реляционной базе (та же самая ссылочная целостность и пр.).

Введение

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

От переводчика: Недавно презентовал на Хабре один проект, в котором использовал MySQL. Многие пользователи удивлялись, почему я не использую NoSQL для моих задач, и настоятельно порекомендовали переходить на нереляционные базы данных. Сегодня я наткнулся на эту статью, которая отлично объясняет, почему я “боюсь” NoSQL.

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

Последние две недели, однако, заставили меня понять, что я больше никогда не начну проект на основе MongoDB или любой другой нереляционной базы данных (НРБД) в качестве первичного хранилища данных. Обратите внимание – я сказал “начну”. Я не говорю, что больше никогда не буду использовать MongoDB как таковую.

На написание этого поста меня вдохновил мой друг Грег Янгблад, который показал мне на прошлой неделе одну интересную загадку в MySQL.

Возможности ETL средства IBM DataStage покрывают достаточно широкий спектр требований, которые возникают в задачах по интеграции данных, но, рано или поздно, возникает потребность расширить функциональные возможности, внедряя Parallel Routines на языке С или создавая Java классы, которые, в дальнейшем используются в Java Transformer или Java Client. Довольно ограниченные возможности же встроенного языка Basic давно устарели и не могут расцениваться как серьезное подспорье (так, например, невозможно использовать XML структуры, или, другой пример — попробуйте написать хеширование MD5 при помощи Basic. Это возможно, но займет значительное время на разработку и отладку).
Как бы там ни было, хотелось бы иметь достаточно гибкое средство, позволяющее работать с потоком данных, не требующее перекомпиляции своих исходных кодов и которое можно было бы использовать в редакторе DataStage Client. Моим коллегой и близким другом было предложено разработать Groovy Transformer. О нем и пойдет речь в данной заметке.

Приветствуем, уважаемые Хабравчане. Последнее время на Хабре стало мелькать название компании Teradata в тех или иных вопросах. И, увидев возможный интерес, мы решили рассказать немного о том, что же такое СУБД Teradata, от первого лица. Мы планируем подготовить небольшую серию статей о самых интересных, на наш взгляд, технических особенностях СУБД и работы с ней. Если у вас есть опыт работы с Teradata или в вашей компании используется наша платформа и у вас есть вопросы – подкидывайте их, и мы либо ответим на них в комментариях, либо подготовим соответствующую полноценную статью. А начнем с небольшого обзора. Для знакомства, так сказать.

HOLO — приставка от греческого ὅλος, «весь».

Введение

Не без волнения рад представить вашему вниманию свою разработку, позволяющую объединять музыкальную библиотеку в единое целое с целью поиска «похожей» музыки.
Ещё несколько лет назад, на пике самостоятельного изучения MATLAB, мне захотелось создать программу, которая позволяла бы по заданному образцу музыки находить другие композиции «в том же духе». Куча уважительных причин заставляли откладывать реализацию всё дальше и дальше, но в какой-то момент дело сдвинулось с мёртвой точки. В результате, слегка изменив основу для разработки, первая версия программы была сделана.

Во время недавней оптимизации запросов в базу данных наткнулся на описание работы SQLite с rowid. Если вкратце: в каждой таблице есть int64 столбец rowid, значение которого является уникальным для каждой записи в таблице. Посмотреть значение можно по имени «rowid» и в запросе * оно не показывается.

Записи хранятся как B-дерево по rowid. И это делает очень быстрым поиск и выборку по rowid. В два раза быстрее чем по primary key или по индексированному полю. Как я понял, поиск по индексированному столбцу — это поиск по B-дереву, в результате которого мы находим rowid. И уже имея rowid — ищем нужную запись.

Напрашивается очевидный вопрос: как сделать чтобы rowid и наш PRIMARY KEY совпадали?

Это совсем краткий пост о причинах возникновения Deadlock

В более менее нагруженных проектах, использующих транзакции InnoDB, в любой момент может возникнуть ошибка вида

«Deadlock found when trying to get lock; try restarting transaction»

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

Как известно, Caché можно использовать как реляционную СУБД, в том числе через JDBC/ODBC драйверы, с возможностью исполнения произвольных SQL-запросов и вызова SQL-процедур.
Известно также, что все данные в Caché хранятся в многомерных разреженных массивах — глобалах. Это позволяет в случае недостаточной производительности отдельно взятой SQL-процедуры не использовать стандартный CachéSQL-движок, а переписать ее код исполнения на языке серверной бизнес-логики Caché ObjectScript (COS), в котором можно реализовать оптимальный алгоритм выполнения SQL-процедуры, часто используя более оптимальные NoSQL-структуры данных (глобалы).
Однако в стандартной библиотеке классов Caché существует одно ограничение: для SQL-процедур, в которых отбор выполняется самописным COS-кодом, необходимо определять набор возвращаемых полей на этапе компиляции — т.е. нет возможности динамически задать метаданные для SQL-процедуры, работающей с NoSQL структурами.

О том, как снять это ограничение, рассказано под катом.

Прочитав новость об уязвимости в Skype, позволяющей угнать любой аккаунт, в процессе чтения комментариев и постов по теме наткнулся на новую для себя информацию: оказывается, начиная с версии 4.* Skype хранит информацию о пользователе в базе sqlite. Это и навело меня на мысль о том, что информацию из базы можно легко и непринужденно получить.

Хотелось бы рассказать некоторые технические подробности создания системы контроля расходов мобильной связи, концепция которой была описана в предыдущем посте.
В качестве примера будем рассматривать счет за один из месяцев от МТС и создадим не сложный OLAP проект.
Судя по откликам, эта тема довольно актуальна, так что, кому интересно, прошу под кат.

Не будет новостью, что контролировать расходы на связь в организации с более чем двадцатью сим карт дело не простое и многие предпочитают просто платить, не озадачиваясь анализом расходов.
На рынке есть специализированные продукты, позволяющие следить за расходами в основном в ручном режиме.
Хотел бы поделиться опытом создания системы контроля расходов для нескольких сотен тысяч сим карт построенной на базе MS SSAS.
В качестве поля для действия была выбрана компания имеющая на тот момент около 120 тыс сим карт, 90% из которых был провайдер с логотипом в виде яйца и устанавливаемых в м2м устройства.

Примечание переводчика

Данная работа является переводом части работы Chris Anley Advanced SQL Injection In SQL Server Applications. (прямая ссылка для скачивания)
В последующих статьях, при наличии свободного времени, данный перевод будет доведен до конца.

P.S. Перевод будет интересен более в образовательных и исторических целях.

Оригинальное название статьи: Продвинутые SQL-инъекции в приложениях, использующих язык SQL.

Аннотация

В данной статье подробно рассматриваются общие способы «SQL-инъекции», для известной платформы Microsoft Internet Information Server/Active Server Pages/SQL Server. В ней обсуждаются различные варианты использования инъекции SQL в приложениях и объясняются методы проверки данных, а также защита баз данных, в которых могут быть использованы инъекции.

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

Часто возникает задача восстановить базу по цепочке бэкапов на резервном/тестовом сервере, на котором непосредственный бэкап базы не проводился, отсутствуют записи в msdb, но есть сами бэкапы, снятые с продуктивного сервера. Вариант с восстановлением копии базы msdb может не подойти если должны существовать разные наборы джобов для основного сервера и того, на котором мы планируем восстановление. Если файлов с бэкапами немного, то восстановить логический порядок следования файлов нетрудно, особенно если бэкапы принадлежат логшиппингу. В этом случае все тривиально — в имени файла хранятся и время, и дата (стоит только помнить, что время в именах файлов хранится в UTC). Но что делать, если в бэкапах нет структуры или файлов очень много, и организовать их простым способом не представляется возможным или как можно просто определить начиная с какого файла логшипинга начинать донакатку?