SQL *

Привет, Хабр! Мы много работаем с Quest Software, и в этом году они приобрели ApexSQL — производителя решений для управления и мониторинга баз данных Microsoft SQL Server. В России об этих ребятах, как нам кажется, знают мало. На главной своего сайта они пишут «Killer tools for SQL Server». Звучит угрожающе. У нас появилась идея представить этого вендора и разобраться что же такого убийственного есть в их решениях. Начнём с хайповой части — бесплатных продуктов. После них будет краткая часть о коммерческих продуктах. Надеюсь, эти программы окажутся вам полезны. Прошу под кат.

FAQ.Net — программа для заметок, написанная под Windows на языке C# (.NET Framework 2.0).
История началась с того, что нужна была портативная программа для хранения накопленных знаний (копий статей из интернета, ссылки на статьи, SQL-запросы, программный код, пароли и т.д.), с возможностью быстрого поиска и редактирования документов. За основу интерфейса FAQ.Net был взят интерфейс из CHM-формата (файл справки или руководство о программе).
Так как я специализируюсь на базах данных, то решил все документы хранить в БД, используя встроенную СУБД — SQLite. Создал таблицы и написал интерфейс для работы с БД.

Многие программисты до сих пор создают заметки в текстовых документах, сохраняя их на компьютере и со временем теряют их местонахождение. Теперь, с помощью FAQ.Net все накопившиеся документы, можно хранить в одном месте, не опасаясь за их утрату.
В приложении FAQ.Net имеется возможность резервного копирования БД.

Привет, Хабр! Наши друзья из Softpoint подготовили интересную статью про Microsoft SQL Server. В ней разбирается два практических примера использования полнотекстового поиска:

• Поиск по «бесконечным» строкам (напр., Комментарии) в противовес обычному поиску через LIKE;
• Поиск по номерам документов с префиксами. Там, где обычно полнотекстовый поиск применять нельзя: ему мешают постоянные префиксы. Разбирается 2 подхода: предварительная обработка номера документа и добавление собственной библиотеки-word breaker’а.

Присоединяйтесь!

Доброго дня.

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

Данная ORM имеет порог вхождения выше среднего, поэтому я попытаюсь объяснить всё простым языком и с примерами. Статья будет полезна тем, кто уже работает с sqlalchemy и хочет прокачать свои навыки или только знакомится с этой библиотекой.

Так сложилось, что вот уже который год мне приходится заниматься технической поддержкой хостинга, а также поддержкой сайтов, к которым я имею довольно косвенное отношение. А так как администраторы довольно часто сталкиваются с разного рода атаками на свои сайты, не имея при этом возможности нанять специалиста, мне пришло в голову придумать единое и универсальное решение для всех сайтов, которое бы помогло им защитить свой сайт без особых усилий. И хотя в нем есть еще немало минусов и нюансов, которые мне пока не удалось решить, тем не менее это единственное на данный момент решение, которое позволяет обезопасить сайт изнутри, не обращаясь к разного рода плагинам и модулям, которые нужно устанавливать извне и которое даже малоопытный разработчик сайтов способен установить и настроить у себя на сайте. Суть данного решения заключается в том, чтобы обработать данные переданные методами GET, POST и/или COOKIE, еще до момента обработки и записи их самих непосредственно в базу данных.

В этой статье я приведу примеры использования и недостатки того или иного метода.

Недавно я нашёл интересную уязвимость, позволяющую установить любому пользователю конкретного сайта любой пароль. Круто, да?

Это было забавно, и я подумал, что можно написать интересную статью.

На неё вы и наткнулись.



Примечание: автор переведённой статьи не специалист по информационной безопасности, и это его первый экскурс в мир SQL-инъекций. Он просит быть «снисходительными к его наивности».

Предупреждение: автор переведённой статьи не станет раскрывать сайт с этой уязвимостью. Не потому, что он сообщил о ней владельцу и связан узами молчания, а потому что хочет приберечь уязвимость для себя. Если вы вычислите этот сайт, пожалуйста, держите рот на замке (цыц).

Сообщество Database & Data warehouse приглашает на свой митап, который состоится 26 сентября в офисе Райффайзенбанка в Нагатино

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

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

О результатах проделанной работы я и хочу поделиться в данной статье. Статья будет полезна как администраторам Zabbix, так и PostgreSQL DBA, а также всем желающим лучше понять и разобраться в популярной СУБД PosgreSQL.

Небольшой спойлер: на слабой машине при нагрузке в 200 тысяч параметров в минуту нам удалось снизить показатель CPU iowait с 20% до 2%, уменьшить время записи порциями в таблицы первичных данных в 250 раз и в таблицы агрегированных данных в 32 раза, уменьшить размер индексов в 5-10 раз и ускорить получение исторических выборок в некоторых случаях до 18 раз.

Салют, хабровчане! Поздравляем всех с днем программиста и делимся переводом статьи, который был подготовлен специально для студентов курса «Архитектор высоких нагрузок».



«Шардировать. Или не шардировать. Без попыток.»
— Йода

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

Одно из наиболее важных решений, которые принимает разработчик, заключается в том, какую базу данных использовать. В течение многих лет опции были ограничены различными вариантами реляционных баз данных, которые поддерживали язык структурированных запросов (SQL). К ним относятся MS SQL Server, Oracle, MySQL, PostgreSQL, DB2 и многие другие.

За последние 15 лет на рынке появилось много новых баз данных в рамках подхода No-SQL. К ним относятся хранилища ключей-значений, такие как Redis и Amazon DynamoDB, широкие колоночные базы, такие как Cassandra и HBase, хранилища документов, такие как MongoDB и Couchbase, а также графовые базы данных и поисковые системы, такие как Elasticsearch и Solr.

