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

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

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

Ваш сайт в 8 раз быстрее конкурентов. Хостинг от $2.95

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

Все необходимое для вашего сайта и лучшая техподдержка 24/7

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

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

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

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

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

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

аноним, Ср 04 мая 2011 17:38:34:
А может просто вы не умеете ей пользоваться ? Чем же она вам не угодила в случае сложных данных ?
architect, Ср 04 мая 2011 17:33:08:
РДБ это примитив, и удобна она только для больших и простых данных.
аноним, Ср 04 мая 2011 17:03:06:
Еще раз, в РБД нет таблиц, там есть только связи, которые могут быть организованы произвольным образом, как правило наиболее удобно их организовывать в таблицы. Таблицы в свою очередь могут быть не плоскими за счет вложенности, и наследования. Размазыванием занимается архитектор, это не свойство реляционки, она лишь обеспечивает при необходимости такую возможность, это гибко.
architect, Ср 04 мая 2011 16:41:02:
От того что "РДБ как раз постулирует равнозначность записей" это никак не помогает делать осмысленные запросы, когда сущность "размазана" по плоским таблицам.
аноним, Ср 04 мая 2011 16:13:35:
Все сильно зависит от того используется база исключительно как хранилище, или как система обработки данных, т.е. одно дело когда мы хотим только хранить "информационные объекты", без какой либо особой их обработки, и совсем другое когда нам нужна сложная обработка, в первом случае все сводится к элементарному SQL или вообще отказу от него, во втором же и сложного SQL зачастую недостаточно, приходится прибегать к процедурным расширениям.

Т.е. для простых хранилищ полноценная SQL база может быть просто избыточной, тем более что за счет отказа от ненужного функционала можно выиграть в производительности. С другой стороны отказ от предоставляемого функционала если он нужен, и его реализация вне, выглядит несколько странным, и в этом случае опять таки можно потерять, в производительности. Отдельно надо рассматривать специфические варианты, когда база хоть и используется как обработчик, но SQL не эффективен в силу характера данных или алгоритмов их обработки.

Короче разработчик должен решать, смотреть на свою задачу, анализировать и решать, какой вариант подойдет лучше. А спорить о том какой из них лучше а какой хуже в принципе, смысла не имеет, можно говорить разве что о распространенности тех или иных классов задач, специалистов, документации, паттернов, простоте и т.п, но выводы тут будут в любом случае не общие а относительные.
аноним, Ср 04 мая 2011 15:16:55:
>> побочные эффекты для преодоления которых делают всякие мосты и мэппинги, которые ограничивают проектировщика.

Проблемы "маппинга" это не проблемы логики, а проблемы частной реализации. ОРМ - результат ограниченности реализующей системы. БД, вообще, синоним надёжного межсессионного хранилища, т.е. есть надёжное хранилище (которое дорогое и затратное) и не слишком надёжное (объекты в оперативной памяти), но оперативное и относительно дешёвое. Так вот, сейчас для множества прикладных задач оперативное хранилище является достаточным. Более того, подробная формализация данных сейчас не оправдывает себя, она оказывается попросту не востребованной, проще вывалить некоторую кучку плохо структурированных, но "быстрых" данных и пусть он сам в них копается и отбирает, что ему нужно. Этот подход раньше был не приемлем, но сейчас количество задач, для которых такое подход приемлем, становится всё больше и больше.
аноним, Ср 04 мая 2011 15:05:51:
>> это примитивные плоские таблицы данных, ибо это РДБ

))) рдб как раз не таблица в принципе. Таблица суть упорядоченные тем или иным способом записи. РДБ как раз постулирует равнозначность записей.
Math, Ср 04 мая 2011 14:48:39:
>Интересно, что за эффекты ?

Почему Google не использует РДБ для хранилища данных?
аноним, Вт 03 мая 2011 13:27:39:
> пожалуйста, реализуйте ООП, но не в хранилище.

Все есть объект поэтому можно и в хранилище, иначе неконцепт.
аноним, Вт 03 мая 2011 09:46:46:
> Разные парадигмы при взаимодействии РДБ и ООП при проектировании дают побочные эффекты ... которые ограничивают проектировщика

Интересно, что за эффекты ? В cопряжении с обычным структурным подходом проблем нет, ООП не пользую, в чем там проблема ? производительность ?

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

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

Имя:

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

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

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

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

VDS хостинг Облачный сервер в Нидерландах и Украине

Аренда виртуального сервера от $7.91

Партнёрская программа
$20 за клиента

Wildcard сертификаты от $74,97 в год.

Дешевые ssl сертификаты для домена

Sectigo сертификаты от $7,67 в год.

хостинг Украина Виртуальный хостинг для сайта от $4,87

Регистрация домена от $2 в год

Партнерская программа – $20 за клиента

VPS с гибкой конфигурацией: за 1€

Мощные выделенные сервера: от 25€

Собственный Дата-Центр
Поддержка 24/7

Бесплатный конструктор сайтов и Landing Page

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

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

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

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

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

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

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — 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
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...