SQL *

Приветствуем, уважаемые Хабравчане. Последнее время на Хабре стало мелькать название компании 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). Но что делать, если в бэкапах нет структуры или файлов очень много, и организовать их простым способом не представляется возможным или как можно просто определить начиная с какого файла логшипинга начинать донакатку?

Здравствуйте!

Прежде всего, хотелось бы отметить 2 момента:
— данная статья описывает алгоритм работы, а не как оптимизировать конкретные SQL-запросы;
— описываемый в статье подход не актуален для «производительного» железа, речь пойдет о том, как удалось повысить «отзывчивость» интерфейса приложения интенсивно работающего с БД на бюджетных смартфонах под управлением Android;

NewSQL

Начало

Сегодня очень легко наблюдать стремительный рост данных в интернете. Согласно одной оценке, данные, созданные в 2010, составляют приблизительно 1,200 ЭБ (10¹⁸ байт) и вырастут почти к 8,000 ЭБ к 2015 в Интернете, являющимся основным поставщиком данных к потребителю.

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

Пока программисты всего мира устраивают глобальные Holywars на тему: «SQL vs NoSQL», крупные компании, такие как Google и Facebook со своей миллиардной аудиторией всеми силами борются с нехваткой мощностей и предельными работами СУБД. Несмотря на появление новой технологии NoSQL, которая позволяла легко масштабировать данные, она так и не решила вопросы связанные с соответствием операций требованиям ACID (atomicity, consistency, isolation, durability — «атомарность, непротиворечивость, изолированность, долговечность») — стандарта, который гарантирует точность выполнения оперативных транзакций средствами СУБД, даже если работа системы прерывалась. На фоне всего этого компания VoltDB при поддержке нескольких других компаний, начали разрабатывать с чистого листа новый opensource проект под название NewSQL, сочетающий в себе лучшие стороны SQL и NoSQL.

Этот пост для тех, кто сталкивался с проблемой производительности, при расчете медианы в OLAP кубе.
Одним из главных достоинств OLAP технологии является скорость получения результатов при обращении к базе. Расчеты происходят «на лету». Однако с медианой, не все так просто.
Для справки: медиана — вид средней. Это величина, которая находиться в середине ряда значений отсортированного по возрастанию. Например, для ряда значений {1, 2, 5, 6, 9} медианой является 5.

Рассмотрим ситуацию на примере OLAP сервера от Microsoft — SSAS 2008 (SQL Server Analysis Services).

Предисловие

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

В данной заметке я покажу, как запускать DBDeploy из скрипта Gradle.

О чём это вообще?

Возможно, вы уже слышали о версионированной миграции структуры баз данных. Об этом писали на хабре. DBDeploy — один из самых простых и известных инструментов, позволяющий легко установить все последние изменения в базе данных на любом инстансе и любой девелоперской машине. А Gradle — модный ныне инструмент для сборки проекта (как Ant и Maven, только лучше). О нём тоже уже писали.

И в чём вопрос?

Вопрос в том, как запускать DBDeploy из скрипта Gradle? У DBDeploy есть таски для Ant и плагин для Maven, но пока ещё нет плагина для DBdeploy (точнее, он в зачаточном состоянии). Немного потыркавшись, я пришёл к выводу, что самый простой способ — это использовать тот самый Ant таск DBDeploy из скрипта Gradle (здесь описано, как из gradle-скрипта использовать любые Ant-таски). Рассмотрим пример.

Введение

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

Более сложная цель

Рассмотрим задачу, с которой я столкнулся в процессе своей работы. Мне кажется этот пример в достаточной мере раскрывает суть текущей темы.

Все началось с того, что на сайте codeforces.ru в очередном Codeforces Round я увидел интересную задачку “Скобочная последовательность” и решать ее “неинтересным способом” никак не хотелось.

Вкратце условия задачи сводятся к нахождению в строке, состоящей только из символов «(», «)», «[» и «]», правильной cкобочной последовательности, содержащей как можно больше скобок «[».

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

Обеспечение масштабируемости в SQL Database

Одним из наиболее значимых преимуществ размещения баз данных в среде SQL Database являются встроенные функции обеспечения масштабируемости. При необходимости можно добавить дополнительные базы данных. Два компонента SQL Database обеспечивают масштабируемость за счет постоянного отслеживания рабочей нагрузки на каждом из узлов. Первый компонент — Engine Throttling (регулировщик нагрузки на ядро), который защищает сервер от перегрузки. Второй компонент — Load Balancer (балансировщик нагрузки), который следит за тем, чтобы сервер не работал постоянно в режиме повышенной производительности.