Дополнительная механика паттерна свойств

предыдущая серия

Сохранение списков свойств

Стив предсказуемо рекомендует сохранять наборы свойств в XML или JSON, благо сериализация в эти форматы поддерживается уже давно практически повсеместно, а нативный текстовый формат дополнительно удобен, так как прозрачен для чтения, редактирования и загрузки. Архивация этих форматов на сегодня тоже реализована уже наверное везде.

Если число объектов в системе не превышает единичных тысяч, вполне можно обойтись стандартной файловой системой. Когда же счёт идет на десятки и сотни тысяч, лучше воспользоваться специализированной СУБД, благо сегодня достаточно документо-ориентированных (читай — JSON-ориентированных) NoSQL-СУБД, да и обычные РСУБД тоже понемногу начинают достаточно эффективно поддерживать иерархические структуры данных. Преимущество специализированных СУБД наподобие MongoDb, отмечу из своего опыта — это прежде всего развитый API запросов и поиска и поддержка индексации произвольных полей документов (бессхемных структур).

Запросы

От формата хранения таким образом плавно переходим к теме запросов. Когда данные разбросаны по куче файлов, поиск-выборка нужных полей будет выполняться, конечно, ужасающе медленно. Так никогда не надо делать.

РСУБД подходят лишь частично — как уже отмечалось, из прототипов могут формироваться весьма объемные иерархии, поэтому для поиска нужны весьма развитые механизмы. Стив упоминает XML-движки, я дополнительно порекомендую такую миниатюрную файловую JSON-СУБД как LiteDb.

В общем случае, на сегодня инфраструктура серверной работы с XML/JSON — данными разработана весьма хорошо, и особо париться с потенциальными проблемами тут не стоит.

Консистентность

Из-за того, что паттерн свойств предлагает максимально гибкую модель, сразу возникает и немало проблем, связанных с целостностью крупной системы, поддерживающей, например, миллион иерархически унаследованных прототипов. Разные баги или ошибки пользователей будут постоянно проверять консистентность на прочность.

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

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

В случае паттерна свойств наиболее болезненными будут, пожалуй, добавления ошибочных названий свойств (особенно когда такая фича становится доступной конечным пользователям). Стив в частности рассказывает, что он нередко помогал backfill-системе, для чего создал административную подсистему, в которой вручную явно помечал свойства, выглядящие сбойными, после чего запускал «сборку прототипного мусора». В противном случае процесс восстановления после сбоев мог бы затянуться на дни.

В заключение мы рассмотрим систему типов применительно к паттерну свойств.

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *