В одном проекте была поставлена задача долговременного хранения логически связанных объектов данных с обеспечением многопользовательского доступа к их содержимому.
Существуют различные способы удовлетворения этой потребности с использованием существующих систем управления данными.
Тем не менее, был предпринят поиск простого и продуктивного решения, результаты которого предложены к рассмотрению.
В этой статье рассматривается общая логика управления данными, не углубляясь в детали программной реализации, которые зачастую самоочевидны.
По условиям задачи система управления объектной базой данных, а точнее та ее часть, которая отвечает за многопользовательский доступ, оперирует однородным набором изолированных объектов.
Обратите внимание, что унифицированную форму объекта могут принимать самые разнообразные информационные сущности: данные, метаданные, списки, транзакции, ресурсы сценариев, документы и другие.
Объект данных
Изначально об объекте известно только то, что он сериализован с целью долговременного хранения на диске и состоит из двух частей: заголовка и самого контента.Заголовок объекта имеет фиксированную длину и должен содержать служебную информацию.
В частности, в заголовке хранится общая длина объекта в байтах, его собственный дескриптор и номер состояния.
Априори объект содержит набор значений, которые идентифицируются своим порядковым номером в наборе.
Сам объект никак не интерпретирует свои значения, но «знает», что каждое значение характеризуется длиной в байтах, что позволяет вычислить размер объекта.
Набор значений существует в формате кортежа.
Идентификация и доступ
Для хранения объектов используется условно бесконечное файловое пространство, логически разбитое на кластеры.В файловом хранилище каждый объект занимает один или несколько последовательных кластеров.
Серийный номер первого кластера используется как указатель файла ФП (Указатель файла), чтобы поместить объект в хранилище.
Используется для долговременного хранения указателей файлов.
таблица распределения ДАТ (Таблица распределения данных), которая представляет собой простой динамически расширяемый массив целочисленных указателей.
Индексы ячеек DAT используются как идентификаторы системных объектов Я ДЕЛАЮ.
.
При создании нового объекта ему выделяется следующая свободная ячейка DAT, индекс которой становится постоянным идентификатором объекта.
Этот идентификатор представляет собой уникальный глобальный дескриптор объекта в физической базе данных.
При запуске системы DAT загружается из хранилища в оперативную память и используется для организации быстрого доступа к объекту с помощью его IDO по следующей схеме: 
Если значение, полученное из DAT, является указателем файла, объект загружается из хранилища в память — Кэшировать объекты , а содержимое ячейки DAT заменяется указателем на память А* .
Обратная замена происходит при удалении объекта из памяти.
Примечание: указатель на память А* — это не абсолютный адрес, а лишь смещение относительно начала Кэш , но он указывает непосредственно на содержимое объекта.
Заголовок объекта, а также служебные поля, предназначенные для временного хранения ФП и связывания объектов в цепочки, располагаются относительно А* с отрицательным смещением.
Примечательно, что значение А* также используется как идентификатор объекта в памяти.
Кэшировать объекты
Представляет собой непрерывную область памяти, которая статически выделяется при инициализации системы.Требуемый размер указывается опционально.
Основные задачи Кэш — быть максимально наполненным и быстро распределить пространство, необходимое для размещения объекта.
Для этих целей цепочка блоков свободной памяти ранжируется, и выталкивание очередных неиспользуемых объектов происходит только тогда, когда это единственный способ получить свободное пространство необходимого размера.
При выделении памяти объекту автоматически учитывается необходимый резерв для размещения служебных полей.
А еще он используется для управления свободной памятью.
Состояния и транзакции
При отсутствии внешних воздействий полный набор объектов, образующих базу данных, сохраняет свою состояние .Под любым действием по извлечению содержимого объектов, не изменяющим состояние базы данных, далее понимается образец .
Внешнее воздействие, изменяющее состояние базы данных, рассматривается как сделка .
Транзакция создает новые объекты или изменяет содержимое существующих.
При этом задействуется следующий механизм внесения изменений: сначала создается копия объекта, как его более старая версия, в которую вносятся эти изменения.
Совокупность вновь созданных объектов и измененных копий объектов образует множество.
объекты транзакции .
Соответственно, новое состояние базы будет объекты транзакции + объекты предыдущего состояния , игнорируя более ранние версии объектов.
Де-факто серийный номер транзакции является номером статуса базы данных.
В условиях многопользовательского доступа к данным требуются определенные усилия для поддержания логической целостности данных как во время выполнения транзакции, так и во время извлечения.
Целостность данных
Концепция транзакционный честность хорошо известно - " все или ничего ".Новое состояние базы данных будет создано только в случае успешного завершения транзакции.
В этом случае объекты транзакций становятся общедоступными.
Фиксация нового состояния происходит, когда пользователь завершает сеанс транзакции , который необходимо открыть перед началом транзакции.
Но пока транзакционный сеанс не завершен, сгенерированные или измененные им объекты доступны исключительно пользователю, открывшему сеанс.
Любое прерывание транзакционной сессии, независимо от причины прерывания, повлечёт за собой простое уничтожение объектов, сгенерированных сессией.
Помимо вышесказанного, следует учитывать еще одно очевидное правило: сделка, началось позже предыдущий не может быть завершено ранее завершение предыдущей транзакции с более высоким приоритетом.
Необходимость соблюдать» богатый «Целостность данных далеко не очевидна.
Формируется оперативный финансовый отчет компании, для которого берется очень обширная и долгосрочная выборка данных.
При этом база данных постоянно меняет свое состояние под воздействием потока транзакций.
Если не вводить ограничения, то существует ненулевая вероятность того, что баланс отчета не сойдётся, так как в выборку попала только часть в целом корректной и успешно завершившейся транзакции (случайным образом на пересечении временных интервалов).
Чтобы остановить такую коллизию, нужно следовать простому правилу — любая выборка данных должна производиться, пока состояние базы данных остается неизменным.
Пользователь реализует фиксацию состояния, открывая сессия отбора проб .
Во время этого сеанса все последующие состояния базы данных, то есть более старые версии объектов, игнорируются.
Таким образом, в каждый момент времени один пользователь либо ничего не делает, либо выполняет один из двух сеансов: транзакционный или выборочный.
Государственные объекты
Хотя бы одно состояние базы данных — фон , всегда актуально.Фоновое состояние формируется полным набором объектов, напрямую адресованных из DAT, часть из которых остается на диске, а часть загружается в память.
Динамика многопользовательского процесса такова, что пользователи, выполняя транзакции, генерируют последовательность новых временный состояния База данных.
При успешном завершении очередного сеанса транзакции сгенерированное ею временное состояние становится общедоступным.
При открытии сеанса выборки пользователю предоставляется доступное состояние с наибольшим номером.
После существования в течение некоторого времени временные состояния, которые больше не используются для целей выборки, последовательно поглощаются фоновым состоянием.
Любое состояние, в том числе и фоновое, владеет определённым набором государственные объекты , которые соединены в одноименную цепочку.
Обратите внимание: временные объекты состояния — это упомянутые выше объекты транзакций, ставшие актуальными в результате успешного завершения сессии транзакции.
В фоновой цепочке состояний объекты располагаются в порядке убывания времени, когда они не использовались.
Доступ к содержимому объекта автоматически перемещает объект в конец цепочки.
Объекты в начале цепочки — кандидаты на выселение из памяти.
Кэш .
Ранее упоминалось, что попытка изменить существующий объект автоматически генерирует его новую версию.
Таким образом, в памяти одновременно может находиться несколько версий одного и того же объекта.
Эти версии связаны в одноимённую цепочку.
Указатель ( А* ) первый объект в цепочке версий находится в DAT, а сама цепочка позволяет пользователю получить доступ к «правильной» версии объекта в необходимом состоянии.
В этом случае корректной (актуальной с точки зрения пользователя) считается версия с наибольшим номером статуса, не превышающим требуемый.
Распределение состояний объектов, связанных в цепочки состояний и версий, выглядит примерно так: 
Процесс поглощения состояния инициируется последним, кто использовал его после завершения сеанса.
При поглощении очередного временного состояния фоновое состояние сначала удаляет из памяти устаревшие версии объектов, для которых существует новая версия в поглощенном состоянии, а затем просто присоединяет цепочку объектов поглощенного состояния к своей собственной.
Для управления многопользовательским доступом, состояниями базы данных и их объектами используйте таблица состояний СТ (Таблица состояний).
Таблица состояний
Каждая запись ST содержит указатель ( А* ) к первому объекту в цепочке объектов состояния, идентификаторам пользователя и объекта блокировки, а также количеству пользователей, использующих это состояние.Что касается таблицы ST, существует три внешних указателя, которые работают с полным номером состояния базы данных.
Если размер таблицы кратен степени двойки, то использование младших цифр абсолютного числа в качестве индекса таблицы ST гарантирует, что указатели будут перемещаться по таблице по кругу.
Указатель фонового состояния ( Б.
С.
) содержит номер фонового состояния.
Когда используется последующее временное состояние, указатель BS увеличивается.
Условием поглощения является нулевое значение счетчиков использования сразу двух состояний: фона и следующего.
Условие проверяется при закрытии любой из сессий после уменьшения счетчика использования.
Индикатор последнего доступного состояния ( Л.
С.
) содержит номер наивысшего доступного состояния.
Этот номер предоставляется пользователю при открытии сеанса выборки.
При закрытии следующей сессии транзакции указатель LS увеличивается, автоматически получая номер этой сессии.
Индикатор следующего состояния ( Н.
С.
) предоставляет номер состояния пользователю, открывающему сеанс транзакции, и затем увеличивается.
Если нет открытых транзакционных сессий, то значение NS превышает значение LS на 1. Если временных состояний нет, то значения указателей BS и LS совпадают. Номер статуса, полученный пользователем при открытии любой сессии, сохраняется в соответствующей записи.
таблицы клиентов КТ (Таблица клиентов).
Все пользовательские вызовы API сервиса объектов включают идентификатор клиента, а остальные данные извлекаются из соответствующей записи CT.
Таблица клиентов
Системный идентификатор клиента — это порядковый номер записи, выделенной ему в Таблице клиентов при авторизации.В этой таблице фиксируются как системные ресурсы, выделенные клиенту: дескрипторы TCP-сокетов и потоков, так и используемые им ресурсы в системе управления данными, и в частности количество открытых пользователем состояний, а также различные элементы управления.
флаги.
Решение конфликта
Напомним: транзакции, независимо от их длительности и результата, должны завершаться строго в том порядке, в котором они были начаты, в порядке возрастания собственных номеров.Для организации такой очереди используется пул именованных объектов блокировки, которые создаются вместе с таблицей ST при инициализации системы.
Непосредственно при открытии транзакционного сеанса из пула запрашивается объект свободной блокировки, который немедленно приобретается пользовательским потоком и удерживается им до завершения сеанса.
Идентификатор захваченного объекта блокировки сохраняется в соответствующем состоянии записи ST. Затем предыдущая запись состояния проверяется на наличие незавершенной транзакции в виде текущего идентификатора объекта блокировки.
При параллельном выполнении транзакций всегда существует неприятная возможность того, что более ранняя транзакция изменит содержимое объекта после того, как последующая транзакция использует тот же объект в своих целях.
Накладные расходы на постоянное отслеживание такого конфликта очень высоки.
И ее разрешение возможно только путем повторного выполнения всех последующих транзакций.
Если есть предыдущая незавершенная транзакция, текущая, пытаясь избежать конфликта, меняет логику своего выполнения.
Напомним, что доступ к диску — самая трудоемкая из всех операций, выполняемых объектной службой.
Поэтому пока выполняется предыдущая транзакция, текущая лишь имитирует ее выполнение — без фактического создания копий объекта и изменения их содержимого.
В этом случае все объекты, которые так или иначе были использованы транзакцией, гарантированно будут загружены в Кэш.
Когда выполнение моделирования завершено, транзакция перепроверяет запись ST предыдущего состояния.
Если из него получен идентификатор объекта блокировки, то транзакция зависает при попытке получить этот объект. После того как объект блокировки будет снят предыдущей транзакцией, текущая продолжит свое выполнение, но теперь уже в обычном режиме и с минимальным временем выполнения.
Аварийные ситуации
Если что-то пойдет не так (например, фатальная ошибка службы объектов или аппаратный сбой), то спасти базу данных сможет только автоматическое восстановление с контрольной точки.В более мягком случае, когда клиентский поток «упал и не восстановился» или ушел в бесконечность, оставив свою сессию открытой, можно предотвратить полную остановку конвейера состояний.
Зависание транзакционного сеанса будет обнаружено, когда новая транзакция не сможет получить свободный объект из пула, который для этой цели содержит вдвое меньше блокирующих объектов, чем таблица записей ST. В этом случае проблемным состоянием является состояние с индексом [LS+1].
Остановка сеанса выборки будет обнаружена только тогда, когда все свободные записи ST будут исчерпаны, то есть когда индексы BS и NS равны.
Замороженное состояние с индексом [BS] или [BS+1] будет иметь ненулевое значение счетчика использования.
Независимо от причины сбоя сеанса, его последствия всегда одни и те же: после получения идентификатора «замороженного пользователя» его поток принудительно останавливается, все используемые ресурсы освобождаются, сессия принудительно завершается, после чего конвейер закрывается.
самостоятельно выгрузился в обычном режиме.
Все эти действия выполняются в теме пользователя, обнаружившего проблему.
После завершения операций восстановления поток зависшего пользователя перезапускается, и пользователь делает хотя бы одну попытку повторить неудачный сеанс.
Если второй терпит неудачу, пользователь запускает свой поток, ожидая внешних событий.
Весь этот процесс регулируется флагами, установленными пользователю в Таблице Клиентов.
Кортеж значений
Содержимое объекта представляет собой набор его значений, хранящихся в формате кортежа.Свойства кортежа позволяют использовать его как универсальный с точки зрения хранения и доступа способ организации данных.
Стоит отметить, что менеджер памяти ( ММ ) объектный сервис, обеспечивающий работу всех его частей, включая объекты Cache, изначально ориентирован на поддержку формата кортежей.
Логически кортеж — это последовательность элементов, идентифицируемых своим порядковым номером в кортеже.
Элемент кортежа содержит значение, характеризующееся его длиной.
Длина значения известна априори и включается в заголовок значения.
Кортеж реализован как массив относительных указателей.
Каждый указатель представляет собой смещение начала значения относительно начала кортежа.
И смещение, и размеры измеряются в байтах.
Кортеж обладает рядом замечательных свойств.
Прежде всего, значением кортежа может быть другой кортеж.
С этой точки зрения все содержимое объекта можно рассматривать как единое значение.
Длина любого значения известна из его заголовка, что означает, что также известно количество элементов в кортеже.
Порядок элементов в кортеже строгий и неизменный.
Операция «Вставка» отключена.
Но вы можете безболезненно добавлять новые элементы к существующему набору.
В кортеже неинициализированное значение будет иметь нулевое значение смещения, которое отличается от «пустого» значения с нулевой длиной.
С неинициализированным значением можно работать без конфликтов, в том числе рассматривать его как «пустое» значение.
Кортеж может содержать структуру данных произвольной сложности.
По логике формат кортежа напоминает XML, но только с индексами вместо тегов и возможностью оперировать не только текстовыми значениями.
Доступ к одному значению в сложной структуре можно получить напрямую, используя последовательность индексов (маршрут) в качестве адреса.
Или вы можете сделать это относительно кортежа-владельца.
Кортеж имеет возможность создавать свои собственные экземпляры.
? экземпляр кортежа отличается от своей копии нулевыми значениями смещения для всех своих значений, которые в свою очередь не являются кортежами.
Другими словами, экземпляр — это копия структуры.
Кортеж значений может существовать как в сериализованном виде (непрерывный набор байт для хранения на диске), так и в случайном виде, в котором отдельные значения кортежа располагаются в разных местах оперативной памяти.
Смещение относительно начала кортежа также может иметь отрицательное значение.
Последние две из перечисленных особенностей поведения кортежа активно используются при изменении объекта во время сеанса транзакции.
Изменение объекта
Строго говоря, изменение объекта означает изменение одного или нескольких его значений.Хотя ранее упоминалось, что копия объекта создается для внесения изменений, на самом деле нет необходимости копировать весь объект. Вместо его копии в Cache создается экземпляр объекта с обнуленными указателями в кортеже.
При обращении к такому неинициализированному значению результат возвращается как значение, извлеченное из предыдущей версии объекта (экономия памяти).
Новое значение, присвоенное объекту, также помещается в кэш объектов, а смещение нового значения относительно экземпляра объекта записывается в соответствующий элемент кортежа.
Далее, если транзакция завершится успешно, созданные таким образом объекты транзакции необходимо загрузить на диск.
Сохранение объектов
Файловое пространство, выделенное для хранения объектов, не только кластеризуется, но и делится на банки данных по два в степени N кластеров.Каждый банк занимает один файл, который называется порядковым номером банка.
Таким образом, при обращении к объекту на диске его ФП последовательно преобразуется сначала в имя файла, а затем в номер кластера в файле.
Для минимизации дисковых операций, а также времени, необходимого для автоматического восстановления системы после аварии, все объекты, независимо от их первичного местонахождения, хранятся в одном банке.
Для этих целей резервируется непрерывная область памяти соответствующего размера (оптимально 32 МБ), и в этот банк памяти последовательно записываются объекты транзакций до тех пор, пока он не заполнится.
Перед записью длина (в кластерах) всех объектов суммируется, и если в банке памяти недостаточно свободного места, у системы запрашивается новый банк, а полный ставится в очередь в потоке записи.
Объекты транзакции сохраняются при закрытии сеанса транзакции.
Запись объекта в память начинается с начала следующего свободного кластера, при этом формируется новый ФП объекта.
Новый ФП не рассчитывается, если в этой памяти уже присутствует предыдущая версия объекта и ее размер позволяет записать в это место новую версию.
Полная версия объекта записывается в память со всеми значениями его кортежа, как измененными, так и заимствованными из предыдущей версии.
В процессе записи объект сериализуется, при этом вычисляются новые указатели (смещения) в кортеже.
После завершения сеанса измененные объекты транзакции в Кэше становятся общедоступными как есть, а именно с неполным кортежем.
Эти объекты должны заменить предыдущие версии.
Объединение версий
Естественно, если у объекта есть в памяти последующая версия, то такой объект нельзя выселить из Кэша с целью получения свободного места, даже если он находится в самом начале цепочки выселения.Для такого объекта предусмотрен другой порядок перемещения, но вместо него пока будет вытеснен другой человек в очереди.
Предыдущая версия объекта (далее версия [0]) вытесняется из памяти его последующей версией [+1], и это происходит при поглощении временного состояния фоновым.
И здесь есть одна тонкость исполнения.
Версия [0], обычно загружаемая с диска, занимает непрерывную область в Кэше, тогда как кортеж и новые значения версии [+1] находятся в разных местах, увеличивая дефрагментацию памяти.
Поэтому сценарий потребления версии [+1] выглядит более привлекательным, чем сценарий вытеснения версии [0].
Если новое значение версии [+1] не больше существующего, то оно просто копируется в тело версии [0], а занимаемая им память освобождается.
В противном случае это новое значение остаётся вне объекта как есть, и для него вычисляется новое смещение и объекту устанавливается флаг, обязывающий обычный процесс смещения проанализировать объект на наличие фрагментов за его границами.
Оформление сделок
Во время выполнения сеанса транзакции транзакция формализуется в объектный формат. Элементы-кортежи этого объекта формируются в результате элементарных действий, таких как создание объекта или изменение одного из его значений.В заголовке объекта, помимо прочего, хранится идентификатор пользователя, от имени которого была выполнена транзакция, а также отметка даты/времени начала транзакции.
Если сеанс транзакции завершается успешно, то при закрытии сеанса оформленная таким образом транзакция помещается в очередь записи.
Стоит отметить, что порядок постановки транзакции в очередь и банка объектов, формируемый при закрытии одной сессии, определяется тем, удалось ли разместить объекты транзакции в этом банке.
В случае успеха формализованная транзакция помещается первой в очередь.
Если для размещения объектов данной транзакции открыт новый банк, то банк объектов помещается первым в очередь.
Последовательность формализованных транзакций, хранящаяся на диске, образует журнал транзакций.
Журнал транзакций
Полный журнал транзакций представляет собой основную форму событий существования базы данных.Последовательное повторное выполнение содержимого журнала создает содержимое базы данных, полностью идентичное полученному в многопользовательском режиме работы.
Эта особенность определяет использование журнала как элемента обеспечения надежности.
Кроме того, стоит отметить, что у журнала есть еще одна функция - фискальная, которая уже не раз доказывала свою полезность в разборках типа ".
программа облажалась".
Запись на диск
Сохранение данных на диске осуществляется потоком записи — фоновым потоком, который обслуживает хранилище файлов.Информация о данных, которые будут храниться: указатель на область памяти, размер области и тип данных, извлекается потоком записи из очереди.
По завершении записи в файл поток самостоятельно освобождает переданную ему область памяти.
Тип данных определяет целевой файл, в который будут записаны данные.
Существует всего три основных типа данных: формализованные транзакции, банки объектов и DAT. Поток записи записывает все транзакции в один постоянно открытый файл журнала транзакций.
В файле транзакции следуют одна за другой, без выравнивания.
Перед записью транзакции вычисляется ее контрольная сумма и записывается в заголовок, а по завершении записи производится принудительная фиксация.
Когда приходит время сохранить банк объектов, поток записи сначала создает еще одну контрольную точку и только потом записывает банк в файл.
Чтобы создать контрольную точку, поток записи закрывает текущий файл журнала, упаковывает его в резервную копию, упаковывает содержимое банка в отдельный файл, упаковывает резервную копию полного DAT и открывает новый файл журнала.
В результате действий потока записи файловое хранилище принимает следующий вид: 
В рабочей области находятся DAT и банки объектов.
Область резервного копирования содержит архивные копии банков объектов и файлов, которые вместе образуют полный журнал транзакций.
Каждый отдельный файл журнала транзакций вместе с архивной копией DAT, а также архивными копиями собственного и предыдущих банков объектов образует отдельную контрольную точку.
Контрольно-пропускной пункт
Во время инициализации файлового хранилища при запуске системы проверяется его валидность.Хранилище считается пригодным к использованию, если контрольные суммы совпадают со значениями в заголовках файлов, а содержимое рабочей области соответствует содержимому резервной области.
Если сервер не был выключен должным образом, то, как минимум, произойдет сбой DAT в рабочей области и последний файл журнала транзакций, и автоматически запустится процесс восстановления из самой последней контрольной точки.
Логика восстановления вполне очевидна: отсутствующие или поврежденные банки восстанавливаются из резервных копий банка объектов, а затем восстанавливается DAT-файл с самой последней контрольной точки, после чего последовательно выполняются транзакции из его журнала.
Поскольку сохранение самой последней транзакции в журнале не гарантируется, если контрольная сумма транзакции не совпадает, процесс завершается.
Вывоз мусора
В нашем распоряжении только два физических ресурса: память и процессорные циклы.А поскольку производительность является приоритетом, следствием этого является увеличение потребления памяти.
Таким образом, чтобы уменьшить объем файловых операций, новые и измененные объекты сохраняются на диске целиком, как один файл.
При этом более ранние версии изменяемых объектов остаются на своих исходных местах в предыдущих банках и никогда больше не будут использоваться.
Чтобы вернуть дисковую память в систему, внутренне «прореженный» банк необходимо периодически «уплотнять», уменьшая его размер, не забывая при этом вносить изменения в DAT и перезаписывать архивную копию банка.
Чтобы облегчить анализ занятости банка, служба объектов постоянно поддерживает актуальность растрового изображения кластера.
Серверная архитектура
Все относительно простые функциональные возможности, описанные выше, сгруппированы вокруг структур данных внутреннего контроля службы хранилища файлов и объектов.Файловое хранилище отвечает за надежность долговременного хранения данных, что обеспечивается как многократным резервным копированием базы данных в различных ее формах, включая журнал транзакций, так и наличием механизмов автовосстановления.
Служба объектов обеспечивает многопользовательский доступ к содержимому базы данных минимальными средствами.
Модель данных использование структурированных метаданных, также хранящихся в объектном формате, обеспечивает логическую связность объектов данных и согласованность их значений в полном соответствии с бизнес-логикой приложения, интегрированной непосредственно в метаданные.
Пользовательский слой Курсоры , которые являются своего рода логическим подобием курсоров SQL, представляют собой серверную часть ресурсов интерфейса, используемую для взаимодействия пользователя с содержимым базы данных.
Этот, что очень важно, помимо всего прочего, обеспечивает полную изоляцию интерфейса от внутренней системы идентификации объектов и их значений.
Внутренняя логика Модели и Курсоров, а также способы ее реализации — тема отдельного рассказа.
Масштабируемость
Потенциал масштабируемости обеспечивается двумя факторами: изоляцией одного объекта, а также разделением действий пользователя на выбор и транзакцию.Если вам необходимо увеличить нагрузочную способность, первое, что приходит на ум — это выбрать отдельный мастер-сервер из пула серверов.
Главный сервер хранит эталонную копию базы данных и занимается исключительно выполнением транзакций.
Он получает транзакции от других серверов, которые обслуживают запросы пользователей и генерируют образцы.
Результатом выполнения является поток модифицированных версий объектов, который главный сервер транслирует всем остальным серверам, обслуживающим выборку данных, одновременно обеспечивая множественную репликацию базы данных.
Наличие значительной неоднородности логической связи объектов в базе данных (объекты могут группироваться в домены с сильной связностью внутри домена и небольшим количеством связей за его пределами) позволяет распределить базу данных на несколько мастер-серверов, каждый из которых обслуживает свои собственные группы доменов.
Подробный анализ особенностей реализации выходит за рамки данной статьи, но сами ее принципы являются предметом обсуждения.
За кулисами
Как это часто бывает при изложении достаточно объемного материала, было упущено множество относительно мелких и второстепенных деталей.Например, не были упомянуты: сегментация и дублирование DAT в памяти; особый порядок управления «крупными» объектами; принципы организации взаимной блокировки пользовательских потоков при доступе к общим ресурсам; логика и реализация сборки мусора; отображение процесса выполнения в журнале регистрации; сбор и отображение статистики; и многое другое.
Важно было показать, что управление многопоточными объектами основано на достаточно тривиальной логике и не является такой сложной для реализации задачей.
Краткое содержание
Вариант реализации, доведенный до примитивизма, скорее всего, окажется наиболее эффективным и действенным.Хотя мнения по этому поводу могут Теги: #базы данных #объектная база данных #архитектура системы #программирование #Анализ и проектирование систем #Алгоритмы
-
Миф О Предпочтительном Стиле Обучения
19 Oct, 24 -
Главу Apple Оценили В $20 Млрд.
19 Oct, 24 -
Таймлапс-Таймер На Arduino
19 Oct, 24 -
Тос, Ккпм. Обязательно Прочтите
19 Oct, 24
