SQL *

Вы когда-нибудь анализировали вакансии?

Задавались вопросом, в каких технологиях наиболее сильна потребность рынка труда на текущий момент? Месяц назад? Год назад?

Как часто открываются новые вакансии Java-разработчиков в определенном районе Вашего города и как активно они закрываются?

В этой статье я расскажу Вам, как можно достичь желаемого результата и построить отчетную систему по интересующей нас теме. Поехали!


(Источник картинки)

Юля: Так, кто вчера менял мою процедуру?
Лёша: не я
Максим: не я
— Ребят, может Git заведём ?
Серёжа: давно пора!
прошло 2 недели…

Юля: ребяяят?
— Юль, а ты не коммитила?
Юля: damn нет(…

Вот так всё и началось. Ну а что, каждый символ и каждую строчку коммитить?

А может всё это будет происходить само?) На этом моменте в голову начинают приходить
DDL-триггеры, Temporal table и картина складывается. Решено, будем хранить версии внутри
SQL Server'a !)

Описание уязвимостей — это одно, а вот попробовать найти уязвимость и поработать с ней — совсем другое дело. Именно для этих целей создаются и развиваются специальные приложения, в которых намеренно оставлены уязвимости. Если набрать в поисковой системе запрос «Purposely vulnerable app», вы найдете ни один десяток ссылок.

В этом цикле мы начнем разбирать уязвимости из OWASP Top 10, и в качестве полигона я буду использовать такое намеренно уязвимое приложение. В моем случае это будет OWASP Mutillidae II. Это не то, чтобы самый лучший вариант, но в нем уязвимости структурированы именно так, как нужно для образовательных целей.

Некоторое время назад передо мной была поставлена задача написать процедуру, которая выполняет прореживание котировок рынка Форекс (точнее, данных таймфреймов).

Формулировка задачи: данные поступают на вход с интервалом в 1 секунду в таком формате:

• Название инструмента (код пары USDEUR и пр.),
• Дата и время в формате unix time,
• Open value (цена первой сделки в интервале),
• High value (максимальная цена),
• Low value (минимальная цена),
• Close value (цена последней сделки),
• Volume (громкость, или объём сделки).

Необходимо обеспечить пересчёт и синхронизацию данных в таблицах: 5 сек, 15 сек, 1 мин, 5 мин, 15 мин, и т.д.

Описанный формат хранения данных имеет название OHLC, или OHLCV (Open, High, Low, Close, Volume). Он применяется часто, по нему сразу можно построить график «Японские свечи».


Под катом я описал все варианты, какие смог придумать, как можно прореживать (укрупнять) полученные данные, для анализа, например, зимнего скачка цены биткоина, а по полученным данным вы сразу построите график «Японские свечи» (в MS Excel такой график тоже есть). На картинке выше этот график построен для таймфрейма «1 месяц», для инструмента «bitstampUSD». Белое тело свечи означает рост цены в интервале, чёрное — снижение цены, верхний и нижние фитили означают максимальную и минимальную цены, которые достигались в интервале. Фон — объём сделок. Хорошо видно, что в декабре 2017 цена вплотную приблизилась к отметке 20К.

Решение будет приведено для двух движков БД, для Oracle и MS SQL, что, в некотором роде, даст возможность сравнить их на этой конкретной задаче (обобщать сравнение на другие задачи мы не будем).

Привет! Этот пост о том, что нового в DataGrip 2018.2. C этой версии поддержка баз данных есть в CLion и AppCode. В WebStorm её можно включить, если вы параллельно используете DataGrip.



— Лог всех запросов
— Новый форматер кода
— Запуск хранимых процедур
— Миграция исходников
— План запроса в виде диаграммы
— Редактирование SQL
— Редактор данных
— Улучшения в пользовательском интерфейсе

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

Я работаю PL/SQL разработчиком. Есть задача собирать некоторые данные для метрик, чтобы отслеживать загрузку систем. Есть некоторая функция, которая вызывается с параметром, состоящим из списка ID.

1,2,3,4…1001,1002,1003…

Задача заключается в следующем. Нужно разбить такую строку на элементы и записать их в целочисленную коллекцию.

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

Твиты зашли неплохо и попали на HackerNews. Последствием такой мини-популярности стала интересная дискуссия. Одни согласились со мной, а другие назвали это глупостью и бредом. Ну, в интернете тоже случаются перестрелки.

Я не пытаюсь убедить вас использовать свой подход. Скорее я хочу подробнее объяснить, что именно имелось в виду в первоначальном выступлении в Twitter.

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

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

До того как встретиться с Big Data и Spark, в частности, мне довелось много и часто оптимизировать SQL запросы, сначала для MSSQL, потом для Oracle, и вот теперь я столкнулся со SparkSQL.

И если для СУБД уже существует множество хороших книг, описывающих методологию и «ручки», которые можно покрутить для получения оптимального плана запроса, то для Spark такого рода книг я не встречал. На глаза попадались больше статьи и наборы практик, причем больше относящиеся к работе через RDD/Dataset API, а не чистому SQL. Для меня одной из эталонных книг на тему оптимизации SQL является книга Дж. Льюис «Oracle. Основы стоимостной оптимизации». Что-то подобное по глубине проработки я и искал. Почему предметом исследования стал именно SparkSQL, а не API, лежащий в основе? Тут интерес был вызван особенностями проекта, над которым я работаю.

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

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

