Здравствуйте, noetic, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
N>Проекты-агрегаторы данных. Скачать с десятка ебэй-магазинов пару десятков тыщ ордеров в виде достаточно развесистых документов и выдать клиенту сервис по постобработке этих данных. База упала? Хрен с ней — перезакачаем, пересчитаем.
Вся ирония ситуации в том, что без Durability ты даже не узнаешь что упало
Фактически операция записи в базу в NoSQL зачастую не оставляет никаких долговременных следов о том что она была выполнена. При падении сервера он после перезагрузки не знает что эта операция была вызвана.
Фактически тебе придется постоянно перезакачивать данные, чтобы иметь хоть какую-то гарантию. Или в чисто NoSQL-ном стиле делать шарднг на кучу машин и надеяться что все будет ОК.
Здравствуйте, gandjustas, Вы писали:
G>>>>>То есть лучше не использовать реестр виндовс, пока не доказано обратное. N>>>>С чего это такой вывод? G>>>Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе? N>>А с чего это мы должны тут рассматривать интернет-магазин? Это очень специализированная задача, с моей точки зрения и никак не соответствует моим задачам. G>Я вот смотрю вакансии: 80% это веб и автоматизация предпирятий (документооборот и учетные системы). Ни одна из этих задач хорошо не ложится на реестр или NoSQL. G>Это кореллирует с тем с какими задачами ко мне обращаются заказчики.
Ну так я и не предлагаю впихивать нереляционные базы в эти 80%. Но кое-кто повёл разговор в ту сторону, что для них вообще нет применения, а это уже явный перегиб.
G>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability). N>>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её. G>Ну так расскажи что за задача.
Мониторинг распределённой сети, управление функционированием по результатам мониторинга, включая автоматические реакции. Слабосвязанной или сильносвязанной сети — уже пофиг, общие подходы едины, в том смысле, что рваться могут по любому
G>>>Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности. N>>Ну, ответил. Говори.) G>Аргумент "у нас все работает", вообще-то не аргумент. Общая практика как раз говорит об обратном, несмотря на хайп. А если вам повезло, то могу только поздравить. G>Опиши свою задачу конкретнее, тогда посмотрим что и как у вас можно сделать средствами SQL баз данных.
Чего не хватает в предыдущих описаниях?
G>>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач. N>>Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования. G>Веб, учетные задачи, автоматизация документооборота. Эти задачи традиционно требуют массового хранения данных.
Учётные — да, в общем случае готов согласиться.
Веб — это вообще не задача по своей природе, это интерфейс. Его же внутренние задачи не имеют никакой заточки для реляционной модели — наоборот, традиционное хранилище "кука => параметры" это key-value.
Автоматизация документооборота — нет, в типичном случае документ сопровождается большим количеством сложноспецифицируемых атрибутов типа "получена виза отдела снабжения", укладка которых на реляционную модель неестественна (даже если тривиальна).
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, ArhAngelVezel, Вы писали:
AAV>>Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии.
A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?
Конечно, а полнотекстовый индекс это вообще самый NoSQL. А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.
Здравствуйте, netch80, Вы писали:
N>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов
А что вы применяете для этой части, если не секрет?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, netch80, Вы писали:
N>>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов
К>А что вы применяете для этой части, если не секрет?
Сейчас — RRD, но не устраивает. Ищем альтернативы в стиле распределённой разделяемой памяти поверх RDMA.
Здравствуйте, adontz, Вы писали:
A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.
Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.
A>Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?
Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур. Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...
G>>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability). N>>>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её. G>>Ну так расскажи что за задача.
N>Мониторинг распределённой сети, управление функционированием по результатам мониторинга, включая автоматические реакции. Слабосвязанной или сильносвязанной сети — уже пофиг, общие подходы едины, в том смысле, что рваться могут по любому
Ну так SSCM, SCOM на вполне реляционной СУБД работают и ниче.
Поподробнее опиши характер данных.
G>>>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач. N>>>Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования. G>>Веб, учетные задачи, автоматизация документооборота. Эти задачи традиционно требуют массового хранения данных.
N>Учётные — да, в общем случае готов согласиться. N>Веб — это вообще не задача по своей природе, это интерфейс. Его же внутренние задачи не имеют никакой заточки для реляционной модели — наоборот, традиционное хранилище "кука => параметры" это key-value.
Проблема только в том как получить список ключей
Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.
N>Автоматизация документооборота — нет, в типичном случае документ сопровождается большим количеством сложноспецифицируемых атрибутов типа "получена виза отдела снабжения", укладка которых на реляционную модель неестественна (даже если тривиальна).
Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.
И NoSQL тут сдается. Ему надо map\reduce индексы писать под каждый такой запрос. Малейшее изменение деталей запроса приведет к изменению индекса.. ну вы поняли.
Здравствуйте, netch80, Вы писали: N>Хорошо, отщипни HKEY_LOCAL_MACHINE\ в начале и замени бэкслэши на точки — получишь мой пример. И строго наоборот. N>Возвращаюсь к исходному вопросу: как будет выглядеть таблица в этом случае?
А тут SQL
DROP PROCEDURE [CreateRegistryKey]
DROP TABLE [RegistryValue];
DROP TABLE [RegistryKey];
GO
CREATE TABLE [RegistryKey]
(
[HID] HIERARCHYID NOT NULL,
[HLevel] AS ([HID].[GetLevel]()) PERSISTED,
[HParent] AS ([HID].[GetAncestor](1)) PERSISTED,
[Name] NVARCHAR(256) NOT NULL
)
GO
CREATE TABLE [RegistryValue]
(
[HID] HIERARCHYID NOT NULL,
[Name] NVARCHAR(256) NOT NULL,
[Value] VARBINARY(MAX) NOT NULL,
)
GO
ALTER TABLE [RegistryKey] ADD CONSTRAINT [RegistryKey/PK] PRIMARY KEY CLUSTERED ([HID], [Name]);
CREATE UNIQUE NONCLUSTERED INDEX [RegistryKey/UK] ON [RegistryKey]([HID])
GO
INSERT INTO [RegistryKey]([HID], [Name]) VALUES (hierarchyid::GetRoot(), '');
GO
ALTER TABLE [RegistryValue] ADD CONSTRAINT [RegistryValue/PK] PRIMARY KEY CLUSTERED ([HID], [Name]);
GO
ALTER TABLE [RegistryValue] ADD CONSTRAINT [RegistryValue/FK] FOREIGN KEY([HID]) REFERENCES [RegistryKey]([HID]);
GO
CREATE PROCEDURE [CreateRegistryKey](
@ParentID HIERARCHYID,
@Name NVARCHAR(256))
AS
BEGIN
DECLARE @ParentHierarchyID hierarchyid;
DECLARE @SiblingHierarchyID hierarchyid;
DECLARE @HierarchyID hierarchyid;
IF @ParentID IS NULL
SET @ParentID = hierarchyid::GetRoot();
SELECT
@ParentHierarchyID = [HID]
FROM
[RegistryKey]
WHERE
[HID] = @ParentID;
SELECT
@SiblingHierarchyID = MAX([HID])
FROM
[RegistryKey]
WHERE
[HID].GetAncestor(1) = @ParentHierarchyID;
SET @HierarchyID = @ParentHierarchyID.GetDescendant(@SiblingHierarchyID, NULL);
INSERT INTO
[RegistryKey]([HID], [Name])
VALUES
(@HierarchyID, @Name);
END
GO
CREATE PROCEDURE [CreateRegistryValue](
@HID HIERARCHYID,
@Name NVARCHAR(256),
@Value VARBINARY(MAX))
AS
BEGIN
INSERT INTO
[RegistryValue]([HID], [Name], [Value])
VALUES
(@HID, @Name, @Value);
END
GO
EXEC [CreateRegistryKey] NULL, 'A';
EXEC [CreateRegistryKey] NULL, 'ZZ';
DECLARE @Hid1 HIERARCHYID;
DECLARE @Hid2 HIERARCHYID;
SELECT @Hid1 = [HID] FROM [RegistryKey] WHERE [Name] = 'A';
SELECT @Hid2 = [HID] FROM [RegistryKey] WHERE [Name] = 'ZZ';
EXEC [CreateRegistryValue] @Hid1, 'P', 0x01;
EXEC [CreateRegistryValue] @Hid1, 'Q', 0x02;
EXEC [CreateRegistryValue] @Hid2, '', 0x03;
SELECT * FROM [RegistryKey];
SELECT * FROM [RegistryValue];
RegistryKey
0x
0
NULL
0x58
1
0x
A
0x68
1
0x
ZZ
RegistryValue
0x58
P
0x01
0x58
Q
0x02
0x68
0x03
N>Понятно, ничего специфического, кроме собственно типа hierarchyid. Это целое число или что-то более хитрое?
Это массив байт. Считай ещё ещё одним VARBINARY. N>В таком случае хранение будет ужасающе неэффективно.
Я предпочитаю измерять производительность, а не рассуждать о ней.
M>Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL
M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.
Со словом "медленная" категорически не согласен. По долгу службы сейчас пишу на C++, потому что SQL сильно тормозит. Да и не все запросы на него хорошо ложатся.
Здравствуйте, gandjustas, Вы писали:
G>Конечно, а полнотекстовый индекс это вообще самый NoSQL.
Так и есть. Полнотекстовый индекс никакого отношения к тому что понимают по словом SQL не имеет. С этим нельзя спорить.
G>А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, adontz, Вы писали:
A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. AAV>Что такое объект в ООП? Это данные и методы работы с этими данными.
Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность.
AAV>Поэтому, да, HIERARCHYID это объект.
Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)?
A>>Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL? AAV>Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур.
Что есть "стандартные процедуры"? MS SQL вполне стандартно имеет возможность писать код на .NET.
AAV>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...
Большего бреда не читал никогда.
Давай рассматривать тупо существующие хранилища, не вешая ярлыки на их возможности.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, adontz, Вы писали:
A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. AAV>Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.
Вопросы резервного копирования данных, их целостности, работа хранилища в условиях нехватки памяти, параллельные запросы — эти вопросы разработчики НЕ ПОНИМАЮТ ДО КОНЦА, и не в состоянии их эффективно решить.
Будем реалистами — специлисты широкого профиля редко хорошо знают НЕСКОЛЬКО областей одновременно.
Те, что владеют DB-разработкой обычно РУГАЮТ NoSQL.
Те, что НЕ владеют DB-разработкой НАДЕЯТСЯ на NoSQL.
Я могу пересчитать по пальцам одной руки своих знакомых, которые ИСПОЛЬЗУЮТ NoSQL, и ПОНИМАЮТ почему они это делают.
AAV>Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур.
[facepalm]
Пожалйста, подучите матчасть.
[/facepalm]
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Mamut, Вы писали:
M>>
M>>Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL
M>>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.
M>Со словом "медленная" категорически не согласен. По долгу службы сейчас пишу на C++, потому что SQL сильно тормозит. Да и не все запросы на него хорошо ложатся.
Видимо ты просто не знаешь его
Рассказываю тайну. SQL база данных может спокойно порвать любой твой код, потому что СУБД оптимизирует доступ к диску. А это сейчас самая медленная операция.
Здравствуйте, IB, Вы писали:
IB>Зачем распределенный map/reduce (еще один модный базворд? )
Почитайте что такое map/reduce и почему такие решения могут обрабатывать миллионы сообщений в секунду, при этом не "пересчитывая" триллионы операций.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.
ANS>Вообще-то это фатальное преимущество, а не недостаток.
Здравствуйте, ArhAngelVezel, Вы писали:
A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. AAV>Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.
INT — это данные и методы работы с ними (сложение, вычитание). INT — объект.
AAV>Если View написана с использованием C#
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Конечно, а полнотекстовый индекс это вообще самый NoSQL.
ANS>Так и есть. Полнотекстовый индекс никакого отношения к тому что понимают по словом SQL не имеет. С этим нельзя спорить.
Да и к NoSQL не имеет тогда уж. В СУБД полнотекстовый поиск где-то с 2000 поддерживается, а может и раньше. Такому явлению как NoSQL от силы года 3.
Кроме того в самом потоке NoSQL ничего нового в полнотекстовом поиске придумано не было.
К SQL имеет самое прямое отношение ибо можно прямо в SQL запросе указать предикаты CONTAINS и FREETEXT.
Здравствуйте, gandjustas, Вы писали:
G>Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, gandjustas, Вы писали:
G>>Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.
AAV>Подучите матчасть, как тут советуют фанатики RDBMS: AAV>http://www.mongodb.org/display/DOCS/Indexes AAV>http://www.mongodb.org/display/DOCS/Querying
Ну и? приведешь как сделать указанный мной запрос на mongodb?
Заодно и схему нарисуй, а потом мы на ней другие юзкесы проверим