Предисловие

В этой серии статей речь пойдет об индексах в PostgreSQL.

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

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

В этой части мы поговорим про разделение сфер ответственности между общим механизмом индексирования, относящимся к ядру СУБД, и отдельными методами индексного доступа, которые в PostgreSQL можно добавлять как расширения. В следующей части мы рассмотрим интерфейс метода доступа и такие важные понятия, как классы и семейства операторов. После такого длинного, но необходимого введения мы подробно рассмотрим устройство и применение различных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.

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

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

Microsoft SQL Server давно нашел свое место в семействе продуктов Яндекс.Денег и успешно решает задачу сбора разрозненной информации обо всех операциях из множества отдельных сервисов. Без такой сборки воедино нельзя было бы отследить платеж, собрать статистику или решить проблему.

Все сказанное далее будет полезно администраторам крупных БД – тем, кто заботится о быстрой и точной работе аналитики Microsoft SQL Server 2012-2014.

Если информация окажется вам полезной и интересной — обязательно дайте знать в комментариях, чтобы автор не расслаблялся.

Цель статьи – показать применение шаблонов Remote Facade и Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Суть проблемы

В системах электронного обучения (СЭО), используемых в образовательных учреждениях, часто требуется помимо подключения электронного курса к СЭО, также импортировать его отдельные компоненты для формирования единых банков образовательных ресурсов. Такие банки используются в образовательном процессе, в том числе для создания междисциплинарных спецкурсов, итоговых тестирований по всему периоду обучения. Как правило, это в первую очередь тестовые задания, изображения, мультимедийные компоненты. Некоторые элементы контента, в частности тестовые задания, созданные без использования машиночитаемых форматов (CSV, JSON, XML, XLS), не поддаются эффективному автоматизированному импорту в СЭО. Особенно это касается HTML/CSS/JavaScript, применяемых в контейнере для электронных курсов и публикаций ePUB. Для решения этой задачи автором предлагается использовать описания тестов и отдельных тестовых вопросов в составе курса в машиночитаемом формате XML в соответствии со спецификацией IMS Question and Test Interoperability v.2.2 (IMS QTI).

Пару слов о ePUB v.3

ePUB версии 3, разработан ассоциацией IDPF и является стандартом для обмена и дистрибуции электронных публикаций. ePUB получил широкое распространение среди издателей электронных учебников и курсов. Формат поддерживается на большинстве мобильных платформ, и лег в основу ряда других подобных форматов, например, ibooks компании Apple.

Рисунок 1. Структура EPUB-контейнера

Недавно столкнулся с одним приложением, которое генерировало запросы к БД. Я понимаю, что этим никого не удивишь, но когда приложение стало тормозить и мне пришло задание разобраться в чём причина, я был сильно удивлён, обнаружив эти запросы. Вот с чем иногда приходится иметь дело SQL Server:

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

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

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

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

Python DB-API – это не конкретная библиотека, а набор правил, которым подчиняются отдельные модули, реализующие работу с конкретными базами данных. Отдельные нюансы реализации для разных баз могут отличаться, но общие принципы позволяют использовать один и тот же подход при работе с разными базами данных.

В статье рассмотрены основные методы DB-API, позволяющие полноценно работать с базой данных. Полный список можете найти по ссылкам в конец статьи.

Требуемый уровень подготовки: базовое понимание синтаксиса SQL и Python.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Добрый день! Я — инди-разработчик (с недавнего времени), 2 года назад, будучи пожарным, пришла в голову мысль создать свою игру на Android. Из опыта было только создание карт под игровые движки Gold Source и Source (на них построены старые добрые: Counter-Strike, Half-Life и многое другое), взяв волю в кулак, решил что я обязательно справлюсь и занялся штудированием интернет-поисковика Google.

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

Осторожно, под катом gif-изображения.

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

1. Safe-mode & Win10
2. Циклическая перезагрузка при установке обновлений.

Хороший перебор — это отсутствие перебора. Рассмотрим пример замены полного перебора запросом.

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

Запрос специально привожу на T-SQL, т.к. думаю, что Хабравцам это будет ближе.

Ранее в статье Становимся контрибьютером в PostgreSQL был подробно рассмотрен процесс разработки PostgreSQL и используемые при этом инструменты, были предложены некоторые идеи для первого патча и рассказано, куда и как эти патчи нужно посылать. Также были приведены ссылки на дополнительные источники информации касательно внутреннего устройства РСУБД.

Теперь же мы рассмотрим примеры реальных патчей, принятых в PostgreSQL за последнее время. Какие-то из этих патчей были написаны непосредственно мной, при разработке других я активно участвовал в качестве ревьювера. Это сравнительно небольшие патчи. На момент написания этих строк я занимаюсь разработкой PostgreSQL менее года, и ранее разработкой СУБД я не занимался (ровно как и разработкой на языке C за деньги). Поэтому есть основания полагать, что данные патчи будут интересны новичкам, желающим начать участвовать в разработке открытых проектов, притом не обязательно именно PostgreSQL. Чтобы не писать лонгридов, статья разбита на части.

