pptx PPTX, 1 МБ

Мастер класс: Хайлоадблоки использование, 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