Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:08
Оценка:
Здравствуйте, noetic, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:


G>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).


N>Проекты-агрегаторы данных. Скачать с десятка ебэй-магазинов пару десятков тыщ ордеров в виде достаточно развесистых документов и выдать клиенту сервис по постобработке этих данных. База упала? Хрен с ней — перезакачаем, пересчитаем.


Вся ирония ситуации в том, что без Durability ты даже не узнаешь что упало

Фактически операция записи в базу в NoSQL зачастую не оставляет никаких долговременных следов о том что она была выполнена. При падении сервера он после перезагрузки не знает что эта операция была вызвана.

Фактически тебе придется постоянно перезакачивать данные, чтобы иметь хоть какую-то гарантию. Или в чисто NoSQL-ном стиле делать шарднг на кучу машин и надеяться что все будет ОК.
Re[13]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 11:10
Оценка:
Здравствуйте, 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.
Автоматизация документооборота — нет, в типичном случае документ сопровождается большим количеством сложноспецифицируемых атрибутов типа "получена виза отдела снабжения", укладка которых на реляционную модель неестественна (даже если тривиальна).
The God is real, unless declared integer.
Re[11]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:12
Оценка:
Здравствуйте, adontz, Вы писали:

A>Здравствуйте, ArhAngelVezel, Вы писали:


AAV>>Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии.


A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?


Конечно, а полнотекстовый индекс это вообще самый NoSQL. А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.
Re[4]: Про NoSQL
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.12.10 11:16
Оценка:
Здравствуйте, netch80, Вы писали:

N>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов


А что вы применяете для этой части, если не секрет?
Re[5]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 11:18
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, netch80, Вы писали:


N>>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов


К>А что вы применяете для этой части, если не секрет?


Сейчас — RRD, но не устраивает. Ищем альтернативы в стиле распределённой разделяемой памяти поверх RDMA.
The God is real, unless declared integer.
Re[11]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:23
Оценка: -1 :))
Здравствуйте, adontz, Вы писали:

A>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.

Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.

A>Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?

Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур. Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:25
Оценка: -1
Здравствуйте, netch80, Вы писали:


G>>>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).

N>>>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.
G>>Ну так расскажи что за задача.

N>Мониторинг распределённой сети, управление функционированием по результатам мониторинга, включая автоматические реакции. Слабосвязанной или сильносвязанной сети — уже пофиг, общие подходы едины, в том смысле, что рваться могут по любому

Ну так SSCM, SCOM на вполне реляционной СУБД работают и ниче.

Поподробнее опиши характер данных.


G>>>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.

N>>>Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования.
G>>Веб, учетные задачи, автоматизация документооборота. Эти задачи традиционно требуют массового хранения данных.

N>Учётные — да, в общем случае готов согласиться.

N>Веб — это вообще не задача по своей природе, это интерфейс. Его же внутренние задачи не имеют никакой заточки для реляционной модели — наоборот, традиционное хранилище "кука => параметры" это key-value.
Проблема только в том как получить список ключей
Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.

N>Автоматизация документооборота — нет, в типичном случае документ сопровождается большим количеством сложноспецифицируемых атрибутов типа "получена виза отдела снабжения", укладка которых на реляционную модель неестественна (даже если тривиальна).

Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.
И NoSQL тут сдается. Ему надо map\reduce индексы писать под каждый такой запрос. Малейшее изменение деталей запроса приведет к изменению индекса.. ну вы поняли.
Re[14]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 11:25
Оценка:
Здравствуйте, 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>В таком случае хранение будет ужасающе неэффективно.


Я предпочитаю измерять производительность, а не рассуждать о ней.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Про NoSQL
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 03.12.10 11:32
Оценка:
Здравствуйте, 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.


Со словом "медленная" категорически не согласен. По долгу службы сейчас пишу на C++, потому что SQL сильно тормозит. Да и не все запросы на него хорошо ложатся.
Re[12]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.12.10 11:32
Оценка: -1 :)
Здравствуйте, gandjustas, Вы писали:

G>Конечно, а полнотекстовый индекс это вообще самый NoSQL.


Так и есть. Полнотекстовый индекс никакого отношения к тому что понимают по словом SQL не имеет. С этим нельзя спорить.

