July 7th, 2010

flow

выбор параметров фактохранилища

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

1. Для хранения фактов ныне принято использовать графовые базы данных. Это такое же общее место, как когда-то SQL для entities. Хороший рабочий пример: AllegroGraph (http://www.franz.com/agraph/allegrograph/). Совмещены триплеты и понятие контекста, что прекрасно подходит под дизайн из http://justy-tylor.livejournal.com/140577.html Пока недостаёт типов.

2. Типы и изменения. Провести полную валидацию модели можно только после её загрузки/получения. Однако, когда у нас есть внешняя информация об уникальности, упорядоченности и иных свойствах ряда фактов, то это как облегчает работу с базой, так и служит оптимизации хранения/доступа. Вопрос в том, как эту информацию указывать. Когда искал решение - вовремя вспомнил Redis (http://code.google.com/p/redis/wiki/CommandReference). Вместо "извлечь или создать список по ключу, затем дополнить его значением" база пополняется действиями вида "добавить в множество" или "добавить в хвост списка", с автоматическим созданием необходимых представлений. Что, опять же, не накладывает ограничений на физические характеристики хранилища, возможно там нет никаких списков, а упорядоченность между фактами реализована дополнительным индексом.

3. Доступ и чтение. Разные виды задач - разные селекторы. Для простой выборки по базе лучше подходит дизайн селекторов MongoDB (http://www.mongodb.org/display/DOCS/Manual). Сложнее - аналоги SQL (SPARQL), мини-Prolog. Общее - опять же, не стоит завязываться на некие "списки" возвращаемых значений. Можно заказать map/foreach по заданному селектору, или даже обход DAG по факту child.

Используя приведённые выше идеи можно совместить удобство, скорость работы и масштабируемость в рамках единого фактохранилища.