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

Дискуссия по поводу "NoSQL" не имеет никакого отношения к SQL

Оригинал: Michael Stonebraker. The "NoSQL" Discussion has Nothing to Do With SQL. BLOG@CACM, November 4, 2009

Если SQL "no", то что же общее "yes" в сообществе NoSQL? От переводчика

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

А что в этой ситуации делать разработчикам новых систем, в которых SQL таки поддерживается? Ведь как-то глупо было бы отказываться от далеко не идеального, но привычного и полезного для людей языка только для того, чтобы примкнуть к движению NoSQL.

В частности, в сложное положение попала компания VoltDB, коммерциализирующая весьма оригинальную OLTP-ориентированную разработку H-Store. Это абсолютно нетрадиционная система, но SQL в ней поддерживается. Так что к направлению NoSQL ее отнести никак невозможно, хотя она не имеет ничего общего с традиционными SQL-ориентированными СУБД. И вот, в конце прошлого года Майкл Стоунбрейкер написал специальную заметку в блоке ACM, в которой пытается показать, что для удовлетворения новых требований рынка OLTP отказ от поддержки SQL не дает никакого выигрыша (как и отказ от поддержки ACID-транзакций).

Интересно, что заметка объективно является не вполне убедительной, о чем, в частности, говорят очень неприятные для Стоунбрейкера комментарии Джона Остераута (John Ousterhout), но при этом лично я полностью разделяю мнение Майкла о том, что в направлении NoSQL менее всего значим именно отказ от SQL. SQL – это нехороший язык, слишком сложный, путаный и т.д. Но другого общепринятого декларативного языка баз данных просто нет. Отказ от SQL отбросит технологию баз данных на несколько десятков лет назад, что, естественно, никому не нужно.

А с направлением NoSQL, как бы оно не называлось, нужно основательно разбираться, чтобы отделить, в конце концов, зерна от плевел.

В последнее время слышится много шума относительно баз данных "NoSQL". В 2009 г. этой теме были посвящены, по крайней мере, две конференции, по одной на каждом побережье. По-видимому, этот шум происходит от людей, являющихся сторонниками двух следующих направлений:

  1. системы, ориентированные на хранение документов, в которых запись базы данных представляет собой пару (ключ, значение) плюс некоторая полезная информация; к примерам систем этого класса относятся CouchDB и MongoDB, и для простоты мы будем называть такие системы хранилищами документов;
  2. системы, предназначенные для хранения пар (ключ, значение); обычно они реализуются на основе распределенных хэш-таблиц (distributed hash tables, DHT), и для простоты мы будем их называть хранилищами "ключ-значение"; примерами таких систем являются Memcachedb и Dynamo.
В обоих случаях при этом обычно используется низкоуровневый доступ к СУБД на уровне записей, а не SQL. Поэтому эти люди полагают себя сторонниками подхода "NoSQL".

Имеются две возможные причины перехода к любой подобной технологии СУБД: производительность и гибкость.

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

  1. разделить данные по нескольким узлам, что привело бы к серьезной головной боли при управлении распределенными данными в моем приложении,
  2. или отказаться от MySQL и заплатить большие деньги за лицензию для использования какой-либо корпоративной СУБД,
  3. или перейти к использованию чего-либо, отличного от SQL-ориентированной СУБД.

Доводы, относящиеся к гибкости, выглядят примерно так. Мои данные не соответствуют никакой жесткой реляционной схеме. Поэтому я не могу ограничиться структурой РСУБД и нуждаюсь в чем-либо более гибком.

В этой заметке анализируются доводы по поводу производительности; следующая заметка будет адресована гибкости.

Для простоты в этом обсуждении мы сосредоточимся на рабочих нагрузках, для которых базы данных NoSQL чаще всего считаются наиболее пригодными: рабочих нагрузках OLTP с многочисленными операциями обновления и простого поиска, а не рабочих нагрузках хранилищ данных со сложными запросами. Мы также не рассматриваем репозитории документов и другие специальные рабочие нагрузки, для которых могут хорошо подходить системы NoSQL.