G>А уж не дай бог сказать по xml столбцы, тем более с индексами, то вообще nosql_нее не бывает.


При чем тут xml столбцы?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:33
Оценка:
Здравствуйте, 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...

Большего бреда не читал никогда.
Давай рассматривать тупо существующие хранилища, не вешая ярлыки на их возможности.
Re[12]: Про NoSQL
От: Sinix  
Дата: 03.12.10 11:35
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, adontz, Вы писали:


A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.

AAV>Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.

Таки почитайте

Вопросы резервного копирования данных, их целостности, работа хранилища в условиях нехватки памяти, параллельные запросы — эти вопросы разработчики НЕ ПОНИМАЮТ ДО КОНЦА, и не в состоянии их эффективно решить.

Будем реалистами — специлисты широкого профиля редко хорошо знают НЕСКОЛЬКО областей одновременно.
Те, что владеют DB-разработкой обычно РУГАЮТ NoSQL.
Те, что НЕ владеют DB-разработкой НАДЕЯТСЯ на NoSQL.
Я могу пересчитать по пальцам одной руки своих знакомых, которые ИСПОЛЬЗУЮТ NoSQL, и ПОНИМАЮТ почему они это делают.



AAV>Если View написана с использованием C#, то да, т.к. использует внутреннюю работу с базами в обход стандартных процедур.

[facepalm]
Пожалйста, подучите матчасть.
[/facepalm]
Re[2]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:35
Оценка: +2 -2
Здравствуйте, 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 база данных может спокойно порвать любой твой код, потому что СУБД оптимизирует доступ к диску. А это сейчас самая медленная операция.
Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.12.10 11:39
Оценка: +1 -3 :))) :))
Здравствуйте, gandjustas, Вы писали:

G>Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.


Вообще-то это фатальное преимущество, а не недостаток.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:39
Оценка: -1
Здравствуйте, IB, Вы писали:

IB>Зачем распределенный map/reduce (еще один модный базворд? )

Почитайте что такое map/reduce и почему такие решения могут обрабатывать миллионы сообщений в секунду, при этом не "пересчитывая" триллионы операций.
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:40
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Не говоря уже об инфраструктурных проблемах самого NoSQL, типа отсутствия ACID.


ANS>Вообще-то это фатальное преимущество, а не недостаток.


И как выражается это преимущество?
Re[12]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 11:45
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

A>>HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним.

AAV>Что такое объект в ООП? Это данные и методы работы с этими данными. Поэтому, да, HIERARCHYID это объект.

INT — это данные и методы работы с ними (сложение, вычитание). INT — объект.

AAV>Если View написана с использованием C#


Отсыпьте, я уже готов примкнуть.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:45
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


G>>Конечно, а полнотекстовый индекс это вообще самый NoSQL.


ANS>Так и есть. Полнотекстовый индекс никакого отношения к тому что понимают по словом SQL не имеет. С этим нельзя спорить.


Да и к NoSQL не имеет тогда уж. В СУБД полнотекстовый поиск где-то с 2000 поддерживается, а может и раньше. Такому явлению как NoSQL от силы года 3.
Кроме того в самом потоке NoSQL ничего нового в полнотекстовом поиске придумано не было.

К SQL имеет самое прямое отношение ибо можно прямо в SQL запросе указать предикаты CONTAINS и FREETEXT.
Re[15]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:47
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.


Подучите матчасть, как тут советуют фанатики RDBMS:
http://www.mongodb.org/display/DOCS/Indexes
http://www.mongodb.org/display/DOCS/Querying
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 11:51
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>Ну любые атрибуты можно положить в NoSQL хранилище. А потом возникают запросы типа, документы, подписанные ивановым за период, по указанной категории и вывести с постраничной разбивкой.


AAV>Подучите матчасть, как тут советуют фанатики RDBMS:

AAV>http://www.mongodb.org/display/DOCS/Indexes
AAV>http://www.mongodb.org/display/DOCS/Querying

Ну и? приведешь как сделать указанный мной запрос на mongodb?
Заодно и схему нарисуй, а потом мы на ней другие юзкесы проверим
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.