Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы
Зачем распределенный map/reduce (еще один модный базворд? ) — если банальный MSSQL в tpc-E тесте безо всяких распределений выдает 4К транзакций в секунду, а Oracle в tpc-C 30 миллионов транзакций в минуту. И это честные согласованные транзакции, с ACID и всем остальным антуражем, а не какая-то там одна запись.
Здравствуйте, gandjustas, Вы писали:
N>>Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано. G>К сожалению многие повелись на NoSQL-hype и пихают его во все дыры. Хотя как основное хранилище NoSQL базы почти не пригодны.
Ты судишь только с одной колокольни.
Для примера, нам под наши задачи нужны
* key-value хранилище с иерархическими ключами и значениями достаточно произвольной природы — под конфигурацию (в общем, похоже на реестр; если бы был распределённый реестр под Linux, взяли бы его)
* группированное по пулам key-value хранилище в памяти с репликацией пула только между определёнными узлами, и опять-таки природа значений не определена (большинство крошечные, но может быть и BLOB'ы на десятки килобайт)
* исторические количественные данные в стиле MRTG или RRD, с постепенной агрегацией при устаревании и необходимостью максимально быстрой выборки с разных узлов
SQL хоть как-то подходит только под третий пункт, для остального его применение будет жуткой натяжкой с громоздким middleware, скрывающим отсутствие иерархической структуры данных.
И где тут описанное тобой "основное хранилище"?
N>>Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит. G>Современные СУБД умею гораздо больше, чем описано в стандартах SQL 92. G>Применяя те же методы проектирования и развертывания, что в NoSQL, можно добиться результатов не хуже, чем в NoSQL решениях.
Вот я привёл пример наших требований. Опиши хоть вчерне, на каких доступных сейчас средствах и каким образом ты бы её реализовывал поверх SQL. Ограничения среды — Linux.
N>>А многим не подходит даже модель реляционной базы. G>Это от того что не умеют правильно её использовать.
Это общие слова, которые может сказать любой, даже тот, кто ничего не умеет. Покажи, что умеешь.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
F>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет? G>>>>А где его достаточно? Таких задач исчезающе мало. N>>>Такие задачи на каждом десктопе Вспомним реестр Windows. N>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой. G>>Реестр Windows — не универсальное хранилище. N>Именно так! И поэтому у него специализированный движок.
То есть лучше не использовать реестр виндовс, пока не доказано обратное.
С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.
Здравствуйте, netch80, Вы писали:
N>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
Да ладно? Что же там в SQL не ложится? )
Что делает его еще более философским, так это то, что верно и инвертированное утверждение:
Любая достаточно сложная SQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины NoSQL
Здравствуйте, IB, Вы писали:
N>>И сомнительно, и бессмысленно. IB>Совершенно верно — NoSQL это сомнительно и в большинстве случаев бессмыслено. =))
С передёрга чужих слов обычно что начинается? Правильно, слив
N>>Как тут уже заметил noetic, ключевое слово — _нужной_ половины. IB>Нет, ключевое слово — неспецифицированную, глючную и медленную. И если она даже после этого нужная, то тем хуже для noSql.
Новое и сырое всегда легко критиковать.
Сейчас речь идёт о том, что направление, которое долго было в тени, получило взрывной рост. Такие вещи не происходят только потому, что кому-то вдруг захотелось свежатинки.
N>> А многим не подходит даже модель реляционной базы. IB>Только в том случае, если они не умеют реляционкой пользоваться.
Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, Sinix, Вы писали:
S>>С такими требованиями вам и ОЛАПы подойдут AAV>Большинство хороших ОЛАП движков это NoSQL решения...
Большинство OLAP движков появилось когда про NoSQL еще никто не знал.
S>>А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения AAV>В NoSql базы вставляются не значения, а объекты.//
И от этого все сразу стало круто-круто.
Здравствуйте, IB, Вы писали:
N>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой. IB>Да ладно? Что же там в SQL не ложится? )
Предложи метод укладки, а я оценю его адекватность для наших задач.
Здравствуйте, gandjustas, Вы писали:
AAV>>Здравствуйте, Sinix, Вы писали:
S>>>С такими требованиями вам и ОЛАПы подойдут AAV>>Большинство хороших ОЛАП движков это NoSQL решения... G>Большинство OLAP движков появилось когда про NoSQL еще никто не знал.
А представляешь себе, до великой статьи Дейта уже были базы данных. И они явно были не SQL.
Учил БД давно, когда слова NoSQL не существовало.
Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели
понимаю как "отсутствие возможности общаться с СУБД посредством языка SQL" — т.е. кастрат-версия СУБД, не вижу в этом смысла.
ЗЫ: параллельно с SQL можно дать другой метод взаимодействия с СУБД, оба интерфейса могут быть опциональными.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, gandjustas, Вы писали:
F>>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет? G>>>>>А где его достаточно? Таких задач исчезающе мало. N>>>>Такие задачи на каждом десктопе Вспомним реестр Windows. N>>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой. G>>>Реестр Windows — не универсальное хранилище. N>>Именно так! И поэтому у него специализированный движок. G>То есть лучше не использовать реестр виндовс, пока не доказано обратное.
С чего это такой вывод?
G>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.
Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
Здравствуйте, Фанатик, Вы писали:
Ф>Учил БД давно, когда слова NoSQL не существовало. Ф>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели
А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10).
Ф>понимаю как "отсутствие возможности общаться с СУБД посредством языка SQL" — т.е. кастрат-версия СУБД, не вижу в этом смысла.
Конечно, если заранее задать бессмысленную входную посылку, смысла не будет
Здравствуйте, gandjustas, Вы писали:
G>Только поддержка целостности в таком зоопарке огромный геморрой, неподвластный разработчикам обычных проектов. G>Делают проще: выделяют основное хранилище, к которому обращаются все остальные при необходимости. G>Угадай какая система становится основным хранилищем?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Фанатик, Вы писали:
Ф>>Учил БД давно, когда слова NoSQL не существовало. Ф>>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели
N>А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10).
Т.е. NoSQL — лишнее слово.
1) "NoSQL" == "Нереляционные СУБД"
2) понятие "Нереляционные СУБД" появилось раньше
Вывод: "NoSQL" — новомодное слово, которое совершенно необязательно понимать.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, netch80, Вы писали:
N>Предложи метод укладки, а я оценю его адекватность для наших задач.
Итак, реестр. Давай начнём с простого, а ты выскажешь свои претензии.
CREATE TABLE [dbo].[Registry]
(
[ID] hierarchyid] NOT NULL,
[Level] AS ([ID].[GetLevel]()) PERSISTED,
[Parent] AS ([ID].[GetAncestor](1)) PERSISTED,
[Name] nvarchar(256) NOT NULL
[Value] varbinary(MAX) NOT NULL
)
Здравствуйте, netch80, Вы писали:
N>Предложи метод укладки, а я оценю его адекватность для наших задач.
Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
В чем у тебя сложность?
Здравствуйте, netch80, Вы писали:
N>С передёрга чужих слов обычно что начинается? Правильно, слив
Сдаешься? )
N>Новое и сырое всегда легко критиковать.
Да я и не утверждаю, что мне сложно ))
N>Сейчас речь идёт о том, что направление, которое долго было в тени, получило взрывной рост. Такие вещи не происходят только потому, что кому-то вдруг захотелось свежатинки.
Ага, такое происходит потому, что свежатинка стала легко доступна. NoSQL обрел популярность ровно по той же причине, что и ORM — есть иллюзия, что можно не думать о хранилище и просто работать с "объектами". Последствия таких заблуждений тоже хорошо известны.
N>Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?
Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, netch80, Вы писали:
N>>Предложи метод укладки, а я оценю его адекватность для наших задач. IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. ) IB>В чем у тебя сложность?
А в терминах инструкций к CPU вообще можно все писать куда более эффективно даже, чем на ваших джавах..
netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе
Здравствуйте, IB, Вы писали:
IB>Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.
В реляционку ложиться все — тут без проблем. Но иногда вместо кухонного комбайна овощи можно порезать простым ножом
Здравствуйте, IB, Вы писали:
N>>С передёрга чужих слов обычно что начинается? Правильно, слив IB>Сдаешься? )
Чего?
N>>Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL? IB>Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.
Откуда ты взял про "не ложится"? Это уже подтасовка моих слов. Я говорил:
для большинства NoSQL-применений специфика такова, что на SQL их укладывать даже если можно, то совершенно неадекватно.
Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
его применение будет жуткой натяжкой с громоздким middleware
Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.
А вот ты в своём сообщении уже допустил второе подряд обобщение с подтасовкой фактов. Нехорошо.
Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого. Какой ты метод организации базы предложишь, более эффективный, чем имитация файловой системы?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, netch80, Вы писали:
N>>Предложи метод укладки, а я оценю его адекватность для наших задач. IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. ) IB>В чем у тебя сложность?
В построении _эффективного_ решения, чтобы оно было выгоднее, чем текущее хранилище.
Мы уже победили, просто это еще не так заметно...
