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 :: ... :: 3 :: 4 :: 5 :: 6 :: следующая

аноним, Вт 03 мая 2011 09:28:21:
> SQL это примитивные плоские таблицы данных, ибо это РДБ.

Здесь как раз случай, что чем проще тем лучше. Это надёжнее и понятнее. РДБ предоставляет "хранилище". SQL предлагает простой логичный доступ к хранилищу. Если нужно что-то более интеллектуальное, пожалуйста, процедурный язык. Если хотите ООП, пожалуйста, реализуйте ООП, но не в хранилище. Многослойная структура обладает массой преимуществ.
Math, Вт 03 мая 2011 04:32:37:
SQL это примитивные плоские таблицы данных, ибо это РДБ.
ООП более гибче, но все еще не то и с БД как-то еще никак.
Разные парадигмы при взаимодействии РДБ и ООП при проектировании дают побочные эффекты для преодоления которых делают всякие мосты и мэппинги, которые ограничивают проектировщика.

В статье кстати нету и слова про ООП.
аноним, Вт 03 мая 2011 00:52:37:
Да ;) ООПщики свои грязные лапы и сюда тянут, да только вот обламываются постоянно. Никак им невдомек что работа с данными это не работа с объектами, тут производительность важнее, уровень не тот, и ООП их что слон в посудной лавке. А особенно их гложет PL/SQL, черт побери эффективный процедурный язык в связке с удобным декларативным, сразу результат, ООП же нервно курит в сторонке, непор-я-док ;)
аноним, Вт 03 мая 2011 00:31:01:
Ох мля эксперты итить вашу за ногу
Руслан, Пн 02 мая 2011 23:57:19:
Как можно сравнивать тумбочку с унитазом.
Разные языки разные задачи разные цели.
Я работаю на многих языках (sql, c#, java, delphi, asm, javascript) и не могу отрицать мощность SQL и его значимость, но нормальный ахитектор вам скажет что для проектирования баз данных используется именно ООП подход -- тоесть есть сущности есть у них свойства и есть у них обработчики -- то что присуще любому ООП языку. Дело в том что интерессные и мощьные вещи чаще всего появляются именно на стыке разных технологии. Поэтому только на голом SQL вам ну никак не построить сложную бизнеслогику ваших проектов -- для этого мы либо используем различные расширения SQL (Pl/SQL наиболее удачное из них) либо мы используем разширение языков различными фреймворками упрощающими работу с уровнем данных . У всех решений есть свои плюсы и минусы. а ООП называть дермом и сравнивать его с SQL просто нелепо это как гвоздь и молоток
аноним, Пн 02 мая 2011 23:14:58:
SQL может и не идеал, но такого дерьма как Java/C# и даром не надо. Реляционные системы это более высокий уровень абстракции чем ООП. Я писал на x86 ассемблере, правлю программки без исходников, несколько лет писал на Delphi и T-SQL. Ну так вот SQL мне нравится больше всего. Широко распространённые реализации конечно не очень, но потенциал огромен. И всё потому, что SQL описывает проблему, но не решение. Прогрессивные реляционные системы типа VoltDB автоматически распараллеливают запросы даже на несколько узлов кластера. А что нам предлагает нового ООП ? Я скажду даже больше, программист который не понимает как надо решать задачи на SQL это просто обезьяна за клавиатурой. Особенно если он ещё не понимает как работает железо под которое он пишет.
Roxseo, Вс 01 мая 2011 20:50:19:
Здесь даже не в стандарте делол. Это как всегда дело привычки. Почему большинство пользуют браузер ИЕ? Да потому что в опере или лисе им видите ли непривычно. Так и тут - проще взять коробочную версию того же оракла и все настроить на брошюре 'оралк для детей дошкольного возраста', чем курить многомеговые маны и конфиги нового ПО, как бы оно уникально и многообещающе ни было.
Рынок практически любого ПО ориентирован на юзера-полного бездаря
Math, Сб 30 апр 2011 11:30:03:
и без стандарта
Math, Сб 30 апр 2011 11:27:06:
>с нормальным ООП и нормальными библиотеками

Дело в том, что нормальный ООП понятие довольно расплывчатое и не без стандарта.
Поэтому помимо NoSQL, нас вскоре еще ждет NoOOP
аноним, Сб 30 апр 2011 03:52:00:
Кое в чём автор ошибается. SQL синтаксис имеет дополнительные расширения, уникальные для каждого производителя SQL-БД. И это далеко не секрет. Кроме того SQL слабо структурирован, и код на этом недоязыке практически не используется повторно. Именно эта проблема повлекла за собой создание разных ORM, дающих унифицированный доступ к различным объектам. храняшимся в БД. Программисту на Python,Java или любом другом языке хотелось бы работать с данными в БД, как с родными типами данных языка, например как с классами или словарями/хешами. Идеальный язык запросов - это нормальный язык программирования, с нормальным ООП и нормальными библиотеками, объектами и функциями. Бизнес логика должна быть на рормальном языке, а от SQL пахнет нафталином. И он медленный, та же Java/C# уделают его в разы по произодительности и удобству написания и использования хранимых процедур. Не зря в лучшей БД(от Oracle) используют хранимые процедуры на нормальном ЯП - Java, а не только на убогом SQL. А по скорости и массштабируемости та же BigTable уделывает любую SQL-based БД на не один порядок. Есть данные, которые надо хранить в реляционной субд, есть данные, которым самое место в NOSQL-БД, иногда нужен обычный XML, а бывает, что самое верное хранилише - раздел на винте, и сериализованные объекты. И не стоит рассуждать, что нужно, а от чего можно отказаться. Для разных целей разные хранилища данных, и ни как иначе. Автар представляет, какой ад начался бы в Google, если бы все данные из BigTаble срочно перенесли на SQL-решения?

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