Крупный бизнес и кровавый энтерпрайз уже давно нашли замену взрослым рсубд на задачах DWH и аналитики. DWH массово движется в сторону DataLake и Hadoop. Выглядит, что и небольшим компаниям уже нет особого смысла запускать аналитику на серьезной рсубд. С ростом кол-ва ядер доступных даже небольшому бизнесу пытаться лицензировать полноценную редакцию взрослой субд типа Oracle смысла мало. Standard редакция Oracle хоть и лицензируется по сокетам, но при этом вырезан важнейший функционал. Во первых в standard редакции нет partitioning

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

"Слишком занят, чтобы стать лучше" Licensed CC by Alan O’Rourke / Audience Stack. Оригинальное изображение

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

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

Ссылка на GitHub для нетерпеливых

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

Данная статья расскажет про библиотеку на Kotlin, которая позволяет писать SQL запросы в синтаксисе Kotlin. Также, мы немного посмотрим на внутренности библиотеки, чтобы понять как это работает.

Представьте себе Oracle DBA. Ему уже за тридцать, он слегка полноват, носит жилетку, на шее у него висит секретный токен доступа ко всем базам, а в резюме полстраницы пройденных им сертификаций. Суббота. День большого релиза. Кульминация. Время накатывать изменения на базу данных. Он набирает sqlplus, нажимает ENTER и по черному экрану куда-то вверх, в пустоту, устремляются километры SQL команд. Совсем как в звездных войнах. Спустя пять минут все готово. Через час релиз завершен. Работа сделана, день удался. Теперь можно и по паре пива.

Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.

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

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

Алексей Лесовский (@lesovsky) на Highload++ 2017 рассказал, как с помощью встроенных и сторонних инструментов, диагностировать различные типы проблем и как устранять их. Под катом расшифровка этого доклада, построенного по спиральному принципу: сначала мы перечислим все возможные средства диагностики, потом перейдем к перечислению типовых проблем и их диагностике, далее посмотрим, какие экстренные меры можно принять, и наконец как радикально справиться с задачей.


О спикере: Алексей Лесовский администратор баз данных в компании Data Egret. Одной из любимых тем Алексея в PostgreSQL является потоковая репликация и работа со статистикой, поэтому доклад на Highload++ 2017 был посвящен тому, как помощью статистики искать проблемы, и какие использовать методы для их устранения.

План

1. Немного теории, или как работает репликация в PostgreSQL
2. Troubleshooting tools или что есть у PostgreSQL и сообщества
3. Troubleshooting cases:
   
   • проблемы: их симптомы и диагностика
   • решения
   • меры, которые нужно принимать, чтобы этих проблем не возникало.

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

13 Июня вышел Elasticsearch 6.3.0 на основе Lucene 7.3.0. Это последний стабильный релиз и уже доступен для использования в облаке через службу Elasticsearch на Elastic Cloud.

Многие знают и используют встроенную функцию ISNULL(X, Y), которая заменяет первый аргумент на второй в случае, если он (первый) NULL. Менее употребима обратная встроенная функция NULLIF(X, Y), которая возвращает NULL, если первый аргумент равен второму. Комбинация этих двух функций позволяет избежать использования конструкций IF-ELSE или CASE-WHEN, что делает код компактнее. Если интересно посмотреть пару примеров — добро пожаловать под кат.

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

В этой статье я расскажу вам о том, как всерьез задумался об альтернативе Oracle. А как же Postgre, скажете вы? Да, но есть нюансы. Сперва разберемся с вопросом «Почему Oracle?».
Бизнес логика у нас в БД. В книге Oracle для профессионалов Том Кайт пишет

При разработке приложений баз данных я использую очень простую мантру:

если можно, сделай это с помощью одного оператора SQL;
если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;
если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;
если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке C;
если это нельзя реализовать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать...

и в проектировании систем я следую этому правилу. Особенно радуют объектные типы в Oracle, с их помощью сложная бизнес логика красиво и удобно реализуется по всем канонам ООП.

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

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

Уже несколько раз мне попадались публикации про корейский продукт Tibero, якобы создаваемый для замены Oracle. А нынче у них аттракцион невиданной щедрости — лицензии на Standard раздают для разработчиков практически бесплатно, за доллар на сокет. Итак, разбираемся: что на данный момент могут предложить корейцы. С автомобилями ведь у них, уже (почти) получилось!

Сегодня мы поговорим с Николаем, «борцом» за продвижение новых технологий в мире БД, членом нашего программного коммитета и активным участником всевозможных конференций. Главные темы — самоуправляемые СУБД, DBA AI, облака, NoSQL, встроенные механизмы контроля БД, доклады на РИТ++ и HighLoad++ Siberia, а также масса дельных советов и примеров, которые могут пригодится в реальной работе как разработчику, так и DBA.