Имеются два способа повышения производительности систем OLTP: автоматическое разделение данных в распределенной среде обработки без совместного использования ресурсов и повышение производительности каждого отдельного сервера.

В первом случае производительность повышается за счет обеспечения масштабируемости системы при добавлении узлов к компьютерной среде; во втором случае повышается производительность отдельных узлов. Любая серьезная SQL-ориентированная СУБД (например, Greenplum, Asterdata, Vertica, Paraccel и т.д.), разработанная в последние 10 лет, обеспечивает масштабируемость в среде без общих ресурсов, и любая попытка создания новой системы была бы недобросовестной, если бы в ней не обеспечивалась эта возможность. Так что это "необходимое условие" высокой производительности должно выполняться в любой СУБД. По моему мнению, никто не должен пользоваться СУБД, в которой не обеспечивается автоматическое разделение данные по узлам обработки.

Поэтому продолжу свою заметку размышлениями о другом компоненте производительности, а именно, производительности одного узла. Накладные расходы, связанные с поддержкой баз данных OLTP в традиционных SQL-ориентированных системах, имеют весьма небольшое отношение к SQL, и поэтому термин "NoSQL" является неправильным.

Основной накладной расход в SQL-ориентированных СУБД категории OLTP составляют коммуникации с СУБД на основе интерфейсов ODBC или JDBC. По-существу, во всех приложениях, чувствительных к производительности, используется интерфейс хранимых процедур, позволяющий выполнять логику приложения внутри СУБД и избегать вредоносных коммуникаций между приложением и СУБД. Другой альтернативой является выполнение СУБД в том же адресном пространстве, что и приложение, с отказом от каких-либо претензий на наличие контроля доступа или поддержки безопасности. Такие встраиваемые СУБД в некоторых средах являются вполне разумными, но только не для основного класса приложений OLTP, для которых очень существенна поддержка безопасности.

При использовании и хранимых процедур и встраивания стоимость полезной части работы составляет лишь небольшую долю общей стоимости транзакции (при том, что сегодняшие базы данных OLTP обычно помещаются в основной памяти). В недавней статье [1] подсчитано, что общее время обработки OLTP-транзакции почти поровну разделяется между следующими компонентами:

Журнализация (logging): В традиционных системах баз данных все записывается дважды – в базу данных и в журнал. Кроме того, журнал должен выталкиваться на диск, чтобы обеспечить гарантию соблюдения долговечности результатов транзакций (durability). Тем самым, журнализация – это дорогостоящая операция.

Блокировки (locking): Прежде чем притрагиваться к какой-либо записи, транзакция должна установить ее блокировку в таблице блокировок. Эта операция вызывает существенные накладные расходы.

Защелки (latching): В многопотоковой (multi-threaded) среде необходимо очень аккуратно выполнять модификации совместно используемых структур даных (B-деревьев, таблицы блокировок, таблиц описания ресурсов и т.д.). Обычно это делается с применением кратковременных синхронизационных защелок, которые являются еще одним источником накладных расходов.

Управление буферами (buffer management): данные в традиционных системах сохраняются на дисковых страницах фиксированного размера. Подсистема управления буферным пулом управляет кэшированием дисковых страниц в основной памяти. Кроме того, требуется размещать записи в страницах и устанавливать границы полей. И эти операции тоже вызывают значительные накладные расходы.

При устранении любого из этих источников накладных расходов скорость СУБД возрастает на 25%. Чтобы значительно ускорить систему, нужно освободиться ото всех четырех компонентов.

Хотя у систем NoSQL имеется множество разных особенностей, наличествуют и некоторые общие черты. Во-первых, многие из них управляют данными, распределенными по нескольким узлам и обеспечивают упомянутое выше "необходимое условие". Очевидно, что правильно разработанная система с несколькими узлами, независимо от того, базируется ли она на SQL или же на чем-то другом, лучше масштабируется, чем одноузловая система.

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

Что касается транзакций, то часто поддерживаются только транзакции над одной записью и система репликации с согласованностью в конечном счете на основе предположений о коммутативности транзакций. По сути "золотой стандарт" ACID-транзакций приносится в жертву производительности.

