Logo Host-telecom.com — профессиональный хостинг в Европе! Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

ATLEX Выделенные серверы: в Европе / в России.

Виртуальные серверы: в Европе / в России.

Партнерская программа

Хостинг + Certum Commercial SSL и домен в подарок

VPS: SSD, KVM, бесплатные бэкапы и администрирование 24/7

Бесплатный перенос сайта + подарки к новоселью

хостинг сайтов ГиперХост — хостинг сайтов который Вы искали.

Виртуальный хостинг, Аренда VPS серверов, рация доменных имен, SSL сертификаты

Почему предприятия не заинтересованы в 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 :: 4 :: 5 :: 6 :: следующая

аноним, Чт 05 мая 2011 10:51:06:
>> Какая разница как реализовано в виде кучи или там бинарного дерева

разница принципиальная
аноним, Чт 05 мая 2011 10:49:36:
>> в теории РДБ

Что за теория такая? ))) В РБД нет таблиц вообще, ни в каком виде. Школота, иди учись.
Анон, Чт 05 мая 2011 10:31:21:
Какая разница как реализовано в виде кучи или там бинарного дерева, в теории РДБ нормальные формы все данные все равно сводят к плоским таблицам.
аноним, Чт 05 мая 2011 10:13:08:
А так, самый распространённый способ хранения строк это куча с произвольным доступом, которую уж никак таблицей не назовёшь.
аноним, Чт 05 мая 2011 10:11:27:
Анон, таблица это упорядоченный список строк, тем или иным способом. Упорядоченный способ хранения данных строк, по большей части, сейчас используется только в убогом MS SQL с его кластерными "таблицами".
аноним, Чт 05 мая 2011 09:36:43:
Даже в теории РДБ это примитивные плоские таблицы данных и все эти 5 нормальных форм такая большая чушь которую уже пора выкидывать на свалку истории.
аноним, Ср 04 мая 2011 18:27:42:
> В какие ещё таблицы вы собрались организовывать данные в рамках РБД? Отдалённо похожее это только курсор, с оговорками. Картеж это не таблица, а "куча" равнозначных свойств.

Следует различать реляционную модель и РСУБД, т.е. вопрос лишь в том к чему мы относим аббревиатуру "РБД" ;) В модели таблиц конечно нет, но в РСУБД они как правило есть. Кортеж в модели это конечно не таблица, и курсоров в ней нет также как и таблиц. Таблицы в модели можно представить разве что как как отдельные множества отношений атрибутов.
аноним, Ср 04 мая 2011 17:58:22:
> нету в РБД таблиц

Не, ну как опциональные контейнеры, удобные и широко используемые на практике они конечно есть, но вот другое дело что к реляционной модели они имеют весьма боковое отношение. Как крайние случаи для демонстрации можно представить всю БД в одной таблице, это вполне возможно, или наоборот, БД где все поля разнесены по отдельным таблицам, в этом случае по сути таблиц уже нет, это уже не таблицы а списки.
аноним, Ср 04 мая 2011 17:53:40:
>> как правило наиболее удобно их организовывать в таблицы

В какие ещё таблицы вы собрались организовывать данные в рамках РБД? Что-то отдалённое похожее на таблицу в РБД это только курсор и то с оговорками. Картеж это не таблица, а "куча" равнозначных и равновероятных реализаций свойств.
аноним, Ср 04 мая 2011 17:50:22:
architect, нету в РБД таблиц. Нету. Ни плоских, ни неплоских. Никаких нету.

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

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

Имя:

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

💰 Самые низкие цены на домены

🔒 Отличный хостинг на SSD c бесплатными SSL

💻 Огромнейший выбор dedicated выделенных серверов

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

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

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

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

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-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...