Re[2]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:33
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы

Зачем распределенный map/reduce (еще один модный базворд? ) — если банальный MSSQL в tpc-E тесте безо всяких распределений выдает 4К транзакций в секунду, а Oracle в tpc-C 30 миллионов транзакций в минуту. И это честные согласованные транзакции, с ACID и всем остальным антуражем, а не какая-то там одна запись.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[3]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:34
Оценка:
Здравствуйте, 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>Это от того что не умеют правильно её использовать.

Это общие слова, которые может сказать любой, даже тот, кто ничего не умеет. Покажи, что умеешь.
Re[8]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 09:36
Оценка:
Здравствуйте, netch80, Вы писали:

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


F>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>>А где его достаточно? Таких задач исчезающе мало.
N>>>Такие задачи на каждом десктопе Вспомним реестр Windows.
N>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
G>>Реестр Windows — не универсальное хранилище.
N>Именно так! И поэтому у него специализированный движок.
То есть лучше не использовать реестр виндовс, пока не доказано обратное.
С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.
Re[6]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:36
Оценка: +2
Здравствуйте, netch80, Вы писали:

N>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.

Да ладно? Что же там в SQL не ложится? )
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.12.10 09:37
Оценка: +1
Здравствуйте, 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>©


M>Думаю, это достаточно философское замечание


Что делает его еще более философским, так это то, что верно и инвертированное утверждение:
Любая достаточно сложная SQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины NoSQL
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:39
Оценка:
Здравствуйте, IB, Вы писали:

N>>И сомнительно, и бессмысленно.

IB>Совершенно верно — NoSQL это сомнительно и в большинстве случаев бессмыслено. =))

С передёрга чужих слов обычно что начинается? Правильно, слив

N>>Как тут уже заметил noetic, ключевое слово — _нужной_ половины.

IB>Нет, ключевое слово — неспецифицированную, глючную и медленную. И если она даже после этого нужная, то тем хуже для noSql.

Новое и сырое всегда легко критиковать.
Сейчас речь идёт о том, что направление, которое долго было в тени, получило взрывной рост. Такие вещи не происходят только потому, что кому-то вдруг захотелось свежатинки.

N>> А многим не подходит даже модель реляционной базы.

IB>Только в том случае, если они не умеют реляционкой пользоваться.

Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?
Re[4]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 09:39
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

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


S>>С такими требованиями вам и ОЛАПы подойдут

AAV>Большинство хороших ОЛАП движков это NoSQL решения...
Большинство OLAP движков появилось когда про NoSQL еще никто не знал.

S>>А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения

AAV>В NoSql базы вставляются не значения, а объекты.//

И от этого все сразу стало круто-круто.
Re[7]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:40
Оценка:
Здравствуйте, IB, Вы писали:

N>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.

IB>Да ладно? Что же там в SQL не ложится? )

Предложи метод укладки, а я оценю его адекватность для наших задач.
Re[5]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:41
Оценка: 1 (1)
Здравствуйте, gandjustas, Вы писали:

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


S>>>С такими требованиями вам и ОЛАПы подойдут

AAV>>Большинство хороших ОЛАП движков это NoSQL решения...
G>Большинство OLAP движков появилось когда про NoSQL еще никто не знал.

А представляешь себе, до великой статьи Дейта уже были базы данных. И они явно были не SQL.
Re: Про NoSQL
От: Фанатик Ад http://vk.com/id10256428
Дата: 03.12.10 09:41
Оценка:
Учил БД давно, когда слова NoSQL не существовало.
Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели
понимаю как "отсутствие возможности общаться с СУБД посредством языка SQL" — т.е. кастрат-версия СУБД, не вижу в этом смысла.

ЗЫ: параллельно с SQL можно дать другой метод взаимодействия с СУБД, оба интерфейса могут быть опциональными.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[9]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

F>>>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>>>А где его достаточно? Таких задач исчезающе мало.
N>>>>Такие задачи на каждом десктопе Вспомним реестр Windows.
N>>>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
G>>>Реестр Windows — не универсальное хранилище.
N>>Именно так! И поэтому у него специализированный движок.
G>То есть лучше не использовать реестр виндовс, пока не доказано обратное.

С чего это такой вывод?