Однако итоговая одноузловая производительность многопотоковой системы NoSQL с хранением данных на дисках даже при отказе от поддержки ACID-транзакций не может значительно превышать производительность правильно построенной SQL-ориентированной OLTP-системы, поддерживающей механизм хранимых процедур. По существу, ACID-транзакции отвергаются только ради очень скромного повышения производительности, и это повышение производительности не имеет отношения к SQL.

Однако можно и рыбку съесть, и косточкой не подавиться (to have one’s cake and eat it too). Для достижения скорости нужно иметь интерфейс хранимых процедур к системе времени выполнения, которая компилирует конструкции высокоуровневого языка (например, SQL) в низкоуровневый код. Кроме того, нужно избавиться от всех четырех упомянутых выше источников накладных расходов.

Недавний проект [2] явным образом показал, что это возможно и продемонстрировал отличную производительность на тестовом наборе TPC-C. Подождем коммерческих реализаций этих и подобных им идей на основе подхода open source. Я полностью расчитываю на появление в ближайшем будущем высокоскоростных SQL-серверов с открытыми исходными текстами, которые будут обеспечивать автоматическое разделение данных. Кроме того, они будут продолжать поддерживать ACID-транзакции, а также обеспечивать более высокую продуктивность программистов, уменьшение расходов на сопровождение и улучшенную независимость данных, свойственную SQL. Так что для достижения высокой производительности не требуется отказываться ни от SQL, ни от ACID-транзакций.

В заключение еще раз отмечу, что для достижения высокой производительности требуется избавляться от накладных расходов. Эти накладные расходы не имеют ничего общего с SQL, а связаны с традиционными реализациями ACID-транзакций, многопотоковой обработки и управления дисками. Для значительного ускорения системы необходимо удалить все четыре источника накдадных расходов, которые обсуждались выше. Это можно сделать как в контексте SQL, так и каком-либо другом контексте.

Литература

[1] S. Harizopoulos, et. al. Through the Looking Glass, and What We Found There. Proc. 2008 SIGMOD Conference, Vancouver, B.C., June 2008.
Имеется перевод на русский язык: Ставрос Харизопулос, Дэниэль Абади, Сэмюэль Мэдден, Майкл Стоунбрейкер. OLTP в Зазеркалье

[2] M. Stonebraker, et. al. The End of an Architectural Era (It’s Time for a Complete Rewrite). Proc 2007 VLDB Conference, Vienna, Austria, Sept. 2007.
Имеется перевод на русский язык: Майкл Стоунбрейкер, Сэмюэль Мэдден, Дэниэль Абади, Ставрос Харизопулос, Набил Хачем, Пат Хеллэнд. Конец архитектурной эпохи, или Наступило время полностью переписывать системы управления данными

Для информации: Майкл Стоунбрейкер не только является адъюнкт-профессором Массачусетского технологического института, но также связан с четырьмя компаниями-стартапами, производящими или использующими технологию баз данных.


Комментарии читателей BLOG@CACM

Йоханнес Эрнст (Johannes Ernst), 4 ноября 2009 г.
Мне кажется, что в своем обсуждении Вы упустили несколько других подкатегорий движения NoSQL. Например, BigTable компании Google и клоны этой системы, а также графовые базы данных. Если бы Вы добавили их к своему анализу, изменилась ли бы Ваша точка зрения?
Дуайт Мерримен (Dwight Merriman), 5 ноября 2009 г.
Майкл,

Мне кажется, что денормализация, которая происходит при типичном использовании документо-ориентированных баз данных, способствует повышению производительности: сложный документ с какими-либо вложенными объектами и/или массивами в реляционной СУБД мог бы храниться в виде 10 строк, а не одного непрерывного компонента данных. Вы согласны с этим?

Майкл Стоунбрейкер, 5 ноября 2009 г.
В ответ на комментарий Дуайта Мерримена.

В своей заметке я осторожно заметил, что базы данных NoSQL могли бы быть полезны для репозиториев документов. Для этого имеется несколько оснований: денормализация (Ваш комментарий), выборка по ключевым словам и семантическая разметка.