Заинтересовавшихся прошу проследовать под кат.

Масштабирование базы данных через шардирование и партиционирование

Денис Иванов (2ГИС)

Всем привет! Меня зовут Денис Иванов, и я расскажу о масштабировании баз данных через шардирование и партиционирование. После этого доклада у всех должно появиться желание что-то попартицировать, пошардировать, вы поймете, что это очень просто, оно никак жрать не просит, работает, и все замечательно.

Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.

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

Думаю, многим знакома такая разновидность веб-форумов, как имиджборды. Да-да, вы правильно поняли — именно на примере имиджборды я расскажу об опыте создания сайта на C++. Что же сподвигло меня заняться столь сомнительной пользы проектом? Левая пятка. В этом случае действительно никаких особых причин не было. Просто проснулся однажды утром и понял — хочу. Но это все лирика.

На Хабре хватает статей о веб-сайтах на C++: например, с использованием FastCGI или CppCMS. Но все это — HelloWorld'ы и туториалы. Я же вам расскажу о полноценном (пусть и не идеальном с точки зрения архитектуры и чистоты кода) проекте, постараюсь осветить различные тонкости.

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

Наша компания Wild Apricot занимается разработкой ПО (SaaS), которое работает на ASP и .NET, а в качестве базы данных использует MS SQL Server. Поэтому львиная доля инфраструктуры у нас работает под управлением Windows, преимущественно Server 2012 R2. Соответственно, отделу сисопов периодически приходится поднимать новые машины с ней, а иногда и разворачивать целые фермы, как на живом окружении, так и на тестовом. В настоящее время у нас порядка 20 гипервизоров и, соответственно, более сотни разнообразных машин, из которых абсолютное большинство — это ВМ с Windows. Сейчас планируется установка ещё полудюжины девелоперских окружений, каждое из которых состоит из десятка компонент, которые желательно изолировать друг от друга. Для решения подобных задач мы и задумали автоматизацию всего процесса. Описание всего пути я сделал довольно детальным, так что статья разрослась и поэтому я решил разделить её на три части. В этой части я постараюсь затронуть общие вопросы, объяснить выбор инструментов и рассказать, как подготовить окружение для дальнейшей работы.

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

Корни истории уходят в те годы, когда один из кланов древней текстовой игры «Бойцовский клуб» заказал у меня, молодого программиста на Perl, капчу для игры. Пара бессонных ночей — и четыре ровных цифры готовы вместе с проверкой ввода.



Через несколько дней пришёл другой, не менее уважаемый клан, и заказал парсер той самой капчи. Для её разбора пришлось потратить гораздо больше времени, никакого Ocrad тогда ещё не было, но был найден очень простой и рабочий способ.

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







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

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

Данную задачу в Linux призвана решать стандартная связка программ GDB и gdbserver. Идея в том, что пишешь на компе программу (host в терминологии GDB), компилируешь её и заливаешь на целевое устройство (target). Далее запускаешь на целевом устройстве (target) отлаживаемый файл и gdbserver, а на хосте GDB и вперед.

В этом посте я постараюсь окончательно разобрать такие тонкие понятия в C и C++, как указатели, ссылки и массивы. В частности, я отвечу на вопрос, так являются массивы C указателями или нет.

Обозначения и предположения

• Я буду предполагать, что читатель понимает, что, например, в C++ есть ссылки, а в C — нет, поэтому я не буду постоянно напоминать, о каком именно языке (C/C++ или именно C++) я сейчас говорю, читатель поймёт это из контекста;
• Также, я предполагаю, что читатель уже знает C и C++ на базовом уровне и знает, к примеру, синтаксис объявления ссылки. В этом посте я буду заниматься именно дотошным разбором мелочей;
• Буду обозначать типы так, как выглядело бы объявление переменной TYPE соответствующего типа. Например, тип «массив длины 2 int'ов» я буду обозначать как int TYPE[2];
• Я буду предполагать, что мы в основном имеем дело с обычными типами данных, такими как int TYPE, int *TYPE и т. д., для которых операции =, &, * и другие не переопределены и обозначают обычные вещи;
• «Объект» всегда будет означать «всё, что не ссылка», а не «экземпляр класса»;
• Везде, за исключением специально оговоренных случаев, подразумеваются C89 и C++98.

Указатели и ссылки

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

int x;
int *y = &x; // От любой переменной можно взять адрес при помощи операции взятия адреса "&". Эта операция возвращает указатель
int z = *y; // Указатель можно разыменовать при помощи операции разыменовывания "*". Это операция возвращает тот объект, на который указывает указатель