Квинтет — это способ записать атомарные фрагменты данных с указанием их роли в нашей жизни. Квинтетами можно описать любые данные, при этом каждый из них содержит исчерпывающую информацию о себе и о связях с другими квинтетами. Он представляет термины предметной области, независимо от используемой платформы. Его задача — упростить хранение данных и улучшить наглядность их представления.
Я расскажу о новом подходе к хранению и обработке информации и поделюсь мыслями о создании платформы разработки в этой новой парадигме.
Квинтет имеет свойства: тип, значение, родитель, порядок среди братьев. С идентификатором получается всего 5 составляющих. Это простейшая универсальная форма записи информации, новый стандарт, который потенциально может устроить всех. Квинтеты хранятся в файловой системе единой структуры, в сплошном однообразном индексированном информационном поле.
Для записи информации есть бесконечное множество стандартов, подходов и правил, знание которых необходимо для работы с этими записями. Стандарты описаны отдельно и не имеют непосредственной связи с данными. В случае с квинтетами, взяв любой из них, можно получить актуальную информацию о его природе, свойствах и правилах работы с его предметной областью. Его стандарт един и неизменен для всех областей. Квинтет скрыт от пользователя — ему доступны метаданные и данные в виде, привычном для многих.
Квинтет — это не только информация, но и исполняемые команды. Но прежде всего это данные, которые требуется хранить, записывать и извлекать. Поскольку они в нашем случае непосредственно адресуемые, связанные и индексированные, хранить мы их будем в некоем подобии базы данных. Для тестирования прототипа системы хранения данных квинтетами мы, например, использовали обычную реляционную базу данных.
Основной идеей этой статьи является замена машинных типов человеческими терминами и замещение переменных объектами. Не теми объектами, которым нужен конструктор, деструктор, интерфейсы и сборщик мусора, а чистокристаллическими единицами информации, которыми оперирует заказчик. То есть если заказчик говорит «Заявка», то для сохранения сути этой информации на носителе не требовалось бы экспертизы программиста.
Полезно фокусировать внимание пользователя только на Значении объекта, а его тип, родитель, порядок (среди равных по подчиненности) и идентификатор должны быть очевидны из контекста или просто скрыты. Это означает, что пользователь вообще ничего не знает о квинтетах, он просто излагает свою задачу, убеждается, что она принята корректно, и затем запускает её выполнение.
Есть набор типов данных, понятных любому: строка, число, файл, текст, дата и так далее. Такого простого набора вполне достаточно для формулирования задачи, и «программирования» её и необходимых для её реализации типов. Базовые типы, представленные квинтетами, могут выглядеть так:
В данном случае часть составляющих квинтета не используются, а в качестве базового типа используется он сам. Это позволяет ядру системы легче ориентироваться при навигации в метаданных.
Из-за аналитического разрыва между пользователем и программистом на этапе постановки задачи происходит существенная деформация понятий. Недосказанность, недопонятость и непрошеная инициатива зачастую превращает простую и понятную мысль заказчика в логически невозможную мешанину, если судить с точки зрения пользователя.
Передача знаний должна происходить без потерь и искажения. Более того, в дальнейшем при организации хранения этих знаний, необходимо избавиться от ограничений, накладываемых выбранной системой управления данными.
На сервере, как правило, существует множество баз данных, в каждой из них хранится описание структуры сущностей с конкретным набором реквизитов — взаимосвязанных данных. Они хранятся в определенном порядке, в идеале оптимальном для формирования выборки.
Предлагаемая система хранения информации — некий компромисс между различными известными способами: колоночными, строковыми и NoSQL. Она призвана решать задачи, обычно выполняемые каким-то одним из этих способов.
Например, теория колоночных баз выглядит красиво: читаем только нужную колонку, а не все строки записей целиком. Однако на практике так разместить данные на носителе, чтобы это было применимо при десятках различных разрезов анализа, вряд ли получится. Заметим, что атрибуты и аналитические метрики могут добавляться и удаляться, причем иногда быстрее, чем мы сможем перестроить это колоночное хозяйство. Не говоря уже о том, что данные в базе могут корректироваться, что также будет нарушать красоту плана выборки из-за неизбежной фрагментации.
Мы ввели понятие — термин — для описания любых объектов, которыми мы оперируем: сущность, реквизит, запрос, файл и т.д. Мы определим все термины, которые используем в нашей предметной области. А с их помощью мы опишем все сущности, имеющие реквизиты, в том числе в виде связей между сущностями. Например, реквизит — ссылка на запись справочника статусов. Термин записывается квинтетом данных.
Совокупность описаний терминов — это метаданные, задающие структуру таблиц и полей обычной БД. Например, есть следующая структура данных: заявка от какой-то даты, у которой есть содержание (текст заявки) и Состояние, к которой участники производственного процесса добавляют комментарии с указанием даты. В конструкторе традиционной базы данных это будет выглядеть примерно так:
Поскольку мы решили скрывать от пользователя все несущественные детали, такие как связующие ID, например, схема будет несколько упрощена: удалены упоминания ID и объединены названия сущностей и их ключевые значения.
Пользователь «рисует» задание: заявку от сегодняшнего числа у которой есть состояние (справочное значение) и к которой можно добавлять комментарии с указанием даты:
Теперь мы видим 6 разных полей данных вместо 9, а вся схема предлагает нам прочитать и осмыслить 7 слов вместо 13. Хотя это далеко не главное, разумеется.
Ниже приведены квинтеты, сгенерированные управляющим ядром для описания этой структуры:
Пояснения на месте значений квинтетов, выделенные серым, приведены для понятности. Эти поля не заполняются, потому что вся необходимая информация однозначно определена остальными составляющими.
Рассмотрим хранение такого набора данных для описанной выше задачи:
Сами данные хранятся в квинтетах согласно структуре с указанием принадлежности к определенным терминам в виде такого набора:
Мы видим знакомую многим иерархическую структуру, хранимую методом списка смежных вершин (aka Adjacency List).
Вышеописанный пример очень прост, но что будет, когда встретится структура в тысячи раз сложнее, а данных будут гигабайты?
Нам понадобится:
Таким образом, все записи нашей базы данных будут проиндексированы, включая и данные, и метаданные. Такая индексация необходима для сохранения свойств реляционной базы данных — самого простого и популярного инструмента. Индекс по родителю на самом деле составной (ID родителя + тип). Индекс по типу также составной (тип + значение) для быстрого поиска объектов заданного типа.
Метаданные позволяют нам избавиться от рекурсии: например, чтобы найти все реквизиты заданного объекта мы используем индекс по ID родителя. Если же требуется поиск объектов определенного типа, то используется индекс по ID типа. Тип — это аналог имени таблицы и поля в реляционной СУБД.
В любом случае мы не сканируем весь набор данных, и даже при большом количестве значений какого-либо типа нужное значение находится за небольшое количество шагов.
Сама по себе такая база данных не самодостаточна для прикладного программирования, не полная, как говорится, по Тьюрингу. Но мы здесь ведем речь не только о БД, а пытаемся охватить все аспекты: объекты — это, в том числе, произвольные управляющие алгоритмы, которые можно запустить, и они будут работать.
В итоге вместо сложных структур базы данных и отдельно хранящегося исходного кода управляющих алгоритмов мы получим однообразное поле информации, ограниченное объемом носителя и размеченное метаданными. Сами данные представлены пользователю в понятном ему виде — структура предметной области и соответствующие записи в ней. Пользователь произвольно меняет структуру и данные, в том числе делая массовые операции с ними.
Для работы с таким представлением данных понадобится очень компактное ядро — движок нашей базы по размеру на порядок меньше BIOS компьютера, и, значит, его можно сделать если не в железе, то как минимум быстрым и в максимально вылизанном виде. В целях безопасности еще и доступным только для чтения.
Добавив в сборку моего любимого .Net новый класс, мы можем наблюдать потерю 200-300 Мб оперативной памяти только на описание этого класса. Эти мегабайты не поместятся в кэш правильного уровня, провоцируя систему засвопиться с вытекающими отсюда последствиями. Аналогичная ситуация с Java. Описание того же самого класса квинтетами займет десятки или сотни байт, поскольку класс использует только примитивные приемы работы с данными, которые уже знакомы ядру.
Использование описанного подхода не ограничивается только квинтетами, но пропагандирует иную парадигму, чем та, к которой привыкли программисты. На смену императивному, декларативному или объектному языку предлагается язык запросов, как более привычный для человека и позволяющий ставить задачу непосредственно компьютеру, минуя программистов и непробиваемую прослойку существующих сред разработки.
Разумеется, переводчик со свободного пользовательского языка на язык четких требований будет по-прежнему необходим в большой части случаев.
Подробнее эта тема будет раскрыта в отдельных статьях с примерами и существующими наработками.
Итак, если коротко, работает это следующим образом:
Полнота по Тьюрингу всей системы обеспечивается воплощением основных требований: ядро умеет делать последовательные операции, ветвление по условию, обработку наборов данных и останов работы по достижении определенного результата.
Для человека выгода в простоте восприятия, например, вместо объявления цикла с задействованием переменных
используется более понятная человеку конструкция вроде
Мы мечтаем абстрагироваться от низкоуровневых тонкостей реализации информационной системы: циклы, конструкторы, функции, манифесты, библиотеки — всё это занимает слишком много пространства в мозгу программиста, оставляя мало места для творческой работы и развития.
Современное приложение немыслимо без средств масштабирования: требуется неограниченная возможность расширять нагрузочную способность информационной системы. В описываемом подходе, в виду предельной простоты организации данных, масштабирование получается организовать не сложнее, чем в существующих архитектурах.
В рассмотренном выше примере с заявками можно разделить их, например, по их ID, сделав генерацию ID с фиксированными старшими байтами для разных серверов. То есть, при использовании 32 битов под хранение ID, старшие два-три-четыре или больше битов, сколько понадобится, будут указывать сервер, на котором хранятся эти заявки. Таким образом, у каждого сервера будет свой пул ID.
Ядро отдельного сервера может функционировать независимо от других серверов, ничего не зная о них. При создании заявки она будет с большим приоритетом попадать на сервер с минимальным количеством используемых ID, обеспечивая равномерное распределение нагрузки.
Учитывая ограниченный набор возможных вариаций запросов и ответов при единой организации данных, потребуется достаточно компактный диспетчер, распределяющий запросы по серверам и агрегирующий их результаты.
Я расскажу о новом подходе к хранению и обработке информации и поделюсь мыслями о создании платформы разработки в этой новой парадигме.
Квинтет имеет свойства: тип, значение, родитель, порядок среди братьев. С идентификатором получается всего 5 составляющих. Это простейшая универсальная форма записи информации, новый стандарт, который потенциально может устроить всех. Квинтеты хранятся в файловой системе единой структуры, в сплошном однообразном индексированном информационном поле.
Для записи информации есть бесконечное множество стандартов, подходов и правил, знание которых необходимо для работы с этими записями. Стандарты описаны отдельно и не имеют непосредственной связи с данными. В случае с квинтетами, взяв любой из них, можно получить актуальную информацию о его природе, свойствах и правилах работы с его предметной областью. Его стандарт един и неизменен для всех областей. Квинтет скрыт от пользователя — ему доступны метаданные и данные в виде, привычном для многих.
Квинтет — это не только информация, но и исполняемые команды. Но прежде всего это данные, которые требуется хранить, записывать и извлекать. Поскольку они в нашем случае непосредственно адресуемые, связанные и индексированные, хранить мы их будем в некоем подобии базы данных. Для тестирования прототипа системы хранения данных квинтетами мы, например, использовали обычную реляционную базу данных.
Структура квинтета
Основной идеей этой статьи является замена машинных типов человеческими терминами и замещение переменных объектами. Не теми объектами, которым нужен конструктор, деструктор, интерфейсы и сборщик мусора, а чистокристаллическими единицами информации, которыми оперирует заказчик. То есть если заказчик говорит «Заявка», то для сохранения сути этой информации на носителе не требовалось бы экспертизы программиста.
Полезно фокусировать внимание пользователя только на Значении объекта, а его тип, родитель, порядок (среди равных по подчиненности) и идентификатор должны быть очевидны из контекста или просто скрыты. Это означает, что пользователь вообще ничего не знает о квинтетах, он просто излагает свою задачу, убеждается, что она принята корректно, и затем запускает её выполнение.
Базовые понятия
Есть набор типов данных, понятных любому: строка, число, файл, текст, дата и так далее. Такого простого набора вполне достаточно для формулирования задачи, и «программирования» её и необходимых для её реализации типов. Базовые типы, представленные квинтетами, могут выглядеть так:
В данном случае часть составляющих квинтета не используются, а в качестве базового типа используется он сам. Это позволяет ядру системы легче ориентироваться при навигации в метаданных.
Предпосылки
Из-за аналитического разрыва между пользователем и программистом на этапе постановки задачи происходит существенная деформация понятий. Недосказанность, недопонятость и непрошеная инициатива зачастую превращает простую и понятную мысль заказчика в логически невозможную мешанину, если судить с точки зрения пользователя.
Передача знаний должна происходить без потерь и искажения. Более того, в дальнейшем при организации хранения этих знаний, необходимо избавиться от ограничений, накладываемых выбранной системой управления данными.
Как принято хранить данные
На сервере, как правило, существует множество баз данных, в каждой из них хранится описание структуры сущностей с конкретным набором реквизитов — взаимосвязанных данных. Они хранятся в определенном порядке, в идеале оптимальном для формирования выборки.
Предлагаемая система хранения информации — некий компромисс между различными известными способами: колоночными, строковыми и NoSQL. Она призвана решать задачи, обычно выполняемые каким-то одним из этих способов.
Например, теория колоночных баз выглядит красиво: читаем только нужную колонку, а не все строки записей целиком. Однако на практике так разместить данные на носителе, чтобы это было применимо при десятках различных разрезов анализа, вряд ли получится. Заметим, что атрибуты и аналитические метрики могут добавляться и удаляться, причем иногда быстрее, чем мы сможем перестроить это колоночное хозяйство. Не говоря уже о том, что данные в базе могут корректироваться, что также будет нарушать красоту плана выборки из-за неизбежной фрагментации.
Метаданные
Мы ввели понятие — термин — для описания любых объектов, которыми мы оперируем: сущность, реквизит, запрос, файл и т.д. Мы определим все термины, которые используем в нашей предметной области. А с их помощью мы опишем все сущности, имеющие реквизиты, в том числе в виде связей между сущностями. Например, реквизит — ссылка на запись справочника статусов. Термин записывается квинтетом данных.
Совокупность описаний терминов — это метаданные, задающие структуру таблиц и полей обычной БД. Например, есть следующая структура данных: заявка от какой-то даты, у которой есть содержание (текст заявки) и Состояние, к которой участники производственного процесса добавляют комментарии с указанием даты. В конструкторе традиционной базы данных это будет выглядеть примерно так:
Поскольку мы решили скрывать от пользователя все несущественные детали, такие как связующие ID, например, схема будет несколько упрощена: удалены упоминания ID и объединены названия сущностей и их ключевые значения.
Пользователь «рисует» задание: заявку от сегодняшнего числа у которой есть состояние (справочное значение) и к которой можно добавлять комментарии с указанием даты:
Теперь мы видим 6 разных полей данных вместо 9, а вся схема предлагает нам прочитать и осмыслить 7 слов вместо 13. Хотя это далеко не главное, разумеется.
Ниже приведены квинтеты, сгенерированные управляющим ядром для описания этой структуры:
Пояснения на месте значений квинтетов, выделенные серым, приведены для понятности. Эти поля не заполняются, потому что вся необходимая информация однозначно определена остальными составляющими.
Посмотреть как связаны квинтеты
Пользовательские данные
Рассмотрим хранение такого набора данных для описанной выше задачи:
Сами данные хранятся в квинтетах согласно структуре с указанием принадлежности к определенным терминам в виде такого набора:
Мы видим знакомую многим иерархическую структуру, хранимую методом списка смежных вершин (aka Adjacency List).
Быстродействие
Вышеописанный пример очень прост, но что будет, когда встретится структура в тысячи раз сложнее, а данных будут гигабайты?
Нам понадобится:
- Рассмотренная выше иерархическая структура — 1 шт.
- B-дерево для поиска по ID, родителю и типу — 3 шт.
Таким образом, все записи нашей базы данных будут проиндексированы, включая и данные, и метаданные. Такая индексация необходима для сохранения свойств реляционной базы данных — самого простого и популярного инструмента. Индекс по родителю на самом деле составной (ID родителя + тип). Индекс по типу также составной (тип + значение) для быстрого поиска объектов заданного типа.
Метаданные позволяют нам избавиться от рекурсии: например, чтобы найти все реквизиты заданного объекта мы используем индекс по ID родителя. Если же требуется поиск объектов определенного типа, то используется индекс по ID типа. Тип — это аналог имени таблицы и поля в реляционной СУБД.
В любом случае мы не сканируем весь набор данных, и даже при большом количестве значений какого-либо типа нужное значение находится за небольшое количество шагов.
Основа для платформы разработки
Сама по себе такая база данных не самодостаточна для прикладного программирования, не полная, как говорится, по Тьюрингу. Но мы здесь ведем речь не только о БД, а пытаемся охватить все аспекты: объекты — это, в том числе, произвольные управляющие алгоритмы, которые можно запустить, и они будут работать.
В итоге вместо сложных структур базы данных и отдельно хранящегося исходного кода управляющих алгоритмов мы получим однообразное поле информации, ограниченное объемом носителя и размеченное метаданными. Сами данные представлены пользователю в понятном ему виде — структура предметной области и соответствующие записи в ней. Пользователь произвольно меняет структуру и данные, в том числе делая массовые операции с ними.
Мы не изобрели ничего нового: все данные уже хранятся в файловой системе и поиск в них осуществляется с помощью B-деревьев, что в файловой системе, что в базах данных. Мы только реорганизовали представление данных, чтобы с ними было проще и нагляднее работать.
Для работы с таким представлением данных понадобится очень компактное ядро — движок нашей базы по размеру на порядок меньше BIOS компьютера, и, значит, его можно сделать если не в железе, то как минимум быстрым и в максимально вылизанном виде. В целях безопасности еще и доступным только для чтения.
Добавив в сборку моего любимого .Net новый класс, мы можем наблюдать потерю 200-300 Мб оперативной памяти только на описание этого класса. Эти мегабайты не поместятся в кэш правильного уровня, провоцируя систему засвопиться с вытекающими отсюда последствиями. Аналогичная ситуация с Java. Описание того же самого класса квинтетами займет десятки или сотни байт, поскольку класс использует только примитивные приемы работы с данными, которые уже знакомы ядру.
Как быть с разными форматами: РСУБД, NoSQL, колоночные базы
Описанный подход покрывает два основных направления: РСУБД и NoSQL. При решении задач, использующих преимущества колоночных баз данных, нам понадобится сообщить ядру, что те или иные объекты следует хранить с учетом оптимизации массовой выборки значений определенного типа данных (нашего термина). Так ядро сможет разместить данные на диске наиболее выгодно.
Таким образом, для колоночной базы мы можем значительно сэкономить пространство, занимаемое квинтетами: использовать только одну-две его составляющих для хранения полезных данных вместо пяти, а также использовать индекс только для указания начала цепочек данных. Во многих случаях для выборок из нашего аналога колоночной базы будет использоваться только индекс, без необходимости обращения к данным самой таблицы.
Следует заметить, что задумка не ставит цели собрать все передовые разработки из этих трех типов баз данных. Наоборот, движок новой системы будет максимально редуцирован, воплощая только необходимый минимум функций — всё, что покрывает запросы DDL и DML в описанной здесь концепции.
Таким образом, для колоночной базы мы можем значительно сэкономить пространство, занимаемое квинтетами: использовать только одну-две его составляющих для хранения полезных данных вместо пяти, а также использовать индекс только для указания начала цепочек данных. Во многих случаях для выборок из нашего аналога колоночной базы будет использоваться только индекс, без необходимости обращения к данным самой таблицы.
Следует заметить, что задумка не ставит цели собрать все передовые разработки из этих трех типов баз данных. Наоборот, движок новой системы будет максимально редуцирован, воплощая только необходимый минимум функций — всё, что покрывает запросы DDL и DML в описанной здесь концепции.
Парадигма программирования
Использование описанного подхода не ограничивается только квинтетами, но пропагандирует иную парадигму, чем та, к которой привыкли программисты. На смену императивному, декларативному или объектному языку предлагается язык запросов, как более привычный для человека и позволяющий ставить задачу непосредственно компьютеру, минуя программистов и непробиваемую прослойку существующих сред разработки.
Разумеется, переводчик со свободного пользовательского языка на язык четких требований будет по-прежнему необходим в большой части случаев.
Подробнее эта тема будет раскрыта в отдельных статьях с примерами и существующими наработками.
Итак, если коротко, работает это следующим образом:
- Мы единожды описали квинтетами примитивные типы данных: строка, число, файл, текст и прочие, а также обучили ядро работе с ними. Обучение сводится к правильному представлению данных и осуществлению простых операций с ними.
- Теперь мы описываем квинтетами пользовательские термины (типы данных) — в виде метаданных. Описание сводится к указанию примитивного типа данных для каждого пользовательского типа и определению подчиненности.
- Заносим квинтеты данных согласно заданной метаданными структуре. Каждый квинтет данных содержит ссылку на свой тип и родителя, что позволяет быстро найти его в хранилище данных.
- Задачи ядра сводятся к выборке данных и осуществлению простых операций с ними для реализации сколько угодно сложных алгоритмов, описанных пользователем.
- Пользователь управляет данными и алгоритмами с помощью визуального интерфейса, наглядно представляющего и первое, и второе.
Полнота по Тьюрингу всей системы обеспечивается воплощением основных требований: ядро умеет делать последовательные операции, ветвление по условию, обработку наборов данных и останов работы по достижении определенного результата.
Для человека выгода в простоте восприятия, например, вместо объявления цикла с задействованием переменных
for (i=0; i<length(A); i++)
if A[i] meets a condition
do something with A[i]используется более понятная человеку конструкция вроде
with every A, that match a condition, do somethingМы мечтаем абстрагироваться от низкоуровневых тонкостей реализации информационной системы: циклы, конструкторы, функции, манифесты, библиотеки — всё это занимает слишком много пространства в мозгу программиста, оставляя мало места для творческой работы и развития.
Масштабирование
Современное приложение немыслимо без средств масштабирования: требуется неограниченная возможность расширять нагрузочную способность информационной системы. В описываемом подходе, в виду предельной простоты организации данных, масштабирование получается организовать не сложнее, чем в существующих архитектурах.
В рассмотренном выше примере с заявками можно разделить их, например, по их ID, сделав генерацию ID с фиксированными старшими байтами для разных серверов. То есть, при использовании 32 битов под хранение ID, старшие два-три-четыре или больше битов, сколько понадобится, будут указывать сервер, на котором хранятся эти заявки. Таким образом, у каждого сервера будет свой пул ID.
Ядро отдельного сервера может функционировать независимо от других серверов, ничего не зная о них. При создании заявки она будет с большим приоритетом попадать на сервер с минимальным количеством используемых ID, обеспечивая равномерное распределение нагрузки.
Учитывая ограниченный набор возможных вариаций запросов и ответов при единой организации данных, потребуется достаточно компактный диспетчер, распределяющий запросы по серверам и агрегирующий их результаты.
Комментарии (40)
gecube
14.12.2018 09:07То что описано — похоже на движок типа 1с, перед которым тоже очевидно стоит аналогичная задача структурированного и платформонезависимого описания объектов.
К тому же, конкретно та платформа имеет ещё кучу готовых примитивов для описания объектов реального мира, из конкретной предметной области, чтобы разработчик себе голову не ломал.
У Вашей концепции какое дальнейшее развитие будет? Чем она принципиально лучше?NikZanyat Автор
14.12.2018 09:25Вы правильно заметили про движок — здесь описан подход к его разработке.
Для создания платформы нужно развивать инфраструктуру и нарабатывать практики, а это уже следующий этап.
Принципиально, на мой субъективный взгляд, самое важное улучшение — это возможность начать всё с чистого листа, постепенно усложняя прикладную часть и избегая известных ошибок.
Соответственно, развитие сейчас заключается в создании энтузиастами нужных им примитивов, решающих очень простые задачи, коих, если присмотреться очень много. По итогам этих работ появляются артефакты, а сами энтузиасты решают для себя насколько им это нравится или не нравится. Сама концепция при этом получает практическое подтверждение жизнеспособности и позволяет запланировать дальнейшие шаги, решая более сложные задачи.
DareDen
14.12.2018 09:24-1Прочитал, что по мнению автора, байт — это минимальная единица данных, взгрустнул о судьбе бита, пролистал статью и написал этот комментарий :). Извините.
WizardryIB
14.12.2018 10:23На forth так и программируют.
NikZanyat Автор
14.12.2018 10:32Да, это, вероятно, ближайшая аналогия из мира разработки, и было трудно удержаться от упоминания этого языка в статье.
fedorro
14.12.2018 10:29TL;TR; Создадим базовый тип Квинтет с тремя дополнительными полями (они не всегда нужны, поэтому иногда не заполняются), и будем использовать DDD.
roscomtheend
14.12.2018 11:15+1> привело к чудовищной растрате ресурсов IT-системами
> Квинтет не заменяет байт как таковой, но, будучи сам составлен из байтов, стремится заменить термин «байт» как обозначение минимальный порции данных.
Т.е. вместо старшего и младшего байта в 16ричном слове надо хранить 15 слов неизвестного размера + 2 байта (по 5 каждый байт и 5 на само слово).
Если взять 32битную систему, то 2 байта заменяются 62. Экономия.
Ну или менять нужно не «байт», а «объект» и не как «минимальная единица представления информации», а как «базовая сущность описания предметной области».NikZanyat Автор
14.12.2018 11:26Спасибо, подправил заголовок и статью.
А байты мы посчитаем в одной из следующих статей и сравним с существующими решениями.
Bedal
14.12.2018 11:31Не забудем, что идентификатор неизбежно будет GUIDом, а это само по себе 16 байт. Попытки вместо GUIDа использовать коротенькое число локального идентификатора непременно окончатся крахом.
Хотя, вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты (то есть не имеющие выделенного идентификатора).
В общем, ждём реализации, вот ужо оно залетает…NikZanyat Автор
14.12.2018 12:06Хотя, вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты (то есть не имеющие выделенного идентификатора).
Да, это именно так. Они неидентифицируемы, что создает определенные проблемы, когда пользователи хотят их анализировать.
Современный пользователь хочет всего и сразу, и его требования часто меняются быстрее, чем мы успеваем обновить нашу систему: изменить типы реквизитов, размерность, индексировать некоторые поля, используемые для поиска только здесь и сейчас.
Мы часто решаем эти проблемы и придумали способ их уменьшить. Это работает, и принято решение расти.Bedal
14.12.2018 13:07+1Они неидентифицируемы,
Ну, как — идентифицируемы по обязательной ссылке.Современный пользователь хочет всего и сразу
Всего и сразу требует практика. Вот у вас ссылки однонаправленные, значит, обязательное дерево неустойчиво. С другой стороны — наличие деревянной структуры вообще не требуется в большом количестве случаев. В других — нет единственного дерева-доминанта, что, по сути, то же самое.
Боюсь, это больше похоже на лабораторную работу или (что почти то же самое) занятие интересными ядерными вещами, когда потребитель почему-то ждёт продукт и бизнес-логику.NikZanyat Автор
14.12.2018 13:16Ну, как — идентифицируемы по обязательной ссылке.
Не уверен, что понял вас. Вы сами сказали «половина объёма — вообще неидентифицируемы».
Вот у вас ссылки однонаправленные, значит, обязательное дерево неустойчиво.
Ссылки двунаправленные — оба упоминания ID проиндексированы, значит их можно сопоставить в любую сторону, равно как и собрать все связи с заданным ID.
Сами квинтеты хранятся не деревом, а списком. Деревья же используются для быстрого нахождения значения в списке.Bedal
14.12.2018 13:43Я сильно подозреваю, что спорить с энтузиастом себе дороже…
Отсутствует собственный идентификатор, автономно объект не идентифицируем, существует только при наличии обязательной ссылки. Вот как палец: на нём не обязательно наносить татуировку, чтобы можно было утверждать, что этот палец — мой. У вас же и идентификатор, и ссылка. Избыточность, причём ссылка по дереву явно будет работать только в очень узком применении, которое в начале разработки предполагалось основным. По мере строительства продукта обычно оказывается, правда, что это не так :-)Ссылки двунаправленные — оба упоминания ID проиндексированы, значит их можно сопоставить в любую сторону, равно как и собрать все связи с заданным IDНу, как — идентифицируемы по обязательной ссылке.
Не уверен, что понял вас. Вы сами сказали «половина объёма — вообще неидентифицируемы».
Ссылки двунаправленные — оба упоминания ID проиндексированы, значит их можно сопоставить в любую сторону, равно как и собрать все связи с заданным ID
индексы не являются обеспечителями надёжности, только скорости. На то они и индексы, что их можно перестраивать независимо от операций с собственно моделью. Альтернатива — обязательные индексы, и тогда у вас не квинтлеты, а уже нагромождение. Чего я, собственно, и ожидал.
И вообще непонятно, если уж на то пошло, зачем Вы перегрузили триплы лишней информацией, если, по сути, строите то же самое. Могли бы взять готовое, а не бегать по граблям. Впрочем, и в готовом виде триплы — бяка.NikZanyat Автор
14.12.2018 14:24Избыточность, причём ссылка по дереву явно будет работать только в очень узком применении, которое в начале разработки предполагалось основным. По мере строительства продукта обычно оказывается, правда, что это не так :-)
Ссылки между квинтетами работают при каждом обращении к данным — это связующая информация и другой никакой нет (нет схем, таблиц, полей). Избыточность присутствует, да, как плата за унификацию и удобство работы со структурой и данными.
индексы не являются обеспечителями надёжности, только скорости. На то они и индексы, что их можно перестраивать независимо от операций с собственно моделью. Альтернатива — обязательные индексы, и тогда у вас не квинтлеты, а уже нагромождение. Чего я, собственно, и ожидал.
Пользователи не очень любят перестраивать индексы и платить за это тоже не всегда желают. Избыточность, как я упомянул выше, это достаточно дешевая альтернатива.
И вообще непонятно, если уж на то пошло, зачем Вы перегрузили триплы лишней информацией, если, по сути, строите то же самое. Могли бы взять готовое, а не бегать по граблям. Впрочем, и в готовом виде триплы — бяка.
Я бы не стал привязываться к триплам, и по сути я строю нечто иное и с иной целью.
Bedal
14.12.2018 11:25CIMы (Common Information Model) существуют в изрядном множестве для разных областей. И они показывают, что реальность не может опираться на такие простенькие структуры, как представлено в посте. Ну, разве что очень простые реальности…
ganqqwerty
14.12.2018 11:28А я вот прямиком обратное замечу. Слишком сложные ваши квинтеты, семантик веб вон так и не смог выбраться за пределы универов, а в нем всего лишь триплеты. Считать в промышленности научились пока только до двух, поэтому ещё долго будем описывать реальность на json, парами ключ-значение.
Bedal
14.12.2018 11:41не надо про триплеты! У нас один энтузиаст наворотил на них, и ушло в эксплуатацию. Уже десять(!) лет проблемы огребаем.
прямиком обратное замечу. Слишком сложные ваши квинтеты
вот-вот, я тоже подобное успел отметить:вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты
ganqqwerty
14.12.2018 12:32лет шесть со всеми этими owl-ами и rdf-ами проработал и ответственно заявляю: хотите чего-нить работающего — отбирайте его у академиков. метавебовский MQL и neo4j настолько практичнее, прагматичнее и удобнее SPARQL/RDF, что просто диву даешься.
maximw
15.12.2018 00:57neo4j, к сожалению, весьма ограничена в применении. Из-за их лицензионной политики или для совсем простых проектов, или для самого матерого ынтерпрайза.
NikZanyat Автор
14.12.2018 13:49CIMы (Common Information Model) существуют в изрядном множестве для разных областей.
Мы не изобретали новую CIM, а реорганизовали представление данных, чтобы с ними было проще и нагляднее работать, не изменяя подход к хранению данных в принципе. Это работает до модели, на уровне квантов данных, без привязки к конкретной области.
И они показывают, что реальность не может опираться на такие простенькие структуры, как представлено в посте. Ну, разве что очень простые реальности…
Для этого и была написана статья — описать подход, применимый к структуре любой сложности, какая может встретиться в современных приложениях.
Поскольку у вас наверняка естьуверенность, что это не сработаетсомнения по каким-то конкретным моментам, я готов ответить на вопросы, рассказать на конкретных примерах, как именно это сработает, и показать в реальности.
Bedal
14.12.2018 15:43Для того, чтобы было понятнее и другим, и вам самим, объясните, чем этот подход отличается от достаточно широко (и многим — печально) известных триплов ака EAV.
Зачем вы расширили этот подход, какой выигрыш и где можно получить? «Зачем?» — вообще главный и не-отвеченный вопрос, возникающий по прочтении поста.
А я остаюсь в состоянии глубокого скептицизма.NikZanyat Автор
14.12.2018 16:20Для того, чтобы было понятнее и другим, и вам самим, объясните, чем этот подход отличается от достаточно широко (и многим — печально) известных триплов ака EAV.
EAV — это не подход, а структура. Можно сказать, что это подход к представлению данных, и не более.
А здесь описан подход к построению информационной системы, где данные (в т.ч. алгоритмы) хранятся в предельно простом и унифицированном формате.
Зачем вы расширили этот подход, какой выигрыш и где можно получить? «Зачем?» — вообще главный и не-отвеченный вопрос, возникающий по прочтении поста.
Выигрыш может быть в скорости разработки, во всяком случае мы стали быстрее разрабатывать приложения, применяя этот подход. Поскольку система хранения унифицирована, к ней можно прикрутить различные варианты интерфейса, который скроет много тривиальной, черновой работы, устранит часть связанных с этим рисков и снизит порог вхождения для разработчика.lair
14.12.2018 17:08EAV — это не подход, а структура. Можно сказать, что это подход к представлению данных, и не более.
По какому формальному критерию вы разделяете одно и другое?
Выигрыш может быть в скорости разработки, во всяком случае мы стали быстрее разрабатывать приложения, применяя этот подход.
Я и про EAV лет пятнадцать назад то же самое говорил. Причем включая интерфейс. Да что там 15 лет назад, в этом году на хабре обсуждали очередную реинкарнацию, причем вот ровно с теми же обещаниями, что вы тут озвучиваете.
lair
14.12.2018 12:23+1Квинтетами можно описать любые данные, при этом каждый из них содержит исчерпывающую информацию о себе и о связях с другими квинтетами.
Не, не содержит. Как показано в примере с мамой и папой выше, эта информация содержится не в квинтете, а в других квинтетах.
Возникает неприятный вопрос: а чем это, собственно, отличается от EAV?
NikZanyat Автор
14.12.2018 13:27Не, не содержит. Как показано в примере с мамой и папой выше, эта информация содержится не в квинтете, а в других квинтетах.
Связь может быть сколько угодно сложной, и квинтет позволяет её проследить, указывая следующее звено этой связи и доводя в итоге до мамы и папы.
Возникает неприятный вопрос: а чем это, собственно, отличается от EAV?
Вы можете называть это EAV. Только к нему ещё добавлены идентификатор и порядок.lair
14.12.2018 13:30Связь может быть сколько угодно сложной, и квинтет позволяет её проследить, указывая следующее звено этой связи и доводя в итоге до мамы и папы.
Неа, квинтет — не позволяет. Конкретную информацию содержит совокупность квинтетов, но не сам квинтет.
Только к нему ещё добавлены идентификатор и порядок.
Идентификаторы в EAV зачастую есть. Порядок… ну да, порядок. В некоторых реализациях тоже есть.
Так где же "новый подход к"?
ganqqwerty
14.12.2018 14:22Конкретную информацию содержит совокупность квинтетов, но не сам квинтет.
Ну дык, конечно. Сам квинтет — это ж типа атом.
DaneSoul
Что делать если родителей больше одного?
То есть например классическая родословная — у ребенка есть папа и мама.
NikZanyat Автор
Добавить ссылки на папу и маму в его реквизиты
lair
… вот вы и получили неоднозначность описания.
gecube
Я так понимаю, что «родитель» здесь технический термин, а не описание логики взаимосвязей доменной структуры.
Касательно родословной — можно собирать коллекцию семья и описывать взаимоотношения отдельными квинтетами, т.к. у человека может быть и больше одной пары родителей: либо приемные/кровные (возможны ещё варианты), либо мы попросту из документальных источников не можем определить какая пара родителей «истинная» (характерно, когда смотришь в исторические источники — там прям путаница бывает)