Майкл Стоунбрейкер, 5 ноября 2009 г.
В ответ на комментарий Йоханнеса Эрнста.

Я большой любитель тезиса "один размер непригоден для всех". Имеется несколько реализаций SQL-серверов с очень разными характеристиками производительности, а также множество других серверов. Наряду с теми, которые Вы упоминали, имеются хранилища массивов (такие как Rasdaman) и хранилища RDF (такие как Freebase). Я приветствую усилия по разработке СУБД, ориентированных на удовлетворение конкретных потребностей рынка.

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

Джон Остераут (John Ousterhout), 15 апреля 2010 г.
Вы утверждаете, что масштабируемая производительность обеспечивается "любой серьезной СУБД, разработанной в последние 15 лет", что означает, что можно просто добавить к системе большее число серверов, чтобы можно было масштабировать как общий размер набора данных, так и скорость обработки транзакций в стиле OLTP (т.е. большого числа мелких транзакций, а не нескольких тразакций увеличивающейся длительности).

Однако я не смог найти какой-либо пример крупномасштабного Web-приложения, потребности которого можно было бы удовлетворить с использованием системы, основанной на одной РСУБД. С другой стороны, имеются многочисленные примеры сайтов, разработчики которых утверждают, что исчерпали возможности масштабирования и перешли к разделению своих данных между несколькими независимыми экземплярами СУБД или созданию систем NoSQL (например, Amazon, Facebook, Google, Yahoo и Ebay). Могли бы вы указать на какие-либо истории успеха, которые опровергали бы распространенное убеждение о невозможности масштабирования систем РСУБД?

Майкл Стоунбрейкер, 5 ноября 2009 г.
Мое замечание относилось конкретно к рынку хранилищ данных, на котором Greenplum, Asterdata, Paraccel и Vertica обеспечивают линейную масштабируемость. Кроме того, более старые системы Teradata, Netezza и DB2 также являются линейно масштабируемыми. Microsoft в этом году дебютирует с интеграцией DataAllegro с SQLServer. Говорят, что они тоже обеспечат линейную масшабируемость. См. статью Энди Павло и др. на конференции SIGMOD 2009; в этой статье приводятся некоторые показатели производительности СУБД Vertica в сравнении с одной из ведущих традиционных СУБД.

Однако Вы спрашиваете про рынок OLTP, а не хранилищ данных. Здесь имеются два соображения: разделяемость (shardability) данных и частота коллизий. Приложение является разделяемым, если можно таким образом разделить данные, что БОЛЬШИНСТВО транзакций выполняется локально в одном узле. Частота коллизий показывает, наколько часто параллельные транзакции будут затрагивать один и тот же элемент данных. Вырожденным случаем является база данных из одной записи, в которых мы будем иметь стопроцентную частоту коллизий.

Если данные являются разделяемыми, и частота коллизий – низкая, то DB2 должна масштабироваться линейно. Аналогично, будут линейно масштабироваться многочисленные системы, построенные на основе MySQL и PosgreSQL, например, EnterpriseDB. Если данные являются разделяемыми, то независимо от частоты коллизий линейную масштабируемость будет демонстрировать VoltDB (сейчас она в состоянии бета-тестирования; производственный выпуск ожидается в мае 2010 г.).

Если данные разделяемыми не являются, то любая система замедлится из-за потребности в поддержке распределенных транзакций. В некоторых системах распределенные транзакции не поддерживаются, что всего лишь выталкивает проблему на уровень приложения, ее решение тоже нанесет ущерб производительности. Большая часть известных мне людей решает эту проблему, пытаясь найти способ переделки своего приложения в разделяемую форму. Компания EBay (которую Вы упоминали в своем комментарии) представляет собой хороший пример предприятия, прибегшего к такому подходу.

