Васильчук Сергей Петрович — 11Рассо Философия системы 2

Васильчук Сергей Петрович — 11Рассо Философия системы 2.

11РАССО ФИЛОСОФИЯ СИСТЕМЫ 2

• 18 дек, 2012 at 11:25 AM

Оригинал взят у serg70p в 11Рассо Философия системы

распределённая асинхронная система секретарь обработка
distributed asynchronous system Secretary processing

           _____________ ЦЕЛЬ +++++++++++++++

Транзакция, выполняемая на уровне изолированности на основе моментальных снимков Snapshot Isolation

Моя версия

Т1 вычисляет cyclic redundancy check

тогда блокировка данных

Вариант 2

T1 вычисляет сумму

из 10 000 000 ПЕР

T2 хочет изменить значение Пер 3 + 10

в конце T1 добавить10

главное здесь тики.

для потоковых приложений, в которых потоки существуют бесконечно, и отсутствует понятие «конца таблицы»

Вариант 3

T1 выполняет запрос select from wheare p1 like «ab*»

T2 желает изменить значение ПЕР

если не противоречит T1 — меняй. Было absol стало abcok. (зачем блокировать)

Последовательная консистентность — модель консистентности, в которой результат выполнения должен быть тот же, как если бы инструкции операторов всех процессов выполнялись в некоторой последовательности, определяемой программой для этого процессора. При параллельном выполнении все процессы должны видеть одну и ту же последовательность записей в память (разрешаются запаздывания для чтения) Впервые она была определена Лампортом в 1979году.

====================

Сравнение ТЗ веб магазина и КИС http://ru.wikipedia.org/wiki/%D0%9A%D0%98%D0%A1 .

       Или описание важности блокировки в БД. В особенности в распределённой.

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

Принципиальная разница в количестве одновременно сидящих пользователях выполняющих блокировку БД, 50 менеджеров продавцов, кладовщиков, руководителей — в общем всех «блок сотрудников» (Средняя фирма для Украины), и 500 одновременно покупающих через веб сайт (Маленький веб магазин именно для этой фирмы). 10 кратная.

Следовательно требования к блокировке транзакций возрастает принципиально.

«задержки по вине пользователей» («user stall»). резервирование.

==============================================

Модели консистентности http://parallel.ru/krukov/lec6.html

Модели консистентности, не использующие операции синхронизации.

Консистентность	Описание
Строгая	Упорядочение всех доступов к разделяемым данным по абсолютному времени
Последовательная	Все процессы видят все записи разделяемых данных в одном и том же порядке
Причинная	Все процессы видят все причинно-связанные записи данных в одном и том же порядке
Процессорная	PRAM-консистентность + когерентность памяти
PRAM	Все процессоры видят записи любого процессора в одном и том же порядке

(б) Модели консистентности с операциями синхронизации.

Консистентность	Описание
Слабая	Разделяемые данные можно считать консистентными только после выполнения синхронизации
По выходу	Разделяемые данные становятся консистентными после выхода из критической секции
По входу	Связанные с критической секцией разделяемые данные становятся консистентными при входе в нее

============================================

Восстановление после отказа. http://parallel.ru/krukov/lec7.html

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

ОТКАЗОУСТОЙЧИВОСТЬ

Уточнения по поводу теоремы CAP и ошибок, связанных с данными http://citforum.ru/gazeta/169/

Догматы — гарантия прогресса, толковать их опасно, приходится разрушать (Станислав Ежи Лец)

============================================

Закон Гудхарта (Goodhart) предупреждает нас, что «когда достижение некоторого показателя становится целью, он перестает быть хорошим показателем»

============================================

============================================

Виды согласованности

Рационализация согласованности в «облаках»: не платите за то, что вам не требуется

============================================

http://x-tex.ru/

Программные продукты разработки компании «Х-Технология»:

Фреймворк UMS– программная сборка веб-сервера, компилятора байт-кода, виртуальной машины,

=======================================================

