Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Почему предприятия не заинтересованы в NoSQL?

Оригинал: Michael Stonebraker. Why Enterprises Are Uninterested in NoSQL. BLOG@CACM, September 30, 2010
От переводчика: Экклизиаст и ветряные мельницы
Много лет назад я осознал всю правоту "Книги Экклезиаста" применительно к технологии баз данных. И вот теперь у меня снова возникает ощущение déjà vu в связи со столкновениями сторонников подходов SQL и NoSQL. Уж очень это похоже на борьбу 20-летней давности сторонников того же подхода SQL со сторонниками объектно-ориентированного подхода к организации баз данных. И тот же Майкл Стоунбрейкер на той же стороне. Воистину: "Бывает нечто, о чем говорят: Смотри, вот,
это – новое! – но это было уже в веках, бывших прежде нас!"

Но есть и разница. В 1990-е гг. было хотя бы понятно, кто с кем борется. Лагерь ООБД был тогда достаточно сплоченным, и хотя отсутствовала общепринятая объектно-ориентированная модель данных, у разных реализаций ООСУБД было много общего (кроме чистого отрицания SQL). Теперешний же лагерь NoSQL включает самые разнообразные подходы, которые как раз не объединяет ровным счетом ничего (особенно, если учесть, что к нему относятся и системы категории Not Only SQL).

По-видимому, чтобы борьба с NoSQL не напоминала борьбу известного персонажа с ветряными мельницами, Майкл Стоунбрейкер выделяет три черты систем, относящихся к классу NoSQL (но не являющихся единственными представителями этого класса), которые делают эти системы неприемлемыми для корпоративного использования, а именно отсутствие поддержки:

  • ACID-транзакций,
  • языка SQL и
  • общепринятых стандартов.

В этом я вижу основной смысл заметки, перевод которой предлагается вашему вниманию. Замечу, что хотя мне близка позиция Майкла Стоунбрейкера, я не считаю направление NoSQL нежизнеспособным или, тем более, вредным. Хотим мы этого или не хотим, но движение NoSQL возникло в качестве реакции на неспособность SQL-ориентированных СУБД обеспечить решение проблем, стоящих перед Internet-компаниями. Поэтому мне бы очень хотелось видеть хорошие и грамотные статьи разработчиков и пользователей NoSQL-систем, в которых описывались бы их технические преимущества перед традиционными SQL-ориентированными СУБД. Не стоит бороться с ветряными мельницами. Как сказал еще один (очень!) известный автор, "пусть расцветают сто цветов, пусть соперничают сто школ" (хотя широко известно, к чему это привело ).

Сергей Кузнецов

Как пишет Одри Уоттерс (Audrey Watters) в блоге сайта ReadWriteWeb, из 755 опрошенных корпоративных пользователей 44% никогда не слышали про NoSQL, а еще у 17% отсутствует интерес. Почему же 61% корпоративных пользователей либо не знает про существование, либо не интересуется NoSQL? Эта заметка отражает мое мнение по этому вопросу.

Недавно я посетил выставку, где на переднем плане находились средства управления данными категории NoSQL. Там присутствовало много Web-разработчиков, главным образом, из начинающих компаний. Однако я был поражен отсутствием корпоративных пользователей. Так что мои (совершенно ненаучные) наблюдения согласуются с данными упомянутой выше заметки.

Кроме того, по моему опыту, большая часть информации среди корпоративных пользователей распространяется из уст в уста. Поэтому, если они о чем-то не слышали, это означает, что соответствующая информация не циркулирует в их профессиональной сети. Другими словами, любой в чем-то заинтересованный корпоративный профессионал вызывает дополнительный интерес в своей среде. При отсутствии интереса возникает поведение, описываемое в заметке Орди. Так почему же у предприятий отсутствует интерес к NoSQL?

Чтобы прояснить эту ситуацию, я обратился к очень заслуженному техническому специалисту крупного предприятия, который отвечает за отслеживание новых технологий систем управления базами данных (СУБД) в интересах своей компании. Я спросил его, интересуется ли он NoSQL, и заинтересована ли в NoSQL его компания. Он ответил мне, что такой интерес и у него, и у его компании отсутствует. Я спросил: "Почему?".

Сначала он сказал, что в его компании подавляющее большинство приложений распадается на два класса: приложения оперативной обработки транзакций (online transaction processing, OLTP), в которых часто происходят небольшие обновления баз данных, состоящих из структурированных записей, и приложения хранилищ и витрин данных (data warehouse/data mart), собирающие исторические бизнес-данные, к которым адресуются произвольные (ad hoc) запросы аналитиков. Хотя наряду с этими "краеугольными" классами приложений имеются и некоторые другие приложения, такие как управление документооборотом, они не считаются важными.

После этого он сделал один комментарий относительно OLTP, один комментарий по поводу хранилищ данных и один комментарий общего характера. Вот в чем их суть.

Отсутствие ACID равносильно отсутствию интереса

Многие данные OLTP, сохраняемые этой компанией, являются критически важными. Повреждение этих данных может привести к потери людьми их рабочих мест. В этом мире ACID является золотым стандартом обновления совместно используемых наборов данных. Любая система, не поддерживающая "настоящие" транзакции, заранее считается непригодной для использования в среде OLTP.

