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

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

Прежде всего, хотелось бы отметить 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).