Хранилища типа ключ-значение ориентированы на работу с записями. Это значит, что вся информация, относящаяся к данной записи, хранится вместе с ней. Домен (о котором вы можете думать как о таблице) может содержать бессчетное количество различных записей. Например, домен может содержать информацию о клиентах и о заказах. Это означает, что данные, как правило, дублируются между разными доменами. Это приемлемый подход, поскольку дисковое пространство дешево. Главное, что он позволяет все связанные данные хранить в одном месте, что улучшает масштабируемость, поскольку исчезает необходимость соединять данные из различных таблиц. При использовании реляционной БД, потребовалось бы использовать соединения, чтобы сгруппировать в одном месте нужную информацию.

http://habrahabr.ru/blogs/nosql/103021/

—————————————————

Репликация.

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

1.   Журнализация — сохранность данных.

2.   Отказоустойчивость узла. Готовность на лету, взять на себя рабочую нагрузку.

3.   Публикатор.

4.   Самая интересная технология — совмещение сообщений из MPI и РСУБД.

Следуя принципу, как можно меньше соединений БД — клиент. Помня о толстом клиенте (Выделенный — невыделенный сервер отдела). В момент, когда продавец — просматривает склад (Публикатор) на доступный товар. Чтобы выписать счёт клиенту. Он совершенно не нуждается, во всех сразу изменениях на наличие товара. Выбирая винчестер — без разницы — что там с другим товаром. Можно в зависимости, от навигации по каталогу, обновлять запрос. Можно отсылать от публикатора — клиенту сообщения, об изменениях в наличии товара. Пусть товарных позиций — 50 000. Но винчестеров Samsung — 15, во вкладке. Поток, на самом деле очень маленький. Веб — клиентам, нет нужды показывать — всю информацию по товару. Сотруднику — желательно, в любых задачах получать с минимальной задержкой, развёрнуто. Но не 50 000 в реальном времени. В однотипных задачах, сотрудники получают роскошную возможность пользоваться толстым клиентом (Выделенный — невыделенный сервер отдела).

Публикатором.

==========================================— 

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

Отображение адреса — перекликается с комплектацией, в общеупотребимом смысле. Товар в товаре — 10 раз, и улица, в городе … до страны — одно и то же.

Пробуем задать свойства товара, на колонках 5.1 — сразу понимаешь — необходим эффективный механизм комплектации. Ещё более проявляется, в фототехнике. Товар может комплектовать, как производитель, так и продавец.

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

Учёт — контрактных поставок, партийный — комплектация.

========================================—

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

http://blog.arrr.org.ru/

================================================

Вопрос о курице и яйце — никто не купит — пока — пока не будет до тех пор 

Закон Дырявых Абстракций TCP IP

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

================================================

Что они придумали своего, так это «субконто». Другими словами, именованный субсчет уровня предприятия. На этом построена вся их идеология учета – натурализация субсчетов (субконто) уровня предприятия. А натуральная операция, если и учитывается, то подчинена бухгалтерской проводке (в конфигурации «Бухгалтерия для России / Украины. . .»), тогда как более естественным должно быть как раз наоборот – бухгалтерская операция должна быть подчинена натуральной операции.

Натуральный учет

«натурализация» субсчетов уровня предприятия.

http://www.sql.ru/forum/actualthread.aspx?bid=63&tid=697184&pg=2

Кажется вы хотите вот что нам сказать, автор:
Есть состояния (в бухгалтерии бух. счета): товары на складе, деньги р/счете, задолженность перед поставщиками, задолженность покупателей организации
Есть переходы состояний (в бухгалтерии хоз. операции): отгрузка товаров покупателям, оплата от покупателей, оплата поставщикам, поступление товаров от поставщика.
Такой вот замкнутый круг переходов из состояния в состояние. как говорится: деньги-товар-деньги-…
Ну я конечно беру очень простую малую часть учета
Переходы состояний в 1С реализуются документами и эти документы должны изменять состояния по обе стороны от стрелки. Состояния либо бух.счетами, либо регистрами остатков. Поэтому каждый такой документ должен реализовывать 2 интерфейса (вот она двойственность!)
Например реализация: интерфейс движения товаров на складе (списание) и интерфейс взаиморасчетов с покупателями (увеличение долга клиента)
С другой стороны, наоборот, если что-то приходит, то и уходит, то есть для каждого интерфейса должны быть 2 различные реализации: приход и расход.
Кроме того переходы состояний характеризуются оборотами (между счетами или оборотными регистрами) — помещаем их «между» состояниями: Закупки, Продажи, Поступление ден. средств, Расход ден. средств

================================================