Джон Остераут, 29 апреля 2010 г.
Спасибо за ответ; у меня имеется еще пара комментариев.
  • Я нахожусь в недоумении: Вы говорите, что Ваше замечание относится к рынку хранилищ данных, но, по моему пониманию, вся Ваша заметка посвящалась OLTP. Вот цитата: "мы сосредоточимся на рабочих нагрузках, для которых базы данных NoSQL чаще всего считаются наиболее пригодными: рабочих нагрузках OLTP с многочисленными операциями обновления и простого поиска, а не рабочих нагрузках хранилищ данных со сложными запросами". Уместны ли в контексте OLTP ссылки на Greenplum, Aster Data и т.д.?
  • В Вашем ответе содержатся общие доводы относительно того, как можно было бы достичь масштабируемости СУБД для OLTP, и эти доводы правдоподобны, но мне-то хотелось услышать какую-нибудь историю успеха (не от вендоров, а от кого-нибудь, кто действительно добился высокого уровня масштабируемости своего приложения при использовании одной РСУБД, распространенной на несколько узлов). Если РСУБД могут масштабироваться (при любых разумных условиях), то, конечно, должны иметься примеры их успешного использования, и я думаю, что Вы из тех людей, которые должны были бы об этом слышать. Есть ли такие примеры, которые заслуживают внимания? При отсутствии убедительных историй успеха многие люди предпочтут поверить скептикам, которые утверждают, что РСУБД не могут масштабироваться для OLTP, подтверждая это многочисленными примерами компаний, которые не смогли масштабировать свои системы РСУБД и перешли на использование NoSQL.

Кстати, я не думаю, что eBay представляет желаемую мной историю успеха: они разделили свои данные с целью использования нескольких независимых, не масштабируемых РСУБД, а не использовали единую масштабируемую РСУБД, не так ли?

Джон Расин (John Racine), 28 июня 2010 г.

Основная проблема, которую я вижу в связи с SQL, заключается в том, что SQL-ориентированная СУБД – это обычно система пакетной передачи данных от сервера к клиенту. Для обеспечения целостности данных требуется блокировка многих записей, а также велика вероятность блокировки записей, не изменяемых в соответствующий момент времени. Я полагаю, что так происходит потому, что в противном случае нарушилось бы свойство атомарности (atomicy). Для противодействия этому многие базы данных SQL программируются без блокировок на изменение данных, что, на первый взгляд, кажется допустимым, потому что мала вероятность доступа других пользователей к той же информации в то же время. Однако действительность состоит в том, что многие записи обновляются многократно. В результате нарушается свойство долговечности хранения (durability), поскольку обновления данных, сделанные одним человеком, могут быть аннулированы другими. По крайней мере, это может приводить к появлению бездетных родительских или сиротских дочерних записей. Разделение записей на головные и детальные приводит к еще большему нарушению атомарности, поскольку такие записи, как заказ на покупку, составляющие единое целое, разбиваются на много частей, распределяются по дисковому устройству, а потом их прходится заново собирать, чтобы снова получить тот же самый заказ на покупку. Ассоциативные массивы позволяют сохранять данные о заказе на покупку в одной записи, хотя и с реляционными ссылками на информацию о заказчике, содержащую имя заказчика, адрес и т.д.

Кажущиеся не менее сложными, чем ассоциативные массивы, содинения нескольких таблиц могут быть далее более сложными, а их результаты – еще более трудно интерпретируемыми, поскольку связи между данными не являются прозрачными. В реляционных базах данных NoSQL допускаются реляционные ссылки, но можно проектировать реальные базы данных без потребности в разделении данных или хранения данных в ассоциативных массивах. Это обеспечивает свободу проектирования и более высокий уровень целостности данных из-за возможности блокирования только тех записей, которые действительно требуются. Это способствует использованию блокировочных стратегий, поскольку такие стратегии становятся практичными.

Замечу, что я имею в вижу ту разновидность NoSQL, к которой относится Pick. Также замечу, что у большинства систем категории Rick сегодня имеется SQL-интерфейс для формулировки запросов. Однако большинство пользователей предпочитает при наличии возможности пользоваться интерфейсом TCL. Еще одна важная вещь состоит в том, что некоторые из этих новых NoSQL-систем поддерживают хэш-таблицы. В Pick/Multivalue они имелись всегда, и они обладают громадным преимуществом перед индексированием. В большинстве систем Pick теперь имеется индексация, но этот метод доступа не является основным и, вероятно, используется в 100 или 1000 раз реже, чем в обычных SQL-системах. Если принимать во внимание известную подверженность ошибкам файловых индексов, это является громадным преимуществом. Кроме того, это повышает уровень атомарности, поскольку индексы не обязаны изменяться при изменении записей, по крайней мере, не обязаны изменяться так часто, как в SQL-системах.

