Logo Спонсор сайта — Хостинг Fornex.com Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Сверхбыстрый хостинг от 69 р./мес., VPS от 299 р./мес.

Бесплатно: администрирование + ISPmanager + DDoS защита + SSL + 7 дней тестовый период

Скидка 50% на первый месяц VPS и хостинга по промокоду CITFORUM

VPS/VDS за 1 евро!

vCore x1, 1 GB RAM ECC, 15 GB SSD (RAID 10), Port 1 Gbps, Трафик ∞, Виртуализатор KVM.

Выбор стран: Нидерланды, Молдова и Россия!

Тарифы от 59 руб в месяц за 512MB RAM и 5Gb NVMe SSD!

Hi-CPU тарифы с повышенной частотой процессора 3.8 – 4.2 GHz, автоматическая установка Windows

Дата-центры на выбор, защита от DDoS-атак

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

Виртуальный хостинг, Аренда 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 :: ... :: 6 :: следующая

не фанат SQL, Пт 18 янв 2019 22:35:52:
>> А чем вам не нравятся РСУБД
> Да меня то все устраивает, просто тут народ ниже заявляет что это старое омно надо давно выкинуть, вот я и спрашиваю, а какие альтернативы ?

Все эти СУБД "из каробки" уродует людей IMHO,
и как раз обезъянами(см.ниже пост SQLщика зазнавшегося хама высокомерно считающего что, SQL - предел интелелктуала, по себе всех судит...) - обезъянами которые могут даже ударить дубинкой если научить этому и даже выстрелить из автомата(был и такой ролик) - но, НИКОГДА ниасилят сделать этот автомат или пусть ладно всеголишь дубинку... да, даже просто изобрести. Этим и отличаются люди вообще то, хоть как показал не все люди - значит люди...

Предвидя вопрос почему же я не знаю SQL
- а, потому что я собсвенно програмист - мне он не нужен! Зачем мне этот скриптовый универсально-залаговый "костыль"?! Я уж не говорю: про все тонкости этого костыля мне знать? В статье цитата про стандарт SQL - это ложь говорящего, ибо нет никакого стандарта: сколько их производителей - столько и SQL стандартов... прям как с Java и JS, ну и теми же "NoSQL". Засирать мозг этими чьими то SQL-продукта плюс неизбежно и их багами и фичами/обходами - вместо собственно программирования? Не смешите! Я не для того в программирование подался, да и без SQL подобного "стандарта" прогарммистам хватает от HW, ОС и [сторонних] библиотек в них, до компиляторов и их библиотек.

А, отвечая: самая лучшая и притом самая надёжная альтернатива, особенно желающему не доверять SQL-"изкоробочному" неизвестному дяде "на слово" (о качественности и вообще стабильности) - делать всё самим. Т.е.вникаем как там AVL, как там BTree и тд работает и собственно программируем...
С моей точки зрения: знание SQL хоть до последнего ньюанса - без знания перечисленного, а к нему и использования(иначе это будет поверхностное "знание" - ибо ньюансов и оптимизаций там тоже "миллион") то, это у таких - как раз никак не программирование!
А, всеголишь скриптование,
т.е.использование *чужога ума* для создания - и пример выше про обезъян тут упоказателен.

И дело тут не только в чужом уме, а и в том что человек незнает как оно там работает: это - Чёрный Ящик... и в добавок оптимизация на нём - это реально: скрытые маркетинговые интересы и сговоры изкоробочного дяди - по занижению производительность базы данных.

Что хуже, привыкнув к нему часто фанаты SQL впихивают его везде где приемлемо и где нет, даже там где нужна оптимизаций при маой реляционности данных, отмахиваюясь тем что он быстрей чем аж ...XML - но, тот же вообще то не предназначенн для БД!... (Хоть можно и его сделать быстрым - рассчитанным на небольшие БД, но вероятно никому не надо - ибо это же надо думать/изобретать-алгоритмы... проще воспользоваться готовым SQL). А, то что только два перечисленных выше мной издавно известных алгоритма дают многократное ускорение относительно SQL и даже NoSQL о этом в т.сл. умалчивается, и в итоге - вынуждая мучиться пользователей лаго-продукции когда число записей превышает тестовое у разработчика оыбчно чуть более нулевое в т.сл.

А, ещё вопрос ответственности: любой программист должен знать что и как происходит в его продукте, и тем более когда речь от любых БД,
- но, НИКТО (не считая самих авторов [No]SQL БД) даже не имеет понятия что там происходит и почему [[может быть]нетак]... И тем более что там за дыры безопасности, в стиле винды: открыл ".doc" - получи вирус на ПК, а для опасливых зловредов - и в ".txt"... Что мешает: открыв принесённый %.БД% на Атомную станцию - её не то что заглючить, а хоть взорвать? - привет Чернобыль/Фукусима? И что - кто виноват? А, понятно - само взорвалось? Или в больнице: сам пациент скончался от [скрытого]передоза и т.д...
Ну да знаем - как обычно если замять не удастся... - назначат самых безответных: виноваты будут типично в профнепригодности работник(и) АЭС / медработник(и)...
А, реально то вина - на программисте лентяе и компания/его руководство такого принявшего на работу или даже сами именно такого выбиравшего! А то и организации сертификаторе.

Итого:
SQL это для самых ленивых,
- собственно программировать...
И безответсвенных.

И даже сказать что, для "обезъян" - тут реально: оскорбить обезъян...
(Ибо умение собственно программировать, оптимизировать так чтобы пользователя(ей) не раздражало хотя бы на N-ядерных ПК! и тем более обеспечивать безопасность продукта и управляемого оборудования - не задача обезъян!)
аноним, Чт 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:
В столяры-бетонщики мне уже поздно. Да и я не думаю, что мне предложат на этой должности большее вознаграждение.

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

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

Имя:

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

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

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

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

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