Я вот читаю сейчас про модель TransRelational (TR), разработанную Стивом Тареном (Steve Tarin) (по наводке «Бредятина»), занятная, надо сказать вещица! Первое впечатление очень хорошее. Действительно, можно обойтись без индексов за счет представления одной «плоской» таблицы двумя таблицами, в первой из которых, все столбцы упорядочены по значениям, независимо от взаимосвязи друг с другом, а вторая представляет собой «таблицу реконструкции записей». Чтобы понять, как она формируется достаточно вникнуть в пример из книги Дейта. Все относительно просто и легко реализуемо. Правда, пока речь идет об уже сформированной БД и доступе к ней только на чтение, но Дейт обещает, что в новой книге, которая готовится к выходу, будут описаны вопросы создания и модификации БД по технологии TR. В принципе, можно попытаться додуматься до этих идей самому и, может быть, все-таки скрестить «ежа и ужа», то бишь TR & EAV 🙂 .

===============================

http://akop.ru/personal/1234?PARENT_RUBR=akop_art_it  А.Х.Акопянц «Автоматизация хаоса»

http://akop.ru/personal/1235?PARENT_RUBR=akop_art_it  А.Х.Акопянц «Автоматизация «от данных» и информационное моделирование»

http://www.msaccess.ru/Raznoe_About.html А.А.Гордиенко «Некоторые соображения по поводу разработки крупных проектов на Access-97»

http://www.msaccess.ru/Raznoe_BigPrgComment5.html «Переписка Андрея Гордиенко и Ирины Николаевой»

====================================================

РСУБД с трудом справляются, с JOIN. OOBD — ещё хуже.

=======================================

http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=4

Ну, насчет отсутствия аксиоматики ОО — это не совсем так. «Полиморфизм», «наследование», «инкапсуляция» — эти термины как раз из области аксиоматики, а не какого-то конкретного продукта.

2 1024. Сможете Вы представить содержимое накладной на стороне SQL сервера в виде, наиболее близком к ее естественному восприятию — то есть в виде совокупности бланковых полей (Поставщик, Покупатель, Грузоотправитель, Грузополучатель, № документа, Дата и т.п.), значения которых фигурируют в накладной ровно один раз; и присовокупленной к этой информации МНОЖЕСТВУ строк табличной части (№ п/п, Наименование номенклатуры, ед.измерения, цена, кол-во, сумма б/НДС, сумма НДС, Сумма с НДС)? Отчасти эту задачу можно решить с помощью хранимой процедуры, которая будет возвращать два рекордсета — в одном одна запись из полей бланковой части, во втором — множество строк табличной части накладной. Но на этом естественность представления себя исчерпывает, потому что экземпляр объекта накладной, представленный хранимой процедурой, может быть доступен только на чтение. Вы не сможете, обратившись к этой же самой хранимой процедуре (как представлению накладной) добавить или удалить в табличной части строчки. Вы вынуждены будете обратиться либо напрямую к таблице, либо к другой хранимой процедуре (которая не является составной частью этой хранимой процедуры), либо ко VIEW.

За исключением денормализации.

Таким образом, объединение всех составных частей накладной в нечто похожее на настоящую накладную. Вам приходится производить уже на клиенте, склеивая между собой бизнес-логикой клиента составные части накладной, которые сервер РСУБД не способен представить в виде, наиболее близком к естественному.
Мне нравится позиция Евгения — она наиболее близка к моей. Я также не хочу вступать в спор о том, что лучше — реляционная модель или объектно-ориентированная. Эти модели не противоречат друг другу, а дополняют друг друга. Реляционная модель обычно реализовывалась на сервере РСУБД, а ОО-модель — на сервере приложений (при трехзвенной архитектуре). При двухзвенной архитектуре ОО-подход, так или иначе, стараются реализовать в клиентской части. Поэтому давайте не будем эти две вещи сталкивать лбами.

