Васильчук Сергей Петрович — 11Рассо Философия системы 2.
Оригинал взят у 
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) предупреждает нас, что «когда достижение некоторого показателя становится целью, он перестает быть хорошим показателем»
============================================
============================================
Рационализация согласованности в «облаках»: не платите за то, что вам не требуется
============================================
Программные продукты разработки компании «Х-Технология»:
Фреймворк UMS– программная сборка веб-сервера, компилятора байт-кода, виртуальной машины,
=======================================================
Хранилища типа ключ-значение ориентированы на работу с записями. Это значит, что вся информация, относящаяся к данной записи, хранится вместе с ней. Домен (о котором вы можете думать как о таблице) может содержать бессчетное количество различных записей. Например, домен может содержать информацию о клиентах и о заказах. Это означает, что данные, как правило, дублируются между разными доменами. Это приемлемый подход, поскольку дисковое пространство дешево. Главное, что он позволяет все связанные данные хранить в одном месте, что улучшает масштабируемость, поскольку исчезает необходимость соединять данные из различных таблиц. При использовании реляционной БД, потребовалось бы использовать соединения, чтобы сгруппировать в одном месте нужную информацию.
http://habrahabr.ru/blogs/nosql/103021/
—————————————————
Репликация.
Вообще говоря — репликация, здесь выполняет четыре задачи.
1. Журнализация — сохранность данных.
2. Отказоустойчивость узла. Готовность на лету, взять на себя рабочую нагрузку.
3. Публикатор.
4. Самая интересная технология — совмещение сообщений из MPI и РСУБД.
Следуя принципу, как можно меньше соединений БД — клиент. Помня о толстом клиенте (Выделенный — невыделенный сервер отдела). В момент, когда продавец — просматривает склад (Публикатор) на доступный товар. Чтобы выписать счёт клиенту. Он совершенно не нуждается, во всех сразу изменениях на наличие товара. Выбирая винчестер — без разницы — что там с другим товаром. Можно в зависимости, от навигации по каталогу, обновлять запрос. Можно отсылать от публикатора — клиенту сообщения, об изменениях в наличии товара. Пусть товарных позиций — 50 000. Но винчестеров Samsung — 15, во вкладке. Поток, на самом деле очень маленький. Веб — клиентам, нет нужды показывать — всю информацию по товару. Сотруднику — желательно, в любых задачах получать с минимальной задержкой, развёрнуто. Но не 50 000 в реальном времени. В однотипных задачах, сотрудники получают роскошную возможность пользоваться толстым клиентом (Выделенный — невыделенный сервер отдела).
Публикатором.
==========================================—
Огромадная методологическая проблема, в БД — разрыв представления данных в реляционном и
естественном виде. Проявляется, в проблеме задания адреса, свойств товара, отображения коммутационных схем. Всё, что я смог найти, меня не устраивало полностью.
Отображение адреса — перекликается с комплектацией, в общеупотребимом смысле. Товар в товаре — 10 раз, и улица, в городе … до страны — одно и то же.
Пробуем задать свойства товара, на колонках 5.1 — сразу понимаешь — необходим эффективный механизм комплектации. Ещё более проявляется, в фототехнике. Товар может комплектовать, как производитель, так и продавец.
Сугубо финансовый аспект деятельности, отображение затрат — на единицу инвестиций, или проданного товара. Не для отчётности, а для правильного ведения бизнеса. Методологически, комплектация.
Учёт — контрактных поставок, партийный — комплектация.
========================================—
Как уже отмечалось, существует большое количество программных систем, предназначением которых, является конструирование сложных составных объектов из большого числа более мелких и простых объектов. При этом, гибкость и универсальность подобных систем, достигается за счет предоставления пользователю полного набора инструментов и примитивов. Важно понимать, что примитивами, в данном контексте являются элементарные объекты, из которых в последствии конструируются составные. Причем, уровень на котором, объект считается примитивным, на самом деле, определяет применимость и эффективность данной системы. Однако, не всегда существует возможность спроектировать систему вплоть до самых низких уровней абстракции. Затраты на память и низкая производительности системы, при прямом подходе, не позволяют этого сделать. Поэтому, при проектировании подобных систем, зачастую применяют паттерн «Приспособленец»
================================================
Вопрос о курице и яйце — никто не купит — пока — пока не будет до тех пор
Закон Дырявых Абстракций 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
Serg_p 