SQL *

Введение

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

Выполнение кода на JavaScript из кода, написанного на Java:

import javax.script.*;

public class InvokeScriptFunction {
    public static void main(String[] args) {
        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine engine = manager.getEngineByName("JavaScript");

        // JavaScript code in a String
        String script = "function hello(name) {print('Hello, ' + name);}";

        // evaluate script
        engine.eval(script);
    }
}

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

Условие задачи

Есть три бога: A, B и C, один из которых бог истины, другой – лжи, а третий — случая. Бог истины всегда говорит правду, бог лжи — всегда обманывает, бог случая может говорить и правду, и ложь. Требуется определить богов, задав 3 вопроса, на которые можно ответить «да» или «нет». Каждый вопрос задаётся только одному богу. Боги понимают язык, но отвечают на своём языке, в котором есть 2 слова «da» и «ja», причём неизвестно, какое слово обозначает «да», а какое «нет».

Если значительная часть бизнес логики Вашего приложения располагается в базе данных, вас наверняка посещала мысль о модульном тестировании хранимых процедур и функций. Опустим обсуждение вопроса о том, хорошо это или плохо — выносить логику в хранимые процедуры, и разберемся — как тестировать хранимый код. В этой статье я расскажу о tSqlt — замечательном бесплатном фреймворке unit-тестов с открытым исходным кодом для Sql Server.

Добрый день! В процессе развития проекта приходится сталкиваться с проблемой производительности баз данных, т.к. объём данных растёт, и волей неволей выплывают проблемные участки.

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

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

Это как гвоздь в подошве любимого ботинка. Ходить можно, но все чаще ловишь себя на желании остаться на месте или перепоручить дело другим. Мелкие неудобства не только замедляют нашу работу, но и снижают мотивацию, вносят помехи в процесс, снижают качество результата. И если нашелся друг, который научил вас взять молоток и забить этот гвоздь, вы не только будете благодарны ему за помощь, но и сами поможете другим, избавив их от мелкой, но очень раздражающей помехи. Для этого и нужно общаться, делиться не только глубокими и сокровенными знаниями в форумах и на сайтах вроде Хабра, но и своими простыми трюками и «маленькими хитростями»

Как и любой текст, запросы и программы на SQL можно создавать в любом текстовом редакторе. Но если вы профессионал, вы очень много и часто работаете с SQL, то вам уже не будет достаточно наличия подсветки синтаксиса и автоматического переформатирования кода, особенно, если вам приходится переключаться между различными версиями одной СУБД или разными платформами СУБД.

Недавно мне случилось общаться с одним из ведущих профессионалов СУБД Oracle. Он рассказал много интересного про работу с планами выполнения запросов в различных версиях этой СУБД и не постеснялся рассказать всем об используемых им инструментах, приемах и дать немного полезных мелких советов. Я сделал перевод одной из статей в его блоге и хотел бы предложить его вниманию Хабравчан. Несмотря на то, что описанный прием применялся для работы с Oracle, я теперь с успехом применяю тот же подход для MS SQL и Sybase.

---

Меня зовут Дан Хотка (Dan Hotka). Я директор Oracle ACE. Одной из моих привилегий в этой группе является помощь в распространении информации и полезных технических знаний, связанных с СУБД Oracle. Меня хорошо знают после моих 12 (скоро 14) опубликованных книг и буквально сотен статей. Я регулярно пишу в блоге и собираюсь делать это в дальнейшем. Мы даже могли встречаться на одном из событий или встреч группы пользователей. Я регулярно выступаю на эти темы по всему миру.
Я собираюсь поделиться с вами как техническими знаниями про Oracle, так и тем, как эти знания применяются в решениях Embarcadero.

Довольно интересное видео (на английском, к сожалению), в котором девушка, на примере соцсетей, рассказывает о плюсах и минусах кэширования в web-приложениях.

Наиболее содержательными являются первые две трети ролика, которые можно суммировать следующим образом:

1) данных в соцсетях нынче много, обновляются они часто, а пользователю их нужно предоставлять быстро
2) поэтому без кэширования не обойтись
3) далее показывается, как кэширование (концептуально) работает в Twitter, Facebook и Reddit
4) но есть проблемка…
5) кэширование в каждом соцсетевом проекте отписывается вручную
6) в результате, имеем много кода, который делает практически одно и то же в каждом проекте. А много кода — это много багов и людского труда
7) и что же с этим делать?

Docsvision — это не просто программа, это платформа, позволяющая создавать свои решения для электронного документооборота. Статья нашего коллеги — разработчика Docsvision Димы Лейкина — предназначена как раз для разработчиков таких решений, к коим мы относим партнёров нашей компании и сотрудников IT-подразделений наших компаний-заказчиков.

