Привет Хабр! Мне довелось реализовать бизнес-процесс, который предполагал безопасность на уровне строк (Row Level Security) на mysql и php.



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

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

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

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

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

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

Темой доклада Василия Лукьянчикова является индексирование в MySQL и расширенные возможности EXPLAIN, т.е. нашей задачей будет ответить на вопросы: что мы можем выяснить с помощью EXPLAIN'а, на что следует обращать внимание?

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

По индексам мы пройдемся очень кратко, исключительно в плане того, какие нюансы есть в MySQL, в отличие от общей теории.

Доклад, таким образом, состоит из 3х частей:

• Архитектура;
• Основы индексирования;
• EXPLAIN (примеры).

Как устроена MySQL-репликация

Андрей Аксенов (Sphinx), shodan

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

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

Что такое репликация, в принципе? Это копирование изменений. У нас есть одна копия БД, мы хотим с какой-то целью еще одну копию.

Репликация бывает разных видов. Разные оси сравнения:

• степень синхронизации изменений (sync, async, semisync);
• количество серверов записи (M/S, M/M);
• формат изменений (statement-based (SBR), row-based (RBR), mixed);
• теоретически, модель передачи изменений (push, pull).

Нередко бывает так, что в большом проекте в силу тех или иных причин — зачастую исторических, хотя бывает по-всякому — его части могут использовать различные СУБД для хранения и поиска критически важных данных. В числе прочего, этому разнообразию способствует конкуренция и развитие технологий, но, так или иначе, взаимодействие между СУБД описывает стандарт SQL/MED 2003 (Management of External Data), который вводит определение Foreign Data Wrappers (FDW) и Datalink.

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

Эти две части были реализованы еще в PostgreSQL 9.1 и называются FDW и dblink соответственно. FDW в PostgreSQL сделан максимально гибко, что позволяет разрабатывать wrapper'ы для большого количества внешних источников. В настоящее время мне известны такие FDW, как PostgreSQL, Oracle, SQL Server, MySQL, Cassandra, Redis, RethinkDB, Ldap, а также FDW к файлам типа CSV, JSON, XML и т.п.

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

Друзья, PG Day'16 Russia успешно завершилась, мы перевели дух и уже думаем над тем, как сделать грядущие мероприятия еще более интересными и полезными для вас. Продолжаем публиковать интересные, на наш взгляд, материалы о Постгресе и общаться с вами в комментариях. Сегодня представляем перевод статьи Pat Shaughnessy о том, что из себя представляют индексы в PostgreSQL.

Все мы знаем, что индексы — одна из самых мощных и важных функций серверов реляционных баз данных. Как быстро найти значение? Создать индекс. Что нужно не забыть сделать при объединении двух таблиц? Создать индекс. Как ускорить SQL запрос, который начал медленно работать? Создать индекс.


Но что такое эти индексы? И как они ускоряют поиск по базе данных? Чтобы выяснить это, я решил прочитать исходный код сервера базы данных PostgreSQL на C и проследить за тем, как он ищет индекс для простого текстового значения. Я ожидал найти сложные алгоритмы и эффективные структуры данных. И я их нашёл. Сегодня я покажу вам, как выглядят индексы внутри Постгреса, и объясню, как они работают.

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

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

Предыстория

Есть группа сотрудников, которая занимается обзвоном клиентов. Дабы экономить на исходящих звонках, для разных направлений используются разные номера телефонов. Это спокойно решается с помощью шаблонов (масок) номеров в Outbound Routes. Но часть направлений, например, звонки на мобильные, остается платным. Чтобы в конце месяца счет компании за телефонные услуги не перевалил XXX$, необходимо жестко контролировать и, при необходимости, ограничивать соответствующие направления звонков.

Задача

Установить индивидуальный дневной лимит для группы менедежеров. Запретить исходящие звонки на определенные направления при исчерпании лимита. При достижении пороговых значение: >50%, >90% и >100% отправлять соответствующее уведомление на email сотрудника. Если сотрудник в течении дня полностью не исчерпал свой дневной лимит, остаток должен перейти на следующий день.

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

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

Имея опыт работы над бинарными базами для Sypex Geo, я решил попробовать набросать формат бинарного файла и алгоритм поиска по нему.

17-го июня в инновационном центре “Сколково” прошла очередная ежегодная конференция DevConf, а Badoo в очередной раз снимали видео выступлений. Программа была богата на именитых спикеров и интересные доклады, поэтому сделать подборку из самых «вкусных» выступлений было крайне сложно. Но мы, как минимум, постарались…

Познавательного вам просмотра!

«Развитие ветки PHP-7», Дмитрий Стогов, Zend Technologies

Привет! У нас пора релизов. Это пост о том, что интересного в новой версии DataGrip — нашей IDE для SQL. Эти изменения также касаются IntelliJ IDEA, PyCharm, PhpStorm и RubyMine — тех инструментов от JetBrains, где есть поддержка баз данных.