Все новое — хорошо забытое старое. Я сейчас углубляюсь (только начал) в изучение Cache. То, что я там читаю про B-деревья, практически один к одному ложится на представление кластерных индексов в MS SQL Server, на представление компаундных индексов Fox и Clipper. Да и вообще многие известные мне РСУБД на внутреннем уровне используют B-деревья для увеличения эффективности обращения к данным. И не просто для увеличения эффективности. Используете вы индексы или не используете, вы все равно работаете с B-деревьями. Каких-то принципиальных различий между структурами данных на нижних уровнях между Cache и РСУБД я вообще не вижу. В VS SQL Server все запросы к данным на SQL обрабатываются ядром сервера (как бы слоем более высокого уровня) и преобразуются в более низкоуровневые операции по B-дереву.
Cache также предоставляет возможность работать с этими данными через РБД-оболочку, используя SQL-запросы. Но кроме того она предоставляет возможность работать с данными B-дерева, так сказать, в native-представлении, то есть в деревянном. Если это представление удобно ложится на естественную структуру объекта предметной области, то можно (и даже нужно) использовать предоставляемые Cache возможности. Тем самым вы исключаете непроизводительные преобразования иерархической структуры объектов в реляционную и затем обратного преобразования из реляционной в иерархическую.

Винчестер — пока по дорожке -последовательно, реляционная — что в памяти, что на винте — ИЕРАРХИЧЕСКАЯ.

Возможно, я в чем-то ошибаюсь, поскольку в освоении Cache нахожусь пока в разряде начинающих чайников, но пока что таково мое восприятие. MS SQL Server лишает возможности низкоуровневого оперирования данными B-дерева. Хорошо это или плохо — вопрос риторический. Кому как. Лично я пытался организовать древовидные структуры (не одну, а множество, завязанных друг на друга) в MS SQL Server 2000 и от полученного быстродействия просто пришел в ужас. Причины мне, в общем-то, понятны. Многократные преобразования из одних моделей представления данных в другие приводят к существенным потерям производительности. Именно поэтому я заинтересовался Cache. Но это уже не по теме «ОО- и Р-модели», а скорее по теме «иерархическая- и Р-модели».

Что касается ОО, так в Юкон, как я понимаю, собираются включить .NET языки, в числе которых и объектно-ориентированные. Полной уверенности пока нет, но у меня уже есть подозрение, что в Юконе можно будет сервер приложений организовать в нем самом, а не выносить его наружу. В Cache это уже есть. Так что подходы сближаются. Сближаются! Может быть, мы тоже не будем расходиться по лагерям, а будем сближаться?

1.     Модель связей, отношений — онтологическая метамодель, описанная состояниями, в ограничениях других метамоделей.

2.     Мораль — модель данных — реляционная. Цель ACID.

3.     Модель хранения, представления, обработки — от производительности.

Пункт 1:

Пример: Не четыре таблицы — производители, покупатели, сотрудники, поставщики. А одна.

Проще — понять: должники — кредиторы, опт — розница.

Пункт 2:

Все данные — описываем строго реляционной моделью. Сколь бы сложна она не была. Безо всякой оглядки на производительность.

Пункт 3:

Имеем две таблицы — «Шапка документа» — «Строки», делаем денормализованную. Она производная, от «Шапко-строк». Порядок такой, пишем в реляционные, ещё раз из них — в любые: быстрые(Денормализованные), поколоночные, графо-древовидные, XML, OWL. Читаем, считаем, пишем — опять в реляционные. Записали — преобразовали, и так везде. Ничто в индустрии, не развивается, с такой скоростью, как падение стоимости мегабайта хранения.

Сначала архитектура — сущность и атрибут, относим к тем, кому они принадлежат. Затем сколь угодно сложные реляционные структуры данных. Предложите ACID, согласен на альтернативу. Критикуешь — предлагай, предлагаешь — делай, делаешь — несёшь ответственность за результат. Утверждающий доказывает.

Без любой из букв, ACID, безсмысленен. Или все, или ничего. Согласованность — рано или поздно, только логическая. Конечная ответственность, за данные — только реляционное воплощение — в БД.

Если из такой БД, транзакционно — а не прямым вводом данные попадают, в любые другие структуры. Оптимизированные для скорости, значит всегда ACID. Точность, для точности — скорость для скорости.

