Васильчук Сергей Петрович — 11Рассо Философия системы.
распределённая асинхронная система секретарь обработка
distributed asynchronous system Secretary processing
http://habrahabr.ru/company/moysklad/blog/116379/
===============================
http://1cv8.net.ua/opyat_uperlis_v_platformu_mrachnie_razdumya_o_proizvoditelnosti.html
http://www.sql.ru/forum/actualthread.aspx?bid=53&tid=597910&pg=13
===============================
Событийно ориентированная система, с поддержкой логики конечных автоматов — отслеживающих состояние граничных параметров.
на одной и той же аппаратной конфигурации (один компьютер с двухъядерным процессором) H-Store показала производительность, в 82 раза превышающую производительность традиционной СУБД
Поскольку все фрагменты транзакций, адресуемые одному разделу базы данных, выполняются в одном потоке управления, нет потребности в менеджере блокировок, доступ к которому производился бы из разных потоков управления
http://citforum.ru/database/articles/kuz_oltp_2010/5.shtml
Тем самым, нет потребности в какой-либо синхронизации доступа к структурам данных, разделяемым между несколькими потоками управления. К полностью детерминированной схеме выполнения транзакций.
http://arbinada.com/main/node/120
Распределенная база данных (DDB – distributed database)
ACID как в БД.
с гарантированным восстановлением любого состояния системы.
С опровержением теории C: Consistency A: Availability P: Partition-tolerance
Части системы
Основная
Оперативная
Резервная копия
OLTP Работает с Оперативной затем передаёт управление в другую оперативную, сама пишет в основную.
Время передачи последнего состояния OLTP как разницы между последним состоянием основной и оперативной минимально.
Падение Availability минимально.
————————————————————:
В основной памяти недорогой массивно-параллельной системы уже сейчас можно разместить базу данных объемом до одного терабайта. Этого достаточно для большинства приложений OLTP. Поэтому будущее за системами транзакционных баз данных, полностью размещаемых в основной памяти.
В любой СУБД, ориентированной на поддержку OLTP, потребуется согласованная репликация данных
В системах OLTP транзакции являются очень легковесными. При работе с базой данных в основной памяти время выполнения наиболее тяжелой транзакции из тестового набора TPC-C составляет менее одной миллисекунды. В большинстве приложений OLTP при выполнении транзакций отсутствуют задержки по вине пользователей. Поэтому имеет смысл выполнять все операции каждой транзакции последовательно в одном потоке управления (если транзакция не затрагивает данные нескольких узлов – С.К.)
Или архитектура позволяет проводить транзакции для нескольких узлов. (Без блокировки, с репликацией, согласованностью).
Следующим по значимости узким местом системы является вызов в ней операций и возврат результатов в приложение. Наиболее эффективным способом решения этой проблемы является выполнение логики приложений в виде хранимых процедур внутри системы баз данных. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Философия системы.
Цель – экономия сетевых соединений с БД. Уменьшить время выделяемое — транзакции, на время необходимое, для полезной работы. Никакой исполняемый поток (Thread), не ждёт разблокировки. Транзакции стартуют асинхронно. Но архитектура — переупорядочивает выполнение конкурирующих МТВ ПВИН. Тики дополняют возможности синхронизации. Изначально асинхронный старт транзакций — в распределённой системе, особенно подвержен, ситуации — когда транзакция начавшаяся исполнятся раньше, добирается до данных позже.
Гибкая система позволяющая перенести обработку данных ближе к исполнителю (территориальная разнесённость, меньшая уязвимость к сетевым сбоям). Решение этого вопроса. При территориальной разнесённости складов, и ненадёжных линиях связи, две засады. Сделаешь 1 центральный сервер – связь оборвалась, склад не работает. Для любых задач локальная, отгрузка – приём товара. Распределённая БД, замучаешься реплицировать – синхронизировать. Эволюция систем – «Эталон». Добавим сначала возможность дилерам через веб интерфейс резервировать товар. Кол-во соединений (БД ВЕБ), вырастет в 10 раз легко. Сколько продавцов, а сколько клиентов. Веб розница ещё раз в 10. Реализовать автоматическую сверку цен и складов для поставщиков (Торговля не купленным товаром) – всё полный крах никто не работает. Дело уже в платформе – маячит мэйнфрейм.
Традиционный клиент – сервер, это аналог магазина самообслуживания. Все бегают, хватают, товары. Сначала схватят, потом на кассе выясняется, что денег нет, или ещё что-то мешает.
Моя система товары почтой. Как пишут форму, которая посылает запрос к БД. Установили по команде соединение с БД, послали запрос, получили ответ – работаем. Простой вопрос, а для чего открытое соединение с БД держать, З А Ч Е М.
Новизна состоит в разрывах потоков управления. Передали просьбу — разорвали. Поставили резерв — забыли. В распределённой среде — а по моему глубокому убеждению, многоядерный процессор, кластер, «Облако», распределённая БД: отличаются — только «стоимостью» передачи информации. Ведь в любом случае — клиент и сервер разнесены. Между изменением информации, и принятием решения — о борьбе за ресурс, происходит разрыв во времени, отличающийся на порядок. Веб магазин за 1 секунду продаёт 100 товаров. Даже если принять время реакции системы, в 0,25 сек. (очень идеализированно), это БД должна отправлять все изменения клиенту, а он успевать реагировать. Транзакция как понятие переносится из потока, который его инициировал, в УЗЛЫ. Образно говоря, где то клиент нажал кнопку, на сервере запустилась хранимая процедура, в проекте DORA почти навечно. И вся логика, часто вложенные процедуры, запросы всё висит в одном потоке. Ответ клиенту, из того же потока. Вместо много клиентов запускают транзакции — а потом разбираемся, с доступностью ресурсов. Много узлов принимают сообщения, что хочет, клиент. И будучи безраздельным хозяином, у себя в вотчине, никогда не полезет к ресурсу, который уже недоступен. Необходимость в блокировках, откатах возникает только в местах межузлового взаимодействия — ПВИН. Благодаря тикам, узлы могут договориться, о порядке разрешения любых взаимоблокировок.
Стартовав, порядок выполнения не блокирующий друг друга.
==========================
Ответственность
Правило никакой модуль системы не несёт конечной ответственности, за все уровни ACID.
Системный, БД, Логический. Нельзя ответственность за «сбой», перекладывать на плечи «модуля», который делает какую-то операцию, он не только может засбоить. Но и всегда неизвестно окружение процесса.
Брювер даже противопоставляет набор свойств ACID предлагаемому им набору свойств BASE
Basically Available, Soft-state, Eventual consistency – доступность в большинстве случаев; неустойчивое состояние; согласованность в конечном счете
Термин мгновенная согласованность immediate consistency.
Согласованность в конечном счете (eventual consistency), или-
Согласованность – «Контрактная», всё в конечном счёте. Рано или поздно. И извиняемся, извиняемся.
Во всех возможных случаях следует отказаться от поддержки и журнала откатов транзакций, поскольку он тоже будет сдерживать производительность
рационализацией согласованности (consistency rationing)
В асинхронной модели сети невозможно реализовать объект данных с операциями чтения и записи, гарантирующий обеспечение свойств доступности и атомарной согласованности для всех допустимых выполнений (включая те, в которых теряются сообщения).
Брювером) Гильберт и Линч
Как считает Майкл Стоунбрейкер [12-13], залогом построения качественной современной СУБД является правильный выбор технических компромиссов. При выборе конкретного инженерного решения нужно учитывать множество факторов – требования будущих пользователей, вероятности возникновения различных сбойных ситуаций и т.д., а не руководствоваться догматическим образом каким-либо общими теоретическими указаниями (в том числе, и «теоремой» CAP).
проект DORA [15], в котором оригинальным образом сочетаются подходы shared-everything на физическом уровне архитектуры СУБД и shared-nothing на логическом уровне.
Эти соображения приводят к следующим выводам.
Основным препятствием для достижения высокой производительности системы почти наверняка станет журнал повторного выполнения операций, сохраняемый в дисковой памяти. Без него можно обойтись за счет подсистемы поддержки высокого уровня доступности и обработки отказов.
Следующим по значимости узким местом системы является вызов в ней операций и возврат результатов в приложение. Наиболее эффективным способом решения этой проблемы является выполнение логики приложений в виде хранимых процедур внутри системы баз данных.
Во всех возможных случаях следует отказаться от поддержки и журнала откатов транзакций, поскольку он тоже будет сдерживать производительность.
Следует приложить все усилия, чтобы максимально освободиться от затрат на синхронизационные блокировки.
Желательно освободиться и от синхронизации на основе «защелок» при доступе к одним и тем же структурам данных из нескольких потоков управления. С учетом кратковременности транзакций эти накладные расходы можно устранить путем перехода к однопотоковой модели выполнения транзакций.
По мере возможности следует избегать применения двухфазного протокола фиксации распределенных транзакций
Протоколам управления параллелизмом в системах баз данных исторически свойственно порождение недетерминированного поведения. Эти протоколы традиционно допускают параллельное выполнение нескольких транзакций, чередуя их операции чтения из базы данных и записи в базу данных и обеспечивая при этом эквивалентность результирующего состояния базы данных такому состоянию, которое было бы получено при выполнении этих транзакций в некотором последовательном порядке. В этой фразе ключевым модификатором является слово некоторый. Никогда заранее не известно, какой именно порядок выполнения транзакций будет обеспечиваться алгоритмом сериализации транзакций; он зависит от большого числа факторов, полностью ортогональных к порядку реального поступления транзакций в систему, частности, от следующего:
планирования процессов и потоков управления;
управления буферами и кэшем;
сбоев аппаратуры;
изменяющейся задержке сети;
схем разрешения тупиковых ситуаций.
Недетерминированное поведение в системах баз данных приводит к трудностям при реализации репликации баз данных и горизонтально масштабируемых распределенных баз данных. Обсудим эти проблемы по порядку
согласованность реплик;
корректность всех реплик;
низкие накладные расходы.
Транзакционная модель построена на основе так называемого multi-version concurrency control (MVCC)
===============================
===============================
Правило – свойства принадлежат только тому, кому они принадлежат. Слишком часто при создании логической модели для БД, свойства и атрибуты объектов назначают не им, а комплекту. Чем сразу теряется соответствие. Пример – Автомобиль – 5скоростей передач. Вообще-то передачи только в коробке.
++++++==============
Менеджер блокировок или менеджмент транзакций.
Узел – представление потока, как ядра процессора.
Набор узла. Отрезок данных, над которыми выполняются операции read write.
Один набор – один узел. Как в магазине, много покупателей 1 продавец, на отдел.
Секретарь принимает заказы, регистрирует заявку в системе, выдаёт уникальный номер заявки.
Сверяет заявку с последними обновлениями, переупорядочивает очерёдность.
Передаёт заявку Менеджеру транзакций. От него поступают сообщения узлам. Только узел инициирует транзакцию. Благодаря сочетанию «тиков», и «пылесосов», появляется третий путь.
… , что если возможны длительные задержки при выполнении какой-либо транзакции, то детерминированная схема приводит к быстрому «загромождению» системы блокированными транзакциями и резкому падению производительности. Поэтому, в частности, детерминированная схема непригодна для СУБД, работающих с базами данных в дисковой памяти. Однако в системах, обрабатывающих данные исключительно в основной памяти, ситуация меняется …
Старт многозвенной, распределённой транзакции, можно привязать, к моменту освобождения ресурсов.
В такой архитектуре вообще нет жёсткой необходимости не только тратить ресурсы на поток соединения с сервером. Но и на транзакцию – транзакции.
===================================
++++++==============
Отсутствие феноменов в последовательной истории.
Тотальная воспроизводимость результатов и состояний системы.
Концептуальный контроль над распределением ресурсов.
Заранее известный, и управляемый порядок обращений к памяти, дискам, сетевым ресурсам и т.д.
возможность упорядочивать все виды операций для наивысшей эффективности.
===============================
===================================
Неповторяющиеся ошибки СУБД. СУБД «падает», но при работе с репликой данных, вроде бы, все в порядке. Так часто случается при наличии асинхронных операций, и подобные ошибки называют «гейзенбагами» (Heisenbug) [2]
===============================
===============================
Продажа товара.
Продавцом.
Прочитать от публикатора склад.
Подготовить документ основание.
Включить при необходимости условия (всё или ничего, «или или», максимальное время актуальности заказа). Зарегистрировать документ основание, у секретаря. Координатором может выступать секретарь, координатор, узел первый принявший сообщение. Разберём координатор – узел, первый принявший от секретаря. В любом случае Секретарь знает координатора.
Координатор определяет следующего получателя.
В случае кредита свериться с карточкой клиента (узлом), не превышен ли кредитный лимит. При превышении реализуется Пылесос кредитный лимит. Узел карточка клиента, запоминает связь, любое изменение величины доступного кредита, стартует транзакция. Или превышен лимит ожидания. В случае «или или», необходим повторный запрос выбора товара. Документ основание есть, кредитный размер позволяет объявить уменьшение кредита для покупки. Товар доступен — продано. Нет товара, а время актуальности позволяет, Пылесос товар. Реализуется на узле, отвечающем за товар. При превышении лимита времени, каждый узел сам снимает неактуальный резерв, избавляется от транзакций потерявших актуальность. Узел карточка кредита сам сформирует баланс по клиенту, и вернёт «в пул» сумму допустимого кредита.
Продаём.
Секретарь отсылает узлу, отвечающему за кредитную историю просьбу зарезервировать на время сумму необходимую для продажи. Узел кредитная история, отсылает узлу товар заказ на товар. Узел товар меняет владельца. Срабатывает триггер — Пересчитать карточку клиента (Баланс), Триггер отгрузка состояние. Публикатор публикует, благодаря документу основанию (заказ), абсолютно прозрачна для пользователя связь, с расходной накладной. Ответственный за заказы не формирует запрос — заказы, ожидающие освобождения товара, а сразу получает через публикатор, сообщение.
———————————————————
=================================
Территориальный склад.
Особенно актуально для наших реалий. Чем дальше от центра, тем хуже интернет.
http://1cv8.net.ua/opyat_uperlis_v_platformu_mrachnie_razdumya_o_proizvoditelnosti.html
Главная задача узла склада – приём выдача товара. В случае отказа связи, не может продавать локально товар. Или предусмотрен, выделенный диапазон резерва склада, становящийся актуальным в случае разрыва связи.
Может выделяться динамически. Для особо одарённых случаев можно предусмотреть «ручную синхронизацию», по телефону.
В момент восстановления связи, сначала узел, подхвативший продажи со склада – передаёт проданное. Продолжая обрабатывать заказы. Затем при синхронизации всех резервов, передаёт обратно управление продажами на склад.
=====================================================
Логическое Транзакционное Несоответствие ( особенно с «историческими данными» ) ЛТН(ИД).
Разница между временем начала транзакции с точки зрения БД, и пользователя — может привести к ЛТН(ИД).
Пользователь П1 начинает транзакцию — например заполняя данными документ , проходя все необходимые проверки безопасности, отвечая на диалоговые окна. Только после нажатия сохранить — «начали» выполняется код транзакции. В критически важных областях полезно дать возможность устанавливать «время действия транзакции». П1 — руководитель оптовой фирмы снижает кредитный лимит для фирмы «Ф1». В этот момент менеджер выписывает товар в кредит. С точки зрения БД, всё корректно. Транзакция менеджера завершилась до транзакции начальника. Формально начальник начал вбивать данные до выписки товара.
Понятие блокировка логически усложняется. Всегда необходимо помнить о «историчности данных».
Понадобится синхронизационная метка «последняя актуальная».
Проще всего реализовывать через все версии консолидационных документов.
Два варианта реализации «исторических данных».
Как все.
Всего две ветви. Журнал изменений (Реплика).
Отдельно хранить «Документ основание» изменений.
Как я.
Чтобы не выполнять каждый раз запроса max Date.
Три ветки
1 «последняя актуальная».
«Консолидационный документ».
Исключение. Пример, имеем базу огромного комбината 10 000 работников.
За 10 лет работы 500 материально ответственных, меняло фамилию.
Проще в модуль, который отвечает за редактирование данных вставить возможность его принудительной блокировки извне. Материализованное представление.
Некотрые особенности репликации, в «историчности данных».
Изменение значений. Добавление новых данных.
Благодаря нашему AutoIncrement, все записи создаются заранее. В случае применения «исторических данных», Update означает добавление новой записи, с тем же ID но новой датой. Потом репликация. Любое чтение только из реплики. Тики гарантируют согласованность. Без необходимости блокировки записи.
===============================
Репликация.
За заранее согласованный «Тик», необходимо собрать все Update, отсортировать по времени, отослать на реплицируемый узел. 100% согласованная система.
===============================
http://citforum.ru/gazeta/154/
C: Consistency (согласованность). Цель состоит в том, что позволить многоузловым транзакциям иметь знакомую семантику «все – или — ничего», обычно поддерживаемую коммерческими СУБД. Кроме того, в тех случаях, когда поддерживаются реплики, можно было бы пожелать, чтобы реплики находились в согласованном состоянии.
A: Availability (доступность). Цель состоит в поддержке СУБД, которая всегда находится в состоянии готовности. Другими словами, если происходит какой-либо сбой, система должна оставаться работоспособной, переключаясь при надобности на какую-нибудь реплику. Это свойство популяризировалось компанией Tandem Computers более 20 лет тому назад.
P: Partition-tolerance (устойчивость к разделению). Если возникает сбой в работе сети, приводящий в расщеплению узлов обработки на две группы, которые не могут общаться, то цель состоит в том, чтобы допустить возможность продолжения обработки в обеих этих группах.
—————————————————————
Производительность CPU, объём оперативной памяти и систем ввода вывода дешевые, и дешевеют. Производительность системной шины нет, и перспективы туманные.
=================
2.2. Уровни изолированности в ANSI SQL 2009 г.
http://citforum.ru/database/classics/SQL_critiques/
Разработчики ANSI SQL дали такое определение изолированности, которое допускает широкий спектр механизмов реализации, не только механизм блокировки. Они определили изолированность с помощью следующих трех феноменов (phenomena):
P1 (грязное чтение, Dirty Read):
++++++==============
Serg_p 