Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>>>Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано. G>>К сожалению многие повелись на NoSQL-hype и пихают его во все дыры. Хотя как основное хранилище NoSQL базы почти не пригодны.
N>Ты судишь только с одной колокольни. N>Для примера, нам под наши задачи нужны N>* key-value хранилище с иерархическими ключами и значениями достаточно произвольной природы — под конфигурацию (в общем, похоже на реестр; если бы был распределённый реестр под Linux, взяли бы его) N>* группированное по пулам key-value хранилище в памяти с репликацией пула только между определёнными узлами, и опять-таки природа значений не определена (большинство крошечные, но может быть и BLOB'ы на десятки килобайт) N>* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов N>SQL хоть как-то подходит только под третий пункт, для остального его применение будет жуткой натяжкой с громоздким middleware, скрывающим отсутствие иерархической структуры данных.
N>И где тут описанное тобой "основное хранилище"?
Ты как-бы привел ваше РЕШЕНИЕ, а не задачу. Расскажи подробнее про задачу тебе решений накидают.
Большинство обычных СУБД вытянут базы на 100гб и не поморщатся при нормальной схеме. Никаких распределенных хранилищ не понадобится.
Как писал Синклер (щас не найду пост) в любых данных есть две части: регулярная (реляционная) и нерегулярная (блобы или XML).
В худшем случае в регулярную часть попадают только ключи, но это редкость.
Решение строится так: регулярная часть укладывается в SQL базу данных, нерегулярная хранится блобами.
Если сама субд не поддерживает хранение блобов отдельно от остальных данных, то это делается ручками.
Если субд не поддерживает полнотекстовый индекс по блобам\xml, то полнотекстовое индексирование делается внешними инструментами.
Ну и собственно все.
Причем! чем больше нерегулярная часть данных, тем позже возникнет потребность шардить регулярную часть. А чем больше регулярная часть данных, тем удобнее при этом пользоваться SQL.
N>>>Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит. G>>Современные СУБД умею гораздо больше, чем описано в стандартах SQL 92. G>>Применяя те же методы проектирования и развертывания, что в NoSQL, можно добиться результатов не хуже, чем в NoSQL решениях.
N>Вот я привёл пример наших требований. Опиши хоть вчерне, на каких доступных сейчас средствах и каким образом ты бы её реализовывал поверх SQL. Ограничения среды — Linux.
См. выше.
Хотя я по линуксовым базам не спец. Для MS SQL напишу решение, аналогичные возможности для того же postgres или oracle под линух найти не сложно будет.
ЗЫ. Единственное во что реально упереться в СУБД, так это в скорость записи. Даже с отключенными блокировками она ниже, чем в специализированном решении. Такое может возникнуть при потоковой обработке, но тут у MS SQL есть решение — Stream Insight.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
AAV>>>Здравствуйте, Sinix, Вы писали:
S>>>>С такими требованиями вам и ОЛАПы подойдут AAV>>>Большинство хороших ОЛАП движков это NoSQL решения... G>>Большинство OLAP движков появилось когда про NoSQL еще никто не знал.
N>А представляешь себе, до великой статьи Дейта уже были базы данных. И они явно были не SQL.
И где они сейчас?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, netch80, Вы писали:
N>>Предложи метод укладки, а я оценю его адекватность для наших задач.
A>Итак, реестр. Давай начнём с простого, а ты выскажешь свои претензии.
A>
A>CREATE TABLE [dbo].[Registry]
A>(
A> [ID] hierarchyid] NOT NULL,
A> [Level] AS ([ID].[GetLevel]()) PERSISTED,
A> [Parent] AS ([ID].[GetAncestor](1)) PERSISTED,
A> [Name] nvarchar(256) NOT NULL
A> [Value] varbinary(MAX) NOT NULL
A>)
A>
Претензий с ходу несколько:
1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием
a.p = 1
a.q = 2
zz = 3
2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.
3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
F>>>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет? G>>>>>>А где его достаточно? Таких задач исчезающе мало. N>>>>>Такие задачи на каждом десктопе Вспомним реестр Windows. N>>>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой. G>>>>Реестр Windows — не универсальное хранилище. N>>>Именно так! И поэтому у него специализированный движок. G>>То есть лучше не использовать реестр виндовс, пока не доказано обратное.
N>С чего это такой вывод?
Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе?
G>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище. N>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности.
ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.
Здравствуйте, Фанатик, Вы писали:
Ф>>>Учил БД давно, когда слова NoSQL не существовало. Ф>>>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели N>>А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10). Ф>Т.е. NoSQL — лишнее слово. Ф>1) "NoSQL" == "Нереляционные СУБД"
Ну в общем да.
Ф>2) понятие "Нереляционные СУБД" появилось раньше Ф>Вывод: "NoSQL" — новомодное слово, которое совершенно необязательно понимать.
Кому как. Я просто принял к сведению факт, что сейчас "это" называют именно так.
Здравствуйте, noetic, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>Только поддержка целостности в таком зоопарке огромный геморрой, неподвластный разработчикам обычных проектов. G>>Делают проще: выделяют основное хранилище, к которому обращаются все остальные при необходимости. G>>Угадай какая система становится основным хранилищем?
N>Курим Теорму Брюера на тему "проще"
А причем тут CAP теорема? Для подавляющего большинства проектов не нужна распределенная база. Не каждый день люди пишут фейсбуки.
M>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL. F>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
G>А где его достаточно? Таких задач исчезающе мало.
memcached, который некоторые заменяют redis'ом, например
вообще, все можно свести к понятию «ключ-значение» при условии, что «значение» может быть достаточно сложным
тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )
Здравствуйте, gandjustas, Вы писали:
N>>Курим Теорму Брюера на тему "проще"
G>А причем тут CAP теорема? Для подавляющего большинства проектов не нужна распределенная база. Не каждый день люди пишут фейсбуки.
согласен. но надо же сравнивать два подхода в примерно равных условиях, чтобы четче все +/- отследить.
Здравствуйте, gandjustas, Вы писали:
G>>>То есть лучше не использовать реестр виндовс, пока не доказано обратное. N>>С чего это такой вывод? G>Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе?
А с чего это мы должны тут рассматривать интернет-магазин? Это очень специализированная задача, с моей точки зрения и никак не соответствует моим задачам.
G>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище. N>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства. G>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное. G>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.
G>Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности.
Ну, ответил. Говори.)
G>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач.
Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования.
Здравствуйте, netch80, Вы писали:
N>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием N>a.p = 1 N>a.q = 2 N>zz = 3
Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему?
N>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.
Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.
N>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае.
Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт.
Здравствуйте, gandjustas, Вы писали:
G>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
Проекты-агрегаторы данных. Скачать с десятка ебэй-магазинов пару десятков тыщ ордеров в виде достаточно развесистых документов и выдать клиенту сервис по постобработке этих данных. База упала? Хрен с ней — перезакачаем, пересчитаем.
Здравствуйте, adontz, Вы писали:
N>>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием N>>a.p = 1 N>>a.q = 2 N>>zz = 3
A>Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему?
Меня устраивает тут и рассмотрение реестра Windows. А чем этот пример, по-твоему, противоречит реестру?
N>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать. A>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.
Вполне подходит. Ты используешь какие-то специфические средства специфической реализации. Объясни их, достаточно по паре слов на каждое.
N>>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае. A>Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт.
Например, он может храниться в основном теле таблицы, если до K байт, в малом пуле блобов, если >=M, и в большом пуле, если >=N.
Здравствуйте, adontz, Вы писали:
N>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать.
A>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей.
Стоит ли обсуждать преимущество архитектурных решений перед инфраструктурными? Конечно, без хаков платформы прожить сложно, но если есть возможность не завязываться, почему бы и нет?
Здравствуйте, netch80, Вы писали:
N>>>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием N>>>a.p = 1 N>>>a.q = 2 N>>>zz = 3 A>>Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему? N>Меня устраивает тут и рассмотрение реестра Windows. А чем этот пример, по-твоему, противоречит реестру?
Ну в реестре есть разделение на ключи и значения. Описание ветки достаточно стандартно.
[HKEY_LOCAL_MACHINE\Key1\Key2]
"Name"="Value"
N>>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать. A>>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей. N>Вполне подходит. Ты используешь какие-то специфические средства специфической реализации. Объясни их, достаточно по паре слов на каждое.
dbo — Database Owner. Что-то типа пространства имён.
PERSISTED — вычисляемый столбец, но значения физически хранятся в БД.
nvarchar — UNICODE строка переменной длины
hierarchyid — специальный тип для хранения иерархических отношений
N>>>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае. A>>Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт. N>Например, он может храниться в основном теле таблицы, если до K байт, в малом пуле блобов, если >=M, и в большом пуле, если >=N.
Здравствуйте, Mamut, Вы писали:
M>>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL. F>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
G>>А где его достаточно? Таких задач исчезающе мало.
M>memcached, который некоторые заменяют redis'ом, например
Те NoSQL это не более чем распределенный кеш?
M>вообще, все можно свести к понятию «ключ-значение» при условии, что «значение» может быть достаточно сложным
Да, тогда станет вопрос о том как получать список нужных ключей. Собственно язык SQL дает ответ на этот вопрос, а различные NoSQL хранилища — нет.
Полнотекстовым индеском все не заменишь, а вручную создавать индексы под каждый запрос — как то слишком круто.
M>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )
Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.
A>CREATE TABLE [dbo].[Registry]
A>(
A> [ID] hierarchyid] NOT NULL,
A> [Level] AS ([ID].[GetLevel]()) PERSISTED,
A> [Parent] AS ([ID].[GetAncestor](1)) PERSISTED,
A> [Name] nvarchar(256) NOT NULL
A> [Value] varbinary(MAX) NOT NULL
A>)
A>
Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии. На это же можно возразить тем, что в некоторых NoSql есть и транзакционность и возможность написания макросов для поддержки целостности базы данных...
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Чувак. hierarchyid это вообщето объектная структура => это элементы NoSql, как и калькулируемые столбцы. Нечестное ведение дискусии.
HIERARCHYID это обычный массив байт, ценный только методами для манипуляции с ним. Никакой объектной структуры там нет. Калькульруемые столбцы — NoSQL? простите, а VIEW — тоже NoSQL?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>>>То есть лучше не использовать реестр виндовс, пока не доказано обратное. N>>>С чего это такой вывод? G>>Ну давай посмотрим как в реестре хрнаить классическую базу инет-магазина: клиенты-заказы-позиции-товары, и как будут выглядеть "запросы" к такой базе?
N>А с чего это мы должны тут рассматривать интернет-магазин? Это очень специализированная задача, с моей точки зрения и никак не соответствует моим задачам.
Я вот смотрю вакансии: 80% это веб и автоматизация предпирятий (документооборот и учетные системы). Ни одна из этих задач хорошо не ложится на реестр или NoSQL.
Это кореллирует с тем с какими задачами ко мне обращаются заказчики.
G>>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище. N>>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства. G>>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное. G>>А я вот не могу сходу придумать ни одной задачи, где не потребуется надежность хранения(Durability).
N>Я — могу и вижу своими глазами. Для нашей задачи хранения исторических данных допустимо, например, что по отказу диска несколько последних изменений потеряются. Для оперативной информации ещё интереснее — она должна регулярно обновляться и экспайриться, а взаимодействие — выживать после разрыва, существенно не обращая на него внимания. Для конфигурации чуть сложнее, но общая схема примерно такова же. В общем, автономность и восстановление от проблем связности важнее традиционного ACID, которое вообще не терпит разрыва на любом участке и в случае невозможности узнать про успех операции на всех участках — просто откатывает её.
Ну так расскажи что за задача.
G>>Как сможешь ответить на этот аргумент начнем говорить о согласованности и атомарности. N>Ну, ответил. Говори.)
Аргумент "у нас все работает", вообще-то не аргумент. Общая практика как раз говорит об обратном, несмотря на хайп. А если вам повезло, то могу только поздравить.
Опиши свою задачу конкретнее, тогда посмотрим что и как у вас можно сделать средствами SQL баз данных.
G>>ЗЫ. Как бы для NoSQL баз (опять таки хранилищ) вообще нету никаких доказательств пригодности их для широкого спектра задач. N>Когда определишь, что именно входит здесь в широкий спектр — тогда и можно будет уточнять требования.
Веб, учетные задачи, автоматизация документооборота. Эти задачи традиционно требуют массового хранения данных.
Здравствуйте, adontz, Вы писали:
N>>>>1. Формат таблицы ещё ничего не говорит о том, как она используется. Ты это не описал, я по данному описанию не могу понять. Прошу описать, например, как будет выглядеть заполненная таблица с содержанием N>>>>a.p = 1 N>>>>a.q = 2 N>>>>zz = 3 A>>>Мы всё ещё говорим о реестре Windows или ты решил выбрать другую тему? N>>Меня устраивает тут и рассмотрение реестра Windows. А чем этот пример, по-твоему, противоречит реестру?
A>Ну в реестре есть разделение на ключи и значения. Описание ветки достаточно стандартно. A>
[HKEY_LOCAL_MACHINE\Key1\Key2]
A>"Name"="Value"
Хорошо, отщипни HKEY_LOCAL_MACHINE\ в начале и замени бэкслэши на точки — получишь мой пример. И строго наоборот.
Возвращаюсь к исходному вопросу: как будет выглядеть таблица в этом случае?
N>>>>2. Мне ничего не говорят слова [dbo], PERSISTED, nvarchar, hierarchyid. Я готов заранее признаться, что ничего не понимаю в некоторых SQL движках или в новых стандартах, но тем не менее прошу расшифровать. A>>>Так может лучше сперва прочитать про всё это? Я не думаю что формат сообщения в форуме подходит для объяснения подобных вещей. N>>Вполне подходит. Ты используешь какие-то специфические средства специфической реализации. Объясни их, достаточно по паре слов на каждое. A>dbo — Database Owner. Что-то типа пространства имён. A>PERSISTED — вычисляемый столбец, но значения физически хранятся в БД. A>nvarchar — UNICODE строка переменной длины A>hierarchyid — специальный тип для хранения иерархических отношений
Понятно, ничего специфического, кроме собственно типа hierarchyid. Это целое число или что-то более хитрое?
N>>>>3. Ничего не сказано об эффективности хранения поля типа varbinary в конкретном движке, без этих данных сложно сказать, насколько оно будет хорошо работать в конкретном случае. A>>>Я не очень понимаю как можно более или менее эффективно хранить неосмысливаемый массив байт. N>>Например, он может храниться в основном теле таблицы, если до K байт, в малом пуле блобов, если >=M, и в большом пуле, если >=N. A>Всегда в теле таблицы.
В таком случае хранение будет ужасающе неэффективно. В моём случае большинство значений короче 60 байт, но некоторые достигают десятков килобайт. Если таблица на диске будет представляться B-деревом или аналогом, то одна строка может просто не влезть в страницу, а если последовательными чанками с длиной или аналогичным подходом, то проходы по ней будут очень медленны. Подход а-ля FS с каждой строкой в отдельном файле тоже ничего хорошего не даст.
В практически известных мне примерах БД всё-таки стараются такие вещи выселять отдельно по превышению некоторого предельного размера.
И они явно были не SQL.