В материале, разделённом на 5 логических частей, — базовая информация о том, как устроена система Docsvision. Кроме того, для разработчиков, которые хотят устроиться к нам на работу, эти знания будут дополнительным плюсом.

В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.

Предыстория

Будучи «недомиддлом» в одной Харьковской конторе, я внезапно получил в LinkedIn приглашение переехать в Польшу и начать работать на один большой банк. После очень долгих раздумий я таки согласился, мотивируя себя надеждой, что это будет очень полезный опыт. Поработать на большую корпорацию это не только опыт программирования но и два, ато и три года полезных записей для резюме, а так же +100 к ношению костюма.(Как бы не так, но об этом в другой раз). Оказалось, что уровень говнокода в Польше намного привосходит оный в Украине, а средний уровень Senior девелопера, по крайней мере из тех кого я тут встречал, не идет ни в какое сравнение с украинскими коллегами.

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

Linq появился в 2007 году, тоже же появился первый IQueryable-провайдер — Linq2SQL, он работал только с MS SQL Server, довольно сильно тормозил и покрывал далеко не все сценарии. Прошло почти 7 лет, появилось несколько Linq-провайдеров, которые работают с разными СУБД, победили почти все «детские болезни» технологии и, уже пару лет как, Linq to Database (обобщенное название для популярных провайдеров) готов к промышленному применению.

Тем не менее далеко не все применяют Linq to Database и объясняют это не только тем, что проект старый и переписать на linq довольно сложно, но и приводят в качестве аргументов различные мифы. Эти мифы кочуют из одной компании в другую и часто распространяются через интернет.

В этом посте я собрал самые популярные мифы и опровержения к ним.

Дисклеймер: Под Linq to Database здесь и далее понимаем самые распространенные .NET библиотеки для доступа к реляционным СУБД с использованием Linq запросов. Такие как Linq2SQL, Entity Framework, NHibername, Linq2db и подобные

С момента появления IQueryable провайдеров для доступа к базам данных писать запросы стало гораздо легче. С одной стороны это хорошо, потому что приложения стало делать гораздо легче. С другой стороны качество запросов сильно упало. И дело не в том, что провайдеры генерируют плохой SQL, а в том, что люди пишут запросы, не понимая как оно работает под капотом. Для многих C# программистов IQueryable является магией, и появляется естественное желание уменьшить влияние магии на приложения, изолировать магию от остального кода. Такой подход не только не исправляет ситуацию, а усугубляет её…

Ни для кого не секрет, что в Java EE Connection Pool реализуется используя Data Source. С примером реализации в Apache Tomcat можно ознакомиться по этой ссылке: habrahabr.ru/post/101342. Но что делать, если мы используем только Java SE и нам нужно организовать многопоточный доступ к базе данных по схеме Connection Pool. Ведь сервера приложений у нас в данном случае нет, следовательно, использовать Data Source мы не можем, а для создания соединений к бд нам придется скорее всего использовать java.sql.DriverManager. Можно еще использовать в замену данному подходу что-нибудь из этой статьи: docs.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html. Скорее всего кем-то данный подход уже реализовывался на Java, по крайней мере я не обнаружил такую реализацию в сети. И я решил изобрести свой велосипед. Было бы хорошо, если в поисковике при поиске Connection pool в Java выходила ссылка на эту статью, дополненную и отредактированную по комментариям и дополнениям от habr.ru, и эта статья была бы полезна кому-нибудь. Если стало интересно, то прошу под кат.

Сегодня мы бы хотели написать об очередной фиче нашего сервиса — мониторинге баз данных.
Существует множество различных сервисов и метрик, которые помогают собирать информацию о количествах посещений сайта, сумме продаж и других важных для бизнеса показателей. Но если нужно эти показатели как-то между собой сравнить? Или же возникнет необходимость проверять более «технические» значения, например, прирост базы?



ХостТрекер предлагает функцию для решения подобных задач — мониторинг БД.

UPD: Продолжение статьи по ссылке — habrahabr.ru/company/avito/blog/322510

О чем статья

Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд.

Постановка задачи