Даже если в настоящее время можно обойтись транзакциями над одной записью (поддержка такого рода транзакций обычно имеется в СУБД категории NoSQL), невозможно гарантировать, что в будущем никогда не понадобятся транзакции над несколькими записями. Другими словами, в компании моего собеседника считается, что в будущем поддержка свойств ACID может потребоваться для любого набора данных OLTP, и возможность использования систем, не поддерживающих ACID-транзакции даже не обсуждается.

Низкоуровневые языки запросов убийственны

К хранилищам данных часто адресуются запросы типа "действительно ли на юге сувениры из самоцветов продаются лучше, чем куклы Барби?". В пионерской статье Теда Кодда "Реляционная модель данных для больших совместно используемых банков данных" ("A Relational Model of Data for Large Shared Data Banks"), опубликованной в 1970 г., отстаивалась потребность в пользовательском интерфейсе, позволяющем сформулировать свои потребности в данных, а не то, как следует прочитать их с диска. Последующее сорокалетнее развитие технологии СУБД показало, что высокоуровневые языки, подобные SQL, облегчают формулировку таких произвольных запросов к хранилищам данных. Компания моего заслуженного специалиста редко проявляет интерес к поддерживаемым в большинстве продуктов NoSQL алгоритмическим интерфейсам с доступом к данным на уровне записей, поскольку их использование означало бы возврат к временам IMS и CODASYL.

NoSQL означает отсутствие стандартов

В компании моего собеседника имеется большое число баз данных (по-видимому, больше 10000), и компанию, очевидно, волнует число различных видов интерфейсов, которые должны знать прикладные программисты. Иначе говоря, для крупной компании важны стандарты.

По-видимому, в настоящее время имеется около 50 систем NoSQL, каждая из которых обладает своим собственным пользовательским интерфейсом. Большинство из них опирается на модели данных, уникальные для этих систем, а также поддерживает уникальные интерфейсы с доступом к данным на уровне записей. Мой корпоративный гуру очень обеспокоен ростом числа таких уникальных подходов. В отличие от этого, SQL обеспечивает стандартную среду.

Мне хочется завершить эту заметку одним собственным комментарием: "Те, кто не способен понять уроки систем предыдущих поколений, обречены на повторение их ошибок". Другими словами, чтобы видеть дальше, стойте на плечах своих предшественников, а не вровень в ними (а это уже по мотивам высказывания сэра Исаака Ньютона (Sir Isaac Newton): "Если я видел дальше других, то потому, что стоял на плечах гигантов" – прим. переводчика).

Комментарии

Страницы комментариев: 1 :: 2 :: 3 :: ... :: 5 :: следующая

аноним, Чт 05 май 2011 16:18:34:
> А чем вам не нравятся РСУБД

Да меня то все устраивает, просто тут народ ниже заявляет что это старое омно надо давно выкинуть, вот я и спрашиваю, а какие альтернативы ?
аноним, Чт 05 май 2011 16:13:15:
> Какие могут быть альтернативы ?
Слюща дарагой ? Какой такой альтернатив ? Ручкы, тетрадкы и сто человикив - ни какой копьютер-шмопьютер ни нужин.
аноним, Чт 05 май 2011 16:11:11:
А чем вам не нравятся РСУБД. Альтернативу обычно ищут когда что-то не устраивает.
аноним, Чт 05 май 2011 15:56:52:
> Альтернативы зависят от того, какие данные вы собираетесь хранить и какие данные и в каком виде вам будут нужны и как часто.

Ну допустим я хочу хранить и работать с данными по например поликлинике. Талончики, пациенты, приемы, анализы, осмотры, и еще стопицот всякой всячины, + на это все нужна не кислая такая аналитика, частые отчеты, + работа в многопользовательской среде, транзакции. Какие могут быть альтернативы ?
аноним, Чт 05 май 2011 15:48:40:
> Конечно, если работаешь столяром-бетонщиком на стройке...

Ну чувак, настроение поправил, спасибо ;)
аноним, Чт 05 май 2011 15:45:48:
> не осилил? ;))

с чего ты взял, экстрасенс?

> если это OLTP, то нормализация даёт существенный прирост производительности и лучшее использование выч. мощностей.

БД должна быть нормализована, обязательно, и даже если это не OLTP.
аноним, Чт 05 май 2011 15:38:30:
>> нормализуете данные

если это OLTP, то нормализация даёт существенный прирост производительности и лучшее использование выч. мощностей.
аноним, Чт 05 май 2011 15:37:08:
>> опять же SQL изучать не придётся

не осилил? ;))

Уж куда проще то.
аноним, Чт 05 май 2011 15:36:10:
В столяры-бетонщики мне уже поздно. Да и я не думаю, что мне предложат на этой должности большее вознаграждение.
аноним, Чт 05 май 2011 14:49:44:
> А РБД хранят данные не в файлах ))))

Вот и возмите пример с РДБ и храните в файлах, проще, опять же SQL изучать не придётся.

> Конечно, если работаешь столяром-бетонщиком на стройке, то особого смысла не то что в пятой НФ не увидишь, но даже третья покажется ненужным нагромождением.

Ещё расскажите тогда, как вы, являясь разработчиком БД, каждый день нормализуете данные, в обзязательном порядке проходя через все 5 форм. Может уж лучше как я, в столяры-бетонщики.

Страницы комментариев: 1 :: 2 :: 3 :: ... :: 5 :: следующая

Ваш комментарий

Имя:

Текст комментария (HTML-теги не допускаются):

Новости мира IT:

Архив новостей

Последние комментарии:

Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...