Я не вижу существенной разницы между SQL и NoSQL по отношению, например, к согласованности и изолированности. Я не очень понимаю, что означают эти понятия в данном контексте. В реляционной NoSQL-системе, которой является Pick, но не являются все NoSQL-системы, так же, как и в SQL-системах данные можно разделить и обращаться к ним в связи с другими таблицами/файлами. Основное отличие состоит в том, что в SQL можно работать только в таком стиле, а в Pick/MultiValue – этого ограничения нет.

Я считаю, что ассоциативные массивы являются более практичной моделью данных, чем организация данных в стиле "головные/детальные" записи. Многозначности (multivalue) гораздо более распространены, чем полагают пользователи SQL, и в некоторых приложениях многозначности и ассоциации являются нормой, а не исключением.

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

SQL опередил MultiValue на рынке во многом из-за преимуществ пользовательского интерфейса, которым обычно обладают SQL-системы. Это привело к возрастанию инвестиций, узнаваемости и конкурентоспособности SQL. Преимущества пользовательского интерфейса теперь не являются существенными, но SQL-системы сохраняют лидерство на рынке, в основном, благодаря своей узнаваемости, что принуждает производителей многозначных систем к тяжелой конкурентной борьбе. Хотя для многозначных систем написано намного больше приложений, чем для любых других СУБД (некоторые из них существуют с 1960-х гг. и до сих пор используются), в большинстве этих систем поддерживаются старомодные пользовательские интерфейсы, и переделка этих интерфейсов стоит настолько дорого, что многие из этих систем потихоньку забрасываются. Те же системы, разработчики которых смогли справиться с новыми пользовавтельскими интерфейсами, например, AccuTerm и моя система BB4GL привлекают внимание всех, кто с ними сталкивается. Я просто не могу позволить себе представить свой продукт на рынке так, как мне хотелось бы. Несколько раз я выпускал пресс-релизы, которые сразу привлекали внимание к нашим продуктам. Если бы тепершний рынок поддерживал новые компании, у меня были бы заказчики, заказчики, которые настолько заняты, пытаясь спасти свои головы от нынешнего экономического урагана, что просто не могут обращать внимание на новые компании. Ко мне часто обращаются с запросами люди со всего мира, случайно попадаюшие на мой редко посещаемый Web-сайт, который я не могу себе позволить рекламировать в Web-каталогах. Но наши продукты привлекают внимание даже и через этот редко посещаемый сайт.

Я прочитаю статью Стоубрейкера позже сегодня вечером. Я хотел всего лишь донести до вас точку зрения человека, который работает как с SQL-, так и "NoSQL"-системами на протяжении многих, многих лет. С моей точки зрения, "NoSQL" означает "Not-Only-SQL", а вовсе не "No SQL". У нас в Pick имеются конструкции SQL, позволяющие осуществлять доступ к данным ассоциативных массивов и управлять ими, так что здесь не обязательно требуется выбирать "SQL" или "No SQL".

Журнализация: в SQL-системах должно производиться больше, чем в Pick-системах, действий по журнализации изменений, поскольку записи в большей степени разделены на головные и детальные, чем при использовании комбинированных записей, хранящихся в ассоциативных массивах, и приходится журналировать больше изменений записей и страниц данных.

Блокировки: как я уже упоминал, при разделении головных и детальных записей приходится блокировать больше записей, в особенности, в тех случаях, когда детальные записи распределены по нескольким дисковым страницам.

Защелки: опять же, поскольку в SQL поддерживается больше отдельных записей, для управления этими записями требуется больше защелок.