Ещё раз про скорость. Оптимизация логическая — даёт 100 крат больший эффект, любых других оптимизаций.

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

            Задача: Торгующих филиалов 180. Каждый день новых номенклатурных позиций — 5000, вносятся не централизованно, а в 160 филиалах. Одновременно поддерживается привязка — по сложно организованному каталогу номенклатуры. Требование — одновременное появление во всех филиалах всей информации, при периодическом и постоянном ухудшении — пропаже связи. Архитектура — моего подхода. ID товарной позиции, описание(Ссылка на сайт производителя), цена — реплицируем сразу. До привязок к номенклатурным каталогам. Грубо говоря, товар продать можно, а найти в каталоге нет. Привязали к каталогу — один центральный «Дорогостоящий», выбор есть. Реплицируем оставшуюся часть, в 20 раз объёмнее, всё 180 местных серверов, могут предоставлять поиск по каталогу. Это и есть, модель логической согласованности — рано или поздно. Всё без чего не могут, обойтись в одной части задачи — сделай уже (самой важной). Остальное когда сможешь.

11РАССО ФИЛОСОФИЯ СИСТЕМЫ 3

 

Васильчук Сергей Петрович — 11Рассо Философия системы

Васильчук Сергей Петрович — 11Рассо Философия системы.

распределённая асинхронная система секретарь обработка
distributed asynchronous system Secretary processing

http://www.moysklad.ru/

http://habrahabr.ru/company/moysklad/blog/116379/

http://gdedengi.com.ua/

===============================

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):

++++++==============

11РАССО ФИЛОСОФИЯ СИСТЕМЫ 2

11РАССО ФИЛОСОФИЯ СИСТЕМЫ 3

11РАССО ФИЛОСОФИЯ СИСТЕМЫ 3 ЦЕЛИ СОЗДАНИЯ

11РАССО ПРИМЕНЯМЫЕ ТЕХНОЛОГИИ

11РАССО ПРИМЕНЯМЫЕ ТЕХНОЛОГИИ 2

11РАССО ПРИМЕНЯМЫЕ ТЕХНОЛОГИИ 3

11РАССО АРХИТЕКТУРА СИСТЕМЫ

11РАССО АРХИТЕКТУРА СИСТЕМЫ 2

11РАССО ИСПРОЛЬЗОВАННЫЕ ССЫЛКИ

11РАССО ОПИСАНИЕ МЕТОДОЛОГИЧЕССКОЕ

Васильчук Сергей Петрович — Сумбур