В этой статье мы попробуем разобраться в SQL и NoSQL, не влезая в их функционал.
Кроме того, мы немного повеселимся в процессе.

Зачем написана статья?

Когда я готовился к OCA и OCP по Java 8, то нашел много статей на Хабре, благодаря которым выбрал оптимальный путь и сэкономил много времени.

Однако по подготовке именно к OCA Oracle Database SQL (1Z0-071) материалов на Хабре нет и в интернете тоже очень мало. Поэтому я решил написать подробную статью, которая поможет заинтересованным потратить меньше времени и успешно сдать довольно объемный экзамен.

Подборка ресурсов по математике, статистике и программированию для начинающих Дата Сайентистов. Ознакомьтесь с материалами, если вы планируете учиться на онлайн-курсах. Так вы опередите одногруппников, а заодно прокачаете полезный навык — изучать дополнительные материалы самостоятельно.

Продолжение статьи Руководство по SQL: Как лучше писать запросы (Часть 1)

От запроса к планам выполнения

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

Следует также отметить, что некоторые из антипаттернов, упомянутых в последнем разделе, коренятся в проблемах производительности, таких, как операторы AND, OR и NOT и их отсутствие при использовании индексов. Размышление о производительности требует не только более структурированного, но и более глубокого подхода.

Однако этот структурированный и углубленный подход будет в основном основан на плане запроса, который, как вы помните, является результатом запроса, впервые проанализированного в «дерево синтаксического анализа» или «дерево разбора» («parse tree»), и точно определяет, какой алгоритм используется для каждой операции и как координируется их выполнение.

В этом материале я хочу подробно показать, как можно при помощи R в Microsoft SQL Server реализовать получение данных из Google Analytics (и вообще из любого API).

Благодарности:

Поскольку я ни разу не маркетолог мне требовалась помощь специалиста. Тестовый кабинет и доступ Google Analytics (GA) организовал Алексей Селезнёв , а также давал дельные консультации.
Он профессионально занимается аналитикой в маркетинге. И в качестве благодарности за помощь упоминается здесь телеграмм канал Алексея, где он ведет свою активность.

Задача — у нас есть сервер MS SQL и мы хотим получать данные в DWH по API

Для подключения к Google Analytics (GA) будем использовать пакет googleAnalyticsR.

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

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

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

FYI: эта статья представляет собой дополненную версию моего доклада на SQA Days #25.

Опираясь на свой опыт общения с коллегами, могу утверждать: тестирование кода в БД не является распространённой практикой. Это может нести в себе потенциальную опасность. Логику в БД пишут такие же люди, какие пишут «обычный» код. Следовательно, там так же могут присутствовать ошибки, и они так же могут повлечь за собой негативные последствия для продукта, бизнеса и потребителей. Неважно, идёт ли речь о хранимых процедурах, помогающих бэкенду, или о ETL, преобразующих данные в хранилище — риск есть, и тестирование может его существенно снизить. О том, что такое tSQLt и как оно помогает нам в тестировании кода в SQL Server, я и хочу вам рассказать.

Описание общей потребности в синхронизации изменений

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

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

Как правило, разработку баз данных ведут в специально выделенной среде. Затем изменения переносят в среду тестирования для проведения различных проверок (юнит-тесты, автотесты, нагрузочные тесты и т д). И только после всех этапов разработки и проверок осуществляют перенос изменений в промышленную среду.

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

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

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

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

Чтобы ответить на вопрос, какую роль играет информация об ошибках ETL, я классифицировал все проблемы, произошедшие за последние два года в немаленьком хранилище.

Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL

Язык структурированных запросов (SQL) является незаменимым навыком в индустрии информатики, и вообще говоря, изучение этого навыка относительно просто. Однако большинство забывают, что SQL — это не только написание запросов, это всего лишь первый шаг дальше по дороге. Обеспечение производительности запросов или их соответствия контексту, в котором вы работаете, — это совсем другая вещь.

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

• Во-первых, вы начнете с краткого обзора важности обучения SQL для работы в области науки о данных;
• Далее вы сначала узнаете о том, как выполняется обработка и выполнение запросов SQL, чтобы понять важность создания качественных запросов. Конкретнее, вы увидите, что запрос анализируется, переписывается, оптимизируется и окончательно оценивается.
• С учетом этого, вы не только перейдете к некоторым антипаттернам запросов, которые начинающие делают при написании запросов, но и узнаете больше об альтернативах и решениях этих возможных ошибок; Кроме того, вы узнаете больше о методическом подходе к запросам на основе набора.
• Вы также увидите, что эти антипаттерны вытекают из проблем производительности и что, помимо «ручного» подхода к улучшению SQL-запросов, вы можете анализировать свои запросы также более структурированным, углубленным способом, используя некоторые другие инструменты, которые помогают увидеть план запроса; И,
• Вы вкратце узнаете о time complexity и big O notation, для получения представления о сложности плана выполнения во времени перед выполнением запроса;
• Вы кратко узнаете о том, как оптимизировать запрос.

В данной статье мы разберемся с эксплуатацией некоторых WEB-узвимостей на примере прохождения варгейма Natas. Каждый уровень имеет доступ к паролю следующего уровня. Все пароли также хранятся в файлах /etc/natas_webpass/. Например, пароль для natas5 хранится в файле /etc/natas_webpass/natas5 и доступен для чтения только для пользователей natas4 и natas5.

Прошлые части: часть 1, часть 2, часть 3 и часть 4.