Мастер класс: Хайлоадблоки - использование, NoSQL

Александр Сербул

Руководитель направленияконтроля качества интеграции и внедрений 1С-Битрикс

ACID, SQL

С конца 70 г.г., «Джим» Грей

Эдгар Кодд, Кристофер Дейт

Atomicity — Атомарность

Consistency — Согласованность

Isolation — Изолированность

Durability — Надежность

NoSQL – как все начиналось

Dynamo (Amazon, =< 2007)

Cassandra (Facebook, 2009)

MongoDB (2009)

Redis (2009)

…

NoSQL – «плавающие» схемы данных

NoSQL – «страшные архитектуры»

NoSQL – распределенные алгоритмы

Werner Vogels - VP and CTO of Amazon.com

Теорема CAP (Брюера)Проф. Эрик Брюер, 2000, University of California at Berkeley

Согласованность данных (Consistency) — во всех

вычислительных узлах в один момент времени данные не

противоречат друг другу

Доступность (Availability) — любой запрос к

распределённой системе завершается корректным

откликом

Устойчивость к разделению (Partition tolerance) —

расщепление распределённой системы на несколько

изолированных секций не приводит к некорректности

отклика от каждой из секций

Теорема CAP - CA

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

доступность, жертвует устойчивостью к распаду на секции. Такие

системы возможны на основе технологического программного

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

Примерами таких систем могут быть решения на основе кластерных

систем управления базами данных или распределённая служба

каталогов LDAP.

Теорема CAP - CP

Распределённая система, в каждый момент обеспечивающая

целостный результат и способная функционировать в условиях

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

Устойчивость к распаду на секции требует обеспечения

дублирования изменений во всех узлах системы, в этой связи

отмечается практическая целесообразность использования в таких

системах распределённых пессимистических блокировок для

сохранения целостности

Теорема CAP - AP

Распределённая система, отказывающаяся от целостности

результата. Большинство NoSQL-систем принципиально не

гарантируют целостности данных, и ссылаются на теорему CAP как

на мотив такого ограничения.

Задачей при построении AP-систем становится обеспечение

некоторого практически целесообразного уровня целостности

данных, в этом смысле про AP-системы говорят как о «целостных в

конечном итоге» (eventually consistent) или как о «слабо целостных»

(weak consistent)

DNS, Web Caches, NoSQL …

NoSQL – поможет ли?

Риски:

Eventual consistency

Агрессивная денормализация

Проблемы со сложными запросами

Усложнение приложения-клиента

HandlerSocket

Автор:

Akira Higuchi

DeNA Co., Ltd.

2010 год

WebApp + memcached

WebApp + HandlerSocket

Архитектура Хайлоадблоков

Отдельные таблицы БД

Свои индексы

D7: стандартизированные интерфейсы (Table Data Gateway):

сущность (Bitrix\Main\Entity\Base) 

поля сущности (Bitrix\Main\Entity\Field и его наследники) 

датаменеджер (Bitrix\Main\Entity\DataManager)

Полезные книжечки

Изучайте истории успеха

Разбирайтесь в архитектуре

Используйте подходящие проекту

решения

Ищите готовые примеры в Bitrix

Framework, D7

Table Module

“A single instance that handles the business logic for all rows in a

database table or view”

Table Data Gateway

“An object that acts as a Gateway to a database table. One instance

handles all the rows in the table”

Настройка подключения к HandlerSocket

Ставим PerconaServer или MariaDB или:

1) Качаем исходники MySQL

2) Собираем плагин HandlerSocket

Настраиваем «/bitrix/.settings.php»

Архитектура Хайлоадблоков

\Bitrix\Main\Loader::includeModule( 'highloadblock' );

use Bitrix\Highloadblock as HL;

use Bitrix\Main\Entity;

$hlblock = HL\HighloadBlockTable::getById( 1 )->fetch();

$entity = HL\HighloadBlockTable::compileEntity( $hlblock ); //генерация класса

$entityClass = $entity->getDataClass();

$result = $entityClass:: add / update / delete / getList/ getById

Хайлоадблоки и HandlerSocket

…

1) $obj = $entityClass::getById( $arData["ID"] )->fetch();

2) Вызов API HS:

open_index

find

3) Обработка результата приложением

Работает для ЛЮБЫХ сущностей!Bitrix\Main\UserTable::getById(1);

Снижение нагрузки на MySQL и сеть.

Хайлоадблоки и бизнес-логика

Наследуем от класса сущности Хайлоадблока:

$hlblock = HL\HighloadBlockTable::getById( # )->fetch();

$entity = HL\HighloadBlockTable::compileEntity( $hlblock ); //генерация класса

$entityClass = $entity->getDataClass();

class MyDomainObjectTable extends #entityClass# {

…//наша бизнес логика проекта

}

Хайлоадблоки/HandlerSocket

Плюсы:

Низкие накладные расходы (PHP, меньше запросов SQL)

Низкий риск блокировок в БД (свои таблицы)

Тысячи, миллионы сущностей, справочники

Снижение нагрузки на БД, хостинг

Highload проекты, системы с большим объемом информации

Спасибо за внимание! Вопросы?

Александр Сербулserbul@1c-bitrix.ru@AlexSerbul