Васильчук Сергей Петрович — Сумбур. Прочитав тысячу книг, по истории никак не мог понять откуда из какой бездны вывалились большевики. Количество никак не соответствовало. Ни один вариант объяснений не проходил проверку критикой по количеству. Евреев было безумно мало. Троцкий с пароходом в 300 боевиков тоже не подходил. Потом прочитал несколько книг по короткому отрезку между февралём и октябрём. И прочитав Купцова прозрел. Одно из первых решений временного правительства (импотентов). Которое они воплотили в жизнь — отмена всех сословий. Воспринималось всеми на ура. И не было отменено ни в одной из белых армий. Воспринималось как прогрессивное. А фактически одна огромная тусовка под названием дворяне. Спряталась. Исчезла. Появился огромный политеистический спектр октябристов, февралистов левые эссеры правые. А фактически две примерно равные группы, спаянные и безумно организованные. Перечислю по убыванию — Дворяне, евреи, дальше количество сильно падает — казаки, старообрядцы (привет Галковскому «поддельные биографии большевиков»). Ещё организационно националисты всех мастей — но представляющие напрямую резидентуры иностранных разведок. Напрямую. Поголовно. Исключительно Англичан. Часть казацкой старшины представляла Немцев. Азербайджан, Грузия Англичане. Подарок белого коня чеченами лично Гитлеру это не знак мы не Советские. Это мы не Английские. На сегодня самая большая не Русская община Москвы — азеры. Евреи пропитали не большевиков, а всех. Без исключения. Хоть у махно, у анархиста железняка, Тамбовское восстание спонсировали еврейские спекулянты хлебом. Они сконцентрировали мобресурс. Разгоняли еврейские чекисты, с помощью дворянских командиров. В общем дворяне занимались любимым делом — геноцидом Русского народа, который давно не был их народом — этнически. А какого цвета бант, флаг, дело десятое. То же самое происходило в Германии. Гитлер вымел исключительно верхушку СоцДемов, и комми. Весь низ включая Анархистов перекрасился. Там этнически всё однороднее было. Не было заточки у Евреев в виде азеров. Самый богатый человек России — «узбек». Каждый раз видишь националюгу — а глядь еврей. Они иначе никогда бы не справились. С позиции Маркса пролетариат, не имеет ничего кроме своих цепей. А что имело дворянство на 1917. Ничего. По официальной статистике — она доступна более 70% были безземельны. Более 80% пахотных земель объеденённых в современный аналог АО. Уже было заложено во французских банках. Дворяне = пролетариат. Они не нация, но на 17 самая организованная образовнная, и имеющая свою армию сила. Книга, генералы царской армии. Без вести пропали 7. 64% Беззаветная служба большевикам. По полковникам такой точной в одном месте собранной информации нет. Но проскакивала цифра более 70%. В общем, я считаю Сталин Берия, единственные кто не дал сотворить с Русским народом ещё более ужасные варианты геноцида этой кодле. А вы нет. Бухарин = ПолПот. Троцкий и правые = сегодняшняя власть. Тухачевский = победила германская группа, напополам с Гитлером Россию делили. В 1953 победила Микоян(Англия), Молотов(Америка). Ну и евреям. Евреям после снятия хруща(немцы). 1937 год это битва между людьми которые решали, как в пользу кого Россию делить. А Россию представлял Сталин. Принимая по очереди помощь от одной группы для разгрома другой. Его период реального правления 1948 — 1953. И то всевластием и не пахло. Он замахнулся на святое, отодвинуть полностью партию от власти. Целиком, всю. И проиграл. Русских он объединил под знаменем «хозяйственники». Командовать у гамадрилии было кому. Желающих работать нет. Главный хозяйственник Берия. Атомная бомба прекрасный повод напугать козлов, и дать Берии полномочия под видом атомного проекта. Кто кроме евреев(космополиты) на Сталина(1948-1953) жаловался, кто критиковал. Он физически не мог, ну никак не мог сделать Русский национальный фронт. Не дали бы. Но он был гений в кодле пидарасов. Русским он подарил его полный аналог. Квоты на поступление в институты — от трудовых коллективов. А как ещё это назвать. Вот где жида и близко не стояло. И чурок не было — это у станка. Вы яростный противник коммунистов сами распишите по годам главные грехи. А самый главный геноцид. Какую бы форму он не принимал. И увидите провал — во времени. Напишите поимённо срисок самых главных врагов Русского народа. Кто непосредственно его уничтожал. Все до одного враги Сталина. Если бы не он, они устроили бы тут Руанду с Кампучией, а не коммунистический эксперимент. Политика искусство возможного. Какая чёрт подери разница, как человек себя называет, главное что он делает. p.s. Было бы здорово, если вам интересно перенести наш диалог с этой ветки куда ни будь ещё.

Альфред Розенберг, Маннергейм одного поля ягоды. Хотя Маннергейм хитрее.

АПН Северо-Запад / Гудериан воевал в Африке, а Маннергейм отказался встречаться с Гитлером

Чем правильнее мы делаем, тем громче они вопят

Оригинал взят у в Чем правильнее мы делаем, тем громче они вопят

Вот ведь какая закономерность получается.

Когда "Газпром" был под Вяхиревым и качал газ мимо бюджета в интересах отдельных бенефициаров, никто даже близко не возмущался откровенно преступной деятельностью газовой империи. Как только "Газпром" стал локомотивом государства и начал наполнять бюджет, тратить деньги на спорт, социальные программы, строить газовопроводы в Европу и Китай, газифицировать регионы и многое другое, на него сразу же полились грязь и обвинения в паразитизме.

Когда в российской армии всё разваливалось и разворовывалось, в Чечне гибли мальчишки, а статус военного упал ниже проститутки, эксперты и енералы молчали в тряпочку и не кричали в СМИ о том, что Ельцин убивает армию. Как только начали зачистку офицерского состава и генералитета от дельцов и предателей, повысили зарплаты и начали перевооружение армии, тут же начались обвинения властей во всех смертных грехах. Енералы и прочие штабные эксперты с "фактами на руках" принялись разъяснять, что "табуреткин развалил армию". Будто до этого она каталась как сыр в масле.

А Ленин предупреждал!