G>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.


Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
Re[2]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 09:44
Оценка:
Здравствуйте, Фанатик, Вы писали:

Ф>Учил БД давно, когда слова NoSQL не существовало.

Ф>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели

А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10).

Ф>понимаю как "отсутствие возможности общаться с СУБД посредством языка SQL" — т.е. кастрат-версия СУБД, не вижу в этом смысла.


Конечно, если заранее задать бессмысленную входную посылку, смысла не будет
Re[9]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 09:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Только поддержка целостности в таком зоопарке огромный геморрой, неподвластный разработчикам обычных проектов.

G>Делают проще: выделяют основное хранилище, к которому обращаются все остальные при необходимости.
G>Угадай какая система становится основным хранилищем?

Курим Теорму Брюера на тему "проще"
Re[3]: Про NoSQL
От: Фанатик Ад http://vk.com/id10256428
Дата: 03.12.10 09:49
Оценка:
Здравствуйте, netch80, Вы писали:

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


Ф>>Учил БД давно, когда слова NoSQL не существовало.

Ф>>Вероятно поэтому разделяю СУБД на реляционные и нереляционные. А NoSQL применительно к реляционной модели

N>А зачем применять его к реляционной модели? Эти базы как раз не используют её (по крайней мере ни одна из известных мне ~10).


Т.е. NoSQL — лишнее слово.

1) "NoSQL" == "Нереляционные СУБД"
2) понятие "Нереляционные СУБД" появилось раньше
Вывод: "NoSQL" — новомодное слово, которое совершенно необязательно понимать.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[8]: Про NoSQL
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.12.10 09:51
Оценка: 1 (1)
Здравствуйте, 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
)
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:53
Оценка: +1 -3
Здравствуйте, netch80, Вы писали:

N>Предложи метод укладки, а я оценю его адекватность для наших задач.

Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
В чем у тебя сложность?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[4]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 09:53
Оценка: -1
Здравствуйте, netch80, Вы писали:

N>С передёрга чужих слов обычно что начинается? Правильно, слив

Сдаешься? )

N>Новое и сырое всегда легко критиковать.

Да я и не утверждаю, что мне сложно ))

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

Ага, такое происходит потому, что свежатинка стала легко доступна. NoSQL обрел популярность ровно по той же причине, что и ORM — есть иллюзия, что можно не думать о хранилище и просто работать с "объектами". Последствия таких заблуждений тоже хорошо известны.

N>Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?

Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[9]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 09:57
Оценка:
Здравствуйте, IB, Вы писали:

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


N>>Предложи метод укладки, а я оценю его адекватность для наших задач.

IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
IB>В чем у тебя сложность?

А в терминах инструкций к CPU вообще можно все писать куда более эффективно даже, чем на ваших джавах..
netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе
Re[5]: Про NoSQL
От: noetic Украина Систематизация автоматизации
Дата: 03.12.10 09:59
Оценка:
Здравствуйте, IB, Вы писали:

IB>Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.


В реляционку ложиться все — тут без проблем. Но иногда вместо кухонного комбайна овощи можно порезать простым ножом
Re[5]: Про NoSQL
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.12.10 10:08
Оценка:
Здравствуйте, IB, Вы писали:

N>>С передёрга чужих слов обычно что начинается? Правильно, слив

IB>Сдаешься? )

Чего?

N>>Прошу доказательств данному выводу. В нём есть квантор общности. Ты уверен, что знаешь _все_ случаи применения NoSQL?

IB>Не передергивай. )) Нас интересуют только те случаи где, по твоему утверждению, модель данных не ложится на реляционку.

Откуда ты взял про "не ложится"? Это уже подтасовка моих слов. Я говорил:

для большинства NoSQL-применений специфика такова, что на SQL их укладывать даже если можно, то совершенно неадекватно.


Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.


его применение будет жуткой натяжкой с громоздким middleware


Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.

А вот ты в своём сообщении уже допустил второе подряд обобщение с подтасовкой фактов. Нехорошо.

Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого. Какой ты метод организации базы предложишь, более эффективный, чем имитация файловой системы?

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

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


N>>Предложи метод укладки, а я оценю его адекватность для наших задач.

IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
IB>В чем у тебя сложность?

В построении _эффективного_ решения, чтобы оно было выгоднее, чем текущее хранилище.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.