Вот, что мы добавили:

Надо “SELECT * WHERE a=b FROM c” или “SELECT WHERE a=b FROM c ON *” ?

Если вы похожи на меня, то согласитесь: SQL — это одна из тех штук, которые на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить каждый простой запрос, чтобы найти правильный синтаксис.

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

SELECT members.firstname || ' ' || members.lastname
AS "Full Name"
FROM borrowings
INNER JOIN members
ON members.memberid=borrowings.memberid
INNER JOIN books
ON books.bookid=borrowings.bookid
WHERE borrowings.bookid IN (SELECT bookid
  FROM books
  WHERE stock>(SELECT avg(stock)
    FROM books))
GROUP BY members.firstname, members.lastname;

Буэ! Такое спугнет любого новичка, или даже разработчика среднего уровня, если он видит SQL впервые. Но не все так плохо.

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

После долгих поисков интересующей меня библиотеки на php для связи с MySQL сел и написал свою, наиболее подходящую для использования в проектах. Данная тема займет небольшой цикл статей, который будет полезен не только профессиональным разработчикам веб-приложений, но и начинающим. Следует отметить, что представленная ниже ORM библиотека, которую, кстати, я назвал kitty, является результатом долгих мучений и не является обязательной библиотекой всех проектов.

Библиотека по моему видению должна иметь два файла (по крайней мере на начальных этапах):

• файл библиотеки — kitty.php;
• файл объектного изображения модели базы данных — modeldb.php.

1. Мы в Битриксе очень любим делиться знаниями.
2. Мы любим использовать Percona Server вместо стандартного MySQL.
3. Иногда мы проводим бизнес-завтраки.

Соединив все эти факты вместе, мы решили провести техно-завтрак. :) Специальный гость — Петр Зайцев, директор Percona.

Все желающие совершенно бесплатно могут участвовать в онлайне — смотреть, задавать вопросы. Регистрируйтесь и отмечайте у себя в календарях 13 июля. :)

Подробности — под катом.

1. Для чего это нужно?

Предположим, у вас есть приложение, которое ведет запись журналов событий в базу данных(например, Kaspersky Security Center, Symantec Endpoint Security Server, и многие другие) и вы хотите собирать эти журналы с помощью SIEM системы Alienvault OSSIM (USM), но в поставке «из коробки» OSSIM не умеет собирать и парсить логи Вашего приложения.

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

До конференции PG Day'16 Russia остались считанные дни, расписание можно посмотреть на нашем сайте. Мы трудимся в поте лица, но тем не менее успеваем готовить для вас переводы самых интересных материалов о PostgreSQL. Сегодня представляем вашему вниманию перевод статьи Pat Shaughnessy о поведении запроса Select.

Готовясь летом к этой презентации, я решил изучить некоторые части исходного кода PostgreSQL на C. Я запустил очень простой запрос select и наблюдал, что Постгрес с ним делает, с помощью LLDB, отладчика C. Как Постгрес понял мой запрос? Как он нашел данные, которые я искал?



Этот пост — неформальный журнал моего путешествия через внутренности PostgreSQL. Я опишу пройденный мной путь и то, что я видел в процессе. Я использую серию простых концептуальных диаграмм, чтобы объяснить, как Постгрес выполнил мой запрос. В случае, если вы понимаете C, я также оставлю вам несколько ориентиров и указателей, которые вы можете поискать, если вдруг решите покопаться во внутренностях Постгреса.

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

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

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

Приходят пользователи и просят: «Вот мы внесли данные в базу, а скажите нам, чего не хватает? Какие данные мы ещё не внесли в базу и их не хватает для полного счастья?»
Первая (и скажем честно, весьма глупая) реакция: «Как же я вам найду то, чего нет в базе данных?».

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

Периодически при разработке какого либо проекта требуется сгенерировать данные в таблицах, чтобы потом прогнать по тестам для оценки производительности работы (используются или нет индексы, как долго исполняется запрос при большой выборке и т.д.). Для этого обычно берется реализованная функциональность API (функции) (php, node.js и т.д.) проекта и прогоняются через CLI для заполнения данными таблиц (insert). Неудобство заключается в том, что нельзя это сделать по быстрому.

Предыстория

Есть небольшой сервер, на котором крутится стандартный LAMP. Все началось с того, что подходит ко мне QA и говорит: «Есть тема, мне нужно перепроверить регистрацию пользователей, можешь удалить старый аккаунт?», «Не вопрос» — ответил я. Суть в том, вход у нас сделан только через социалки. Что бы не нарушать целостность базы удалением аккаунта, я решил просто взять и переименовать UID (пользовательский ID в конкретной социальной сети) в таблице.
Так как UID у всех разный (vk, facebook, google… — числовой UID, linkedin — строковый UID) был использован VARCHAR для хранения. В итоге я добавил символ нижнего подчеркивания `_` к строке, и со спокойной душой отписался: «Проверяй...».