Здравствуйте, netch80, Вы писали:
G>>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
N>>>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.
G>>Ну так расскажи что за задача.
N>Мониторинг распределённой сети, управление функционированием по результатам мониторинга, включая автоматические реакции. Слабосвязанной или сильносвязанной сети — уже пофиг, общие подходы едины, в том смысле, что рваться могут по любому
Ну так SSCM, SCOM на вполне реляционной СУБД работают и ниче.
Поподробнее опиши характер данных.
G>>>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.
N>>>Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования.
G>>Веб, учетные задачи, автоматизация документооборота. Эти задачи традиционно требуют массового хранения данных.
N>Учётные — да, в общем случае готов согласиться.
N>Веб — это вообще не задача по своей природе, это интерфейс. Его же внутренние задачи не имеют никакой заточки для реляционной модели — наоборот, традиционное хранилище "кука => параметры" это key-value.
Проблема только в том как получить список ключей
Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.
N>Автоматизация документооборота — нет, в типичном случае документ сопровождается большим количеством сложноспецифицируемых атрибутов типа "получена виза отдела снабжения", укладка которых на реляционную модель неестественна (даже если тривиальна).
Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.
И NoSQL тут сдается. Ему надо map\reduce индексы писать под каждый такой запрос. Малейшее изменение деталей запроса приведет к изменению индекса.. ну вы поняли.