Народы постсоветского пространства могут наглядно увидеть разницу между Россией матушкой, и светочем демократии. Они называют нашу Православную церковь — Ортодоксальной. Причина посты блюдут. Но все народы и пространства завоёванные Россией — да вот они все. Вот их религии, буддизм — шаманизм, как было. Вот элиты. А они вас считают бабуинами. А Русских по недоразумению папуасами. Учитывая, с какой радостью постсоветские, и Россияне бросились охаивать своё прошлое. А реально информационный вброс дедушки хрущёва. Перепевая на все лады. Многие это, и есть. За что боролись?
Оригинал взят у в Узбекистан: гнев бабуина

Приветсвую всех блогеров.
Конечно Узметроном не совсем "независимый" ресурс, иногда тенденциозный, иногда похож на государственный новостной канал Ахборот, иногда там размещают заказной компромат на кого либо.Я думаю что любая как бы "независимая газета" в диктаторской стране на самом деле зависима от спецслужб этой страны.Уже тот факт что журналиста Узметронома иногда приглашают на мероприятия в посольство США говорит само за себя.
Читал в оригинале весь этот спор журналистов из Узметронома и посла США в Узб.

Мои выводы : Не смог президент Узбекистана Каримов выторговать для себя тет-а-тет аудиенцию с БО на предстоящем саммите НАТО в США.Не помогли и просьба от Американо-узбекской торговой палаты (AUCC), и рекомендательное письмо от Хилари Клинтон. Не помог и посол США в Узб Крол.
Поэтому и дали команду Узметроном наступить этой обезьяне на хвост.
Кем бы ни были на самом деле журналисты Узметронома и те кто дал им такую команду — я их поддерживаю.
Помоему скоро снимут посла Узб в США Илхома Нематова.Ему бы пошла работа в Ахбороте, он очень хорошо умеет рассказывать об "уникальных экономических достижениях" Узбекистана. А дипломат он никудышный. Был послом в РФ с 2008 по 2010. В те года резко ухудшились отношения Узб с РФ.

Оригинал взят у в Узбекистан: гнев бабуина

 

Посол США в Узбекистане Джордж Крол через своих сотрудников выразил недовольство по поводу публикации на узбекском сайте Uzmetronom.com и призвал журналистов принести извинения в письменной форме, а также удалить статью, передает корреспондент ИА REGNUM. Ранее, в послании народу Узбекистану по случаю 9 мая, Крол назвал Великую Отечественную войну просто "конфликтом".

"Конфликт, который завершился 67 лет назад, объединил страны и народы, которые как союзники боролись за общее дело, среди них — народы Узбекистана и Соединённых Штатов Америки", — говорилось в послании посла народу Узбекистана.

В ответ узбекское издание указало в своей публикации: "Заметьте — ВОВ, не величайшая трагедия ХХ века, унесшая жизни сорока с лишним миллионов людей, поставившая под вопрос будущее народов и государств, а всего лишь конфликт. …Простите нас великодушно. Мы же — аборигены, недавно слезшие с дерева, не имеющие ни малейшего понятия о демократических ценностях, свободе прессы и прочих достижениях прогрессивного человечества, у истоков которых стояли великие Соединенные Штаты", говорится в ответе редакции главе дипмиссии США.

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

****

На Востоке говорят: “Чем выше лезет обезьяна, тем больше виден его зад”! Что еще тут скажешь в поддержку узбекских журналистов?

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

Без блестяще отработавшего всю войну военно-промышленного комплекса героизм бы нас не спас

Оригинал взят у в Без блестяще отработавшего всю войну военно-промышленного комплекса героизм бы нас не спас

09.05.2012

Нарком Берия и факторы Победы

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

А кто сказал, что мы вообще должны были победить? Вермахт разгромил Польшу меньше чем за три недели, сильнейшую в Европе французскую армию – за сорок дней, а мы с крохотной Финляндией телепались три с половиной месяца, и с каким позором!

Почему же мы победили? У Победы много факторов. Кроме главного — героизма солдат и бессовестно забытых творцами проекта «Георгиевская ленточка» офицеров, это и расстояния, и дороги, и дожди с морозами. И еще один главный фактор Победы, без которого и героизм бы нас не спас – блестяще отработавший всю войну военно-промышленный комплекс.

А кто, кстати, в советском правительстве времен войны отвечал за ВПК – ведь Сталин был главкомом, не разорваться же ему!

Молчит история, шуршат ее скрижали…

Так кто рулил «оборонкой»?