Управление буферами: для извлечения того же объема данных из фактически того же набора записей требуется прочитать больше данных с дискового устройства (для моего примера с простым заказом на покупку для получения информации о заказе с 20 позициями потребуются один или два доступа к диску, в то время как в среде SQL для этого придется выполнить, по меньшей мере, 21 обмен с диском).

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

Джон Расин (John Racine), 1 июля 2010 г.
Кроме того, атомарность с точки зрения SQL состоит в разбиении атома на электроны, нейроны и протоны, что изменяет сущность атома. Если использовать мой пример с заказами, то в ассоциативном массиве многозначной системы атом заказа на покупку сохраняется как единое целое. В SQL-системе эти данные были бы разбиты не на атомы, а на электроны и т.д., что изменило бы их суть. Заказ на покупку несет много информации, когда он представлен целиком, в позициях заказа остается мало информации, если они оторваны от заголовка и других позиций заказа (и их итога). Такие детальные записи редко обладают смыслом по отношению к любой другой части данных в системе, если они не связаны с головной записью, и в многозначных системах имеются способы простого извлечения этих детальных данных в подобных редких случаях.
Джон Расин (John Racine), 1 июля 2010 г.
P.S. Для тех, кто не знаком с Pick/MultiValue. Эта категория систем является сегодня одной из наиболее распространенных в мире. Системы продавались и продаются под различными названиями, включая Sequoia (пионер отказоустойчивых систем)1), D3, mvBase, mvEnterprise2), AP3), General Automation4), Mentor , Ultimate, Revelation, OpenInsight, Reality, Microdata (McDonnell Douglas), Applied Digital Data Systems (кроме того, популярный производитель терминалов), NCR, IBM U2 (UniVerse & UniData), Rocket Software, Intersystems Cache, NorthGate, jBase, OpenQM, Maverick, ONWare, Prime Information Systems и UniVision5). В половине университетов и колледжей США используется приложение Datatel, являющееся многозначной системой и поддерживающее административную и академическую деятельность, составление расписаний, управление платежами и т.д. На Pick базируются системы основных банков США. Для управления операциями в крупнейшей американской компании-поставщике производственного оборудования Hughes Supply также используется Pick.


Примечания переводчика.

1) СУБД Sequoia и сама компания Sequoia Enterprise Systems не существуют с 1996 г., когда Sequoia была поглощена компанией General Automation, которая, в свою очередь была поглощена компанией Precision Partners, до этого успев произвести на основе Sequoia СУБД mvEnterprise. В 2000 г. эта система была продана компании Raining Data, позже переименованной в TigerLogic.

2) Три последние системы в настоящее время принадлежат TigerLogic.

3) Насколько я понимаю, AP раскрывается как Advanced Pick, и это название версии Pick System, включавшей не только СУБД, но и операционную систему.

4) Это название компании, а не СУБД, см. первую сноску.

5) Похоже, что наиболее надежным материалом по истории систем семейства Pick является статья в Википедии Pick operating system.

Комментарии

Сергей Кузнецов, Сб 28 авг 2010 15:36:02:
В середине лета появились новые комментарии к этой заметке Стоунбрейкера. Их написал Джон Расин (John Racine), являющийся президентом и техническим лидером компании Racine Enterprises Inc., основной продукт которой базируется на системе категории Pick. С моей точки зрения, во-первых, Pick, безусловно, исторически является одним из первых представителей категории NoSQL, и, во-вторых, люди, связанные с Pick, в последнее время так редко публично выступают, что любое новое известие от них заслуживает публикации. Поэтому я перевел комментарии Расина (хотя местами они написаны очень путанным образом) и включил их в данный материал. Кстати, прошу обратить внимание на то, что сообщество Pick приняло в свои ряды компанию Intersystems с ее основным продуктом Cache. Лично я как-то упустил тот факт, что еще пять лет назад Intersystems реализовала Pick'о-подобный интерфейс к базам данных Cache и теперь конкурирует и с основными производителями околопиковых систем (в том числе, с IBM U2 - Universe и Unidata).

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

Имя:

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

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

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

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

Как стать программистом? (22)
Вторник 26.07, 21:56
Вышел web-браузер Chrome 52 (1)
Суббота 23.07, 18:51
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
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...