С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.
Здравствуйте, Mamut, Вы писали:
M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.
Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы
Здравствуйте, Mamut, Вы писали:
M>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.
По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Сделайте мне распределенный map/reduce на любой SQL базе данных (Oracle, MSSQL и т.д.) с обработкой хотя-бы 1000 записей в секунду и я скажу, что вы правы
С такими требованиями вам и ОЛАПы подойдут
А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения
NoSQL хорош для примитивных моделей данных с низкой связностью. К сожалению, модели данных с низкой связностью не очень хороши для подавляющего большинства задач.
Здравствуйте, Mamut, Вы писали:
A>>http://zabivator.livejournal.com/412053.html
M>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.
Да что там, даже full-text search в SQL базе данных это тоже NoSQL, по словам некоторых здешних обитателей.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Mamut, Вы писали:
M>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL. F> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
Здравствуйте, Mamut, Вы писали:
M>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.
И сомнительно, и бессмысленно.
Сомнительно — потому, что для большинства NoSQL-применений специфика такова, что на SQL их укладывать даже если можно, то совершенно неадекватно.
Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано.
Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит. А многим не подходит даже модель реляционной базы.
Здравствуйте, gandjustas, Вы писали:
M>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL. F>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
G>А где его достаточно? Таких задач исчезающе мало.
Такие задачи на каждом десктопе Вспомним реестр Windows.
Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
M>>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL. F>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
G>>А где его достаточно? Таких задач исчезающе мало.
N>Такие задачи на каждом десктопе Вспомним реестр Windows. N>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой.
Реестр Windows — не универсальное хранилище. В нем жутко неудобно хранить нефиксированное множество.
Каждое приложение пользуется фиксированным конечным множеством ключей, зачастую отказываясь от такого хранилища в пользу конфигурационных файлов.
Здравствуйте, Sinix, Вы писали:
S>С такими требованиями вам и ОЛАПы подойдут
Большинство хороших ОЛАП движков это NoSQL решения...
S>А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения
В NoSql базы вставляются не значения, а объекты.//
NoSQL это не key-value базы, не ORM, не отрицание SQL или реляционной модели, это использование движков к базе не только с колокольни реляционной модели.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Mamut, Вы писали:
M>>Любая достаточно сложная NoSQL-программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины SQL.
N>И сомнительно, и бессмысленно. N>Сомнительно — потому, что для большинства NoSQL-применений специфика такова, что на SQL их укладывать даже если можно, то совершенно неадекватно. N>Бессмысленно — потому, что фактически идёт взрывной рост направления, и такого рода обобщающие оценки, как "10-е правило Гринспуна", выставлять просто рано.
К сожалению многие повелись на NoSQL-hype и пихают его во все дыры. Хотя как основное хранилище NoSQL базы почти не пригодны.
N>Как тут уже заметил noetic, ключевое слово — _нужной_ половины. При том, что NoSQL-средства в основном развиваются в сторону обеспечения скорости определённых шаблонов работы, типов запросов, нагрузки, etc., универсальное средство тут не подходит.
Современные СУБД умею гораздо больше, чем описано в стандартах SQL 92.
Применяя те же методы проектирования и развертывания, что в NoSQL, можно добиться результатов не хуже, чем в NoSQL решениях.
N>А многим не подходит даже модель реляционной базы.
Это от того что не умеют правильно её использовать.
Здравствуйте, gandjustas, Вы писали:
G>не универсальное хранилище
Кто сказал что NoSQL должно быть универсальным хранилищем? Если бы это было бы так, то они конкурировали бы за место под солнцем. Но нет же. Зачастую в одном проекте используется несколько типов хранилищ, как традиционных реляционных, так и NoSql. Через key-value кешируются обращения к сайту, на реляционке висит авторизация, на документ-ориентированной — профили, на map/reduce — обработка сырых данных, на олапе — аналитика и т.д....
Здравствуйте, gandjustas, Вы писали:
F>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет? G>>>А где его достаточно? Таких задач исчезающе мало. N>>Такие задачи на каждом десктопе Вспомним реестр Windows. N>>Попытка укладки его на SQL в любом виде представляет собой просто насилие над базой. G>Реестр Windows — не универсальное хранилище.
Именно так! И поэтому у него специализированный движок.
G> В нем жутко неудобно хранить нефиксированное множество. G>Каждое приложение пользуется фиксированным конечным множеством ключей, зачастую отказываясь от такого хранилища в пользу конфигурационных файлов.
S>>С такими требованиями вам и ОЛАПы подойдут AAV>Большинство хороших ОЛАП движков это NoSQL решения...
Ну, если уважать приоритеты — то большинство NoSQL — это своеобразно переделанные ОЛАПы. Хумор в том, что ОЛАПы плохо подходят для ОЛАПа и к тому что щас понимается под носкулем имеют весьма посредственное отношение.
S>>А теперь сделайте нам транзакционное обновление. Для начала — вставку уникального значения AAV>В NoSql базы вставляются не значения, а объекты.//
Вай сколько пафоса Хранение Объектов означает неважность всяких там ограничений и согласованности данных?
AAV>NoSQL это не key-value базы, не ORM, не отрицание SQL или реляционной модели, это использование движков к базе не только с колокольни реляционной модели.
Я таки советую пройти по ссылке, что запостил adonz. NoSql — это очень нишевое и очень недешёвое в плане сопровождения и развития решение. И с колокольней, увы, рядом даже не ползало
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, gandjustas, Вы писали:
G>>не универсальное хранилище AAV>Кто сказал что NoSQL должно быть универсальным хранилищем? Если бы это было бы так, то они конкурировали бы за место под солнцем.
Если база не сможет нормально работать с теми данным, которыми захочет пользователь, то нафиг такая база не нужна.
AAV>Но нет же. Зачастую в одном проекте используется несколько типов хранилищ, как традиционных реляционных, так и NoSql. Через key-value кешируются обращения к сайту, на реляционке висит авторизация, на документ-ориентированной — профили, на map/reduce — обработка сырых данных, на олапе — аналитика и т.д....
Только поддержка целостности в таком зоопарке огромный геморрой, неподвластный разработчикам обычных проектов.
Делают проще: выделяют основное хранилище, к которому обращаются все остальные при необходимости.
Угадай какая система становится основным хранилищем?
Здравствуйте, Sinix, Вы писали:
S>Хумор в том, что ОЛАПы плохо подходят для ОЛАПа и к тому что щас понимается под носкулем имеют весьма посредственное отношение.
Нда. Вообще-то для ОЛТП. Но и так неплохо вышло
Здравствуйте, netch80, Вы писали:
N>И сомнительно, и бессмысленно.
Совершенно верно — NoSQL это сомнительно и в большинстве случаев бессмыслено. =))
N>Как тут уже заметил noetic, ключевое слово — _нужной_ половины.
Нет, ключевое слово — неспецифицированную, глючную и медленную. И если она даже после этого нужная, то тем хуже для noSql.
N> А многим не подходит даже модель реляционной базы.
Только в том случае, если они не умеют реляционкой пользоваться. Все-таки, как совершенно верно замечено, порог вхождения в реляционку, на самом деле, довольно высок и есть иллюзия, что проще взять noSql и не забивать себе голову.
Мы уже победили, просто это еще не так заметно...