Рассмотрим высоконагруженный сайт крупной российской интернет-компании (теперь можно — это Авито ;)).
Деятельность компании описывается следующими цифрами: ~ 10 млн. активных пользователей, ~100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (~100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.

Во время посещения PyConRu 2014 я, с удивлением, узнал, что достаточно большая аудитория python-разработчиков не использует SQLAlchemy в качестве основного инструмента для работы с базой данных. Порассуждав на данную тему после Light Talks с коллегами было принято решение — во чтобы то ни стало написать статью о том, что же можно делать со всей мощью SQLAlchemy.

Обычно в написании сайтов не требуется чего-нибудь этакого от штатного ORM. А если и требуется, то хватает замены на нештатный или прочтения основной части документации. И, как правило, голову ломать над сложными запросами не приходится. Достаточно много различных ORM предлагают классические схемы One-2-Many, One-2-One, Many-2-Many, и т.д. Для обычных запросов и связей этого вполне достаточно. К сожалению, в больших проектах не обходится без частных случаев и программисты при сложных запросах пишут либо raw sql, либо полагаются на то, что им предлагает базовый функционал ORM. Это выглядит не совсем красиво или создает достаточно большую нагрузку на базу данных.

Понятно, что в погоне за скоростью выполнения сценариев, можно пожертвовать красотой кода, но что если скоростью можно пренебречь, а вот кроссплатформенностью — нет? Да и не хочется в python коде видеть что-то кроме python кода. А что если хочется на полную катушку использовать любимый ORM (для меня SQLAlchemy) и не писать raw sql запросы?

Последние пару дней работал над интересной задачей и хотел бы поделиться интересным опытом с сообществом.

В чём проявляется проблема:
Запускаю хранимую процедуру (хранимку) по выборке данных для отчета — выполняется три секунды, смотрю профайлером на бою — у пользователей те же результаты. Но проходит три часа и та же хранимка, с теми же параметрами выполняется уже 2 минуты, и аналогично у пользователей. Причём данные в используемые таблицы не вставлялись/удалялись, окружение не меняли и админы не делали настроек.

Как могут помнить те из вас, кто читает хаб «Программирование», зимой 2014 JetBrains объявила подписку на private preview C++ IDE. В результате немалое количество подписчиков ей уже пользуются, в начале осени мы планируем выпустить общедоступную early preview, а мы до сих пор олучаем письма от друзей на тему «мы не успели подписаться, как вскочить в этот поезд сейчас?».

А сейчас есть отличная возможность вписаться в похожую историю без опозданий: JetBrains открывает подписку на early preview новой IDE для разработчиков, которые пишут на SQL. И для админов баз данных, — им тоже бывает нужно что-то поудобнее, чем pgAdmin. Для админов новая IDE пригодится там, где им надо поработать с данными в таблицах. Назначать права, делать бэкапы и выполнять прочие чисто админские задачи IDE пока не умеет, хотя мы подумываем ее этому научить.

Короче: тут — подписываться, а под катом — подробности.

Добрый день, статья написана в качестве некоего продолжения данного опуса. Компания 1С довольно часто подвергается критике, нередко объективной, но я попытаюсь своим примером показать, что 1С предоставляет свободу выбора, что в нынешнее время как минимум заслуживает уважения. Также немного посчитаем деньги.

Мы разрабатываем базу данных. Однажны к нам обратилась компания, которая столкнулась со следующей задачей:

Есть некоторое множество объектов, и некоторое множество тегов. Каждый объект может содержать несколько тегов. Какие-то теги очень редкие, а какие-то встречаются часто. Одному объекту один тег может быть сопоставлен несколько раз.
Новые объекты, теги и связи между ними непрерывно добавляются.
Задача — очень быстро отвечать на вопросы вида: «сколько есть объектов, у которых есть тег А или B, но нету тега С» и похожие. На такие запросы хотелось бы отвечать за десятые доли секунды, при этом не останавливая загрузку данных.

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

SELECT 
    COUNT(*) 
FROM (
    SELECT 
        object_id, 
        (MAX(tag == A) OR MAX(tag == B)) AND MIN(tag != C) AS good
    FROM tags
    WHERE tag IN (A, B, C)
    GROUP BY object_id
) WHERE good == 1;

Чтобы такой запрос выполнялся быстро, мы разбили данные между серверами кластера по object_id, а внутри каждого сервера отсортировали их по тегам. Таким образом сервер, выполняющий запрос, может отправить запрос без изменений на все сервера с данными, а затем просто сложить их результаты. На каждом сервере с данными для выполнения запроса достаточно найти строки для тегов A, B и C (а так как данные по тегу отсортированы, это быстрая операция), после чего выполнить запрос за один проход по этим строкам. Худший тег имеет несколько десятков миллионов объектов, несколько десятков миллионов строк обработать за десятые доли секунды видится возможным.
Стоит отметить, что подзапрос содержит GROUP BY object_id. GROUP BY в данной ситуации можно выполнить несколькими способами, например, если данные после тега отсортированы по object_id, то можно выполнить что-то похожее на merge sort. В данной ситуации, однако, мы данные по object_id не отсортировали, и оптимизатор разумно решил, что для выполнения GROUP BY надо построить хеш-таблицу.

Мы загрузили все данные в кластер, и запустили запрос. Запрос занял 25 секунд.

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

Если проводить аналогии с Oracle, то в SQL Server нельзя так же легко получить список невалидных объектов:

SELECT owner, object_type, object_name
FROM all_objects
WHERE status = 'INVALID'

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