6. Некоторые комментарии по поводу мира, в котором один размер не является пригодным для всех

Если признать результаты этой статьи убедительными, то мы движемся по направлению к миру с не менее чем пятью специализированными программными средствами, миру, в котором не остается места для унаследованных «безразмерных» систем. В этом разделе рассматриваются некоторые последствия таких архитектурных изменений.

6.1 Реляционная модель не обязательно является решением

Пережив продолжительные дебаты 1974 года [Rus74] и дискуссии между защитниками Codasyl и реляционной модели данных, авторы не желают более «кормить эту священную корову». Однако они считают уместным обсудить модель данных (или модели данных), на которой они основывают свои системы. В 1970-е гг. в мире СУБД имелись только приложения обработки бизнес-данных, и идея Теда Кодда о нормализации данных в плоские таблицы хорошо послужила сообществу баз данных в течение 30 лет. Однако теперь имеются новые области приложений, которые необходимо принимать во внимание: хранилища данных, Web-ориентированный поиск, аналитика в реальном времени и полуструктурированные данные. Авторы предлагают следующие наблюдения.

1. В области хранилищ данных почти сто процентов схем относятся к категориям «звезда» или «снежинка», содержащим центральную таблицу фактов с соединениями 1-к-n с окружающими ее таблицами измерений, которые, в свою очередь, могут участвовать в соединениях 1-к-n с таблицами измерений второго уровня и т.д. Хотя схемы «звезда» и «снежинка» легко моделируются с использованием реляционных схем, на самом деле, в этой среде проще и естественнее использовать модель «сущности-связи». Более того, в E/R-модели проще формулируются запросы к хранилищам данных. Наконец, операции над хранилищами данных в реляционной реализации являются существенно более дорогостоящими. Например, операцию, эквивалентную операции изменения ключа строки в таблице измерений, можно гораздо быстрее выполнить в реализации на основе E/R-модели.
2. В области обработки потоковых данных имеются следующие потребности:
   1. обработка потоков сообщений, поступающих с высокой скоростью;
   2. установление соотношений таких потоковых данных с хранимыми данными.

   Для решения обеих задач принято использовать язык StreamSQL, обобщение SQL, позволяющее одновременно указывать в разделе FROM SQL-запроса хранимые таблицы и потоки. Этот язык появился в результате пионерской работы [ABW06], выполненной в Стэндфордском университете, и в настоящее время активно обсуждается его стандартизация. Конечно, в StreamSQL поддерживаются реляционные схемы как для таблиц, так и для потоков.

   Однако в коммерческих каналах, таких как Reuters, Infodyne и т.д., не фиксирована модель данных, которой должны следовать передаваемые сообщения. Некоторые из них являются плоскими и хорошо укладываются в реляционную схему. Но имеются и иерархические сообщения, например, в канале FX по поводу курсов иностранных валют. Системы обработки потоковых данных, такие как StreamBase и Coral8, в настоящее время поддерживают только плоские (реляционные) сообщения. В таких системах входной адаптер должен нормализовывать иерархические объекты в несколько типов плоских сообщений для их дальнейшей обработки. Но, к сожалению, довольно неприятным занятием является соединение частей исходного сообщения, когда требуется обработка нескольких компонентов иерархии.

   Авторы статьи ожидают, что для решения этой проблемы поставщики потоковых систем будут активно переходить к использованию иерархических моделей данных, и тогда они, несомненно, отойдут от принципов Теда Кодда.

3. Очевидно, реляционная модель никогда не использовалась в области текстовой обработки.
4. В любой СУБД, ориентированной на обработку научных данных, такой как ASAP [SBC+07], в качестве базового типа данных, вероятно, будут использоваться многомерные массивы, а не таблицы.
5. В последнее время ведутся активные обсуждения моделей данных, подходящих для представления полуструктурированных данных. Конечно, энергично обсуждается чрезмерная сложность спецификации XMLSchema [SC05]. Имеются сторонники использования для таких данных RDF [MM04] и те, кто утверждает, что RDF можно эффективно хранить в реляционной базе данных с хранением данных по столбцам [AMM+07]. Авторы считают достаточным сказать, что имеется много идей, на которых может основываться дальнейшее развитие этой области.

Реляционная модель разрабатывалась для «безразмерного» мира. При переходе к специализированным системам для каждой из них можно подобрать модель данных, наилучшим образом соответствующую конкретным особенностям этой системы.

6.2 SQL также не является решением

SQL является «безразмерным» языком. В мире OLTP никого и никогда не интересуют служащие, зарабатывающие больше своих менеджеров. На самом деле, как отмечалось ранее, в этом мире вообще не задаются непредвиденные запросы. Следовательно, в этом случае достаточно было бы иметь некоторый язык, который был бы более ограниченным, чем SQL. По соображениям производительности вездесущими являются хранимые процедуры. В мире хранилищ данных требуется другое подмножество SQL, поскольку здесь распространены сложные непредвиденные запросы, но нет хранимых процедур. Поэтому для специализированных программных средств управления данными можно иметь специализированные языки, ориентированные на конкретный вертикальный рынок и не обладающие устрашающей сложностью, свойственной SQL.

Переосмысление количества одновременно существующих языков и их сложности будет обладать колоссальным положительным побочным эффектом. В настоящее время SQL – это унаследованный язык со многими известными серьезными недостатками, ряд из которых отмечался Крисом Дейтом еще два десятка лет тому назад [Dat84]. Следующая попытка разработки языков может оказаться более удачной.

При переосмыслении языков доступа к данным авторам вспоминается яростная дискуссия 1970-х гг. С одной стороны, имелись сторонники подъязыков данных, для которых могли бы иметься интерфейсы с любыми языками программирования. Это привело к появлению интерфейсов с высокими накладными расходами, таких как JDBC и ODBC. Кроме того, эти интерфейсы очень трудно использовать из традиционного языка программирования. С другой стороны, некоторые члены сообщества баз данных предлагали намного более привлекательные возможности доступа к базам данных, встраиваемые в языки программирования. Типичными представителями этих языковых средств в 1970-е гг. являлись Pascal R [Sch80] и Rigel [RS79]. В обоих этих средствах обеспечивалась полная интеграция со средствами языков программирования, такими как организация логики управления, локальные переменные и т.д. С теми же целями Крис Дейт предлагал расширение языка PL/1 [Dat76].

Как видно, ни один из этих языков не вошел в широкую практику, и победу одержало направление поъязыков данных. Сообщество баз данных средства разработало невероятно безобразные средства сопряжения языков программирования с подъязыком баз данных, и результатом являются низко производительные системы, происходящие из прошедшей эпохи. Поэтому авторы статьи выступают за полный отказ от подъязыков данных в пользу встраивания в языки программирования средств доступа к данным.

В сообществе языков программирования наблюдается бурное развитие «малых языков», таких как Python, Perl, Ruby и PHP. Идея состоит в том, чтобы для решения любой конкретной задачи можно было использовать язык, наиболее подходящий именно в этом случае. Малые языки привлекательны еще и тем, что их легче изучать, чем языки общего назначения. При взгляде со стороны это явление кажется симптомом конца эпохи «безразмерности» в мире языков программирования.

У малых языков имеются два очень приятные свойства. Во-первых, в большинстве случаев они относятся к категории open source и поэтому могут изменяться сообществом. Во-вторых, их не так страшно модифицировать, как современные языки общего назначения. В связи с этим, авторы выступают за модификацию малых языков с целью включения в них встроенных средств доступа к данным.

В настоящее время любимым примером этого подхода у авторов является Ruby-on-Rails. Эта система основана на малом языке Ruby, расширенном интегрированной поддержкой доступа к данным и манипулирования ими на основе паттерна программирования «model-view-controller». Ruby-on-Rails компилируется в стандартный JDBC, но вся сложность этого интерфейса скрывается.

Поэтому авторы планируют отказаться от применения языка C++ для программирования хранимых процедур в среде H-Store и перейти к использованию Ruby-on-Rails. Конечно, подсистема поддержки времени исполнения Ruby-on-Rails должна быть скомпонована в одном адресном пространстве совместно с СУБД, и ее необходимо изменить, чтобы вызовы служб СУБД производились с использованием высокопроизводительных локальных вызовов процедур, а не JDBC.

7. Резюме и планы на будущее

В последней четверти прошлого века произошел ряд серьезных изменений:

1. Рынки СУБД: произошел переход от одного рынка обработки бизнес-данных к набору рынков с разными требованиями.
2. Необходимые возможности: к числу новых требований относятся поддержка архитектуры «shared nothing» и высокий уровень доступности.
3. Технология: почти все изменилось благодаря наличию большого объема основной памяти, возможности «горячего» резервирования и существованию Web.

Результатом этих изменений является следующее:

1. предсказываемая кончина эпохи «безразмерности»;
2. несоответствие существующих реляционных реализаций требованиям какого бы то ни было сегмента рынка;
3. необходимость переосмысления моделей данных и языков запросов, соответствующих особенностям специализированных программных средств, которые, по ожиданиям авторов статьи, будут доминировать на различных вертикальных рынках.

Прототип H-Store демонстрирует выигрыш в производительности, который удалось получить за счет отказа от традиционного образа мышления. Конечно, несмотря на получение ободряющих начальных результатов, описанных в данной статье, имеется ряд областей, в которых необходимо проведение дополнительных исследований и разработок. В частности:

• Требуются исследования возможности автоматического определения одноузловых, двухфазных приложений с одноразовым использованием результатов. Также требуются автоматические средства, которые могли бы обеспечить разделение данных, ведущее к появлению у приложений этих свойств.
• Развитие технологии многоядерных процессоров наводит на мысль об интересных оптимизациях, связанных с совместной работой логических узлов, физически располагающихся в одном и том же компьютере.
• Требуется тщательное исследование эффективности различных стратегий управления транзакциями, общие черты которых были описаны в разд. 3.
• Изучение накладных расходов различных компонентов систем OLTP – журнализации, обработки транзакций и двухфазной фиксации, блокировок, JDBC/ODBC и т.д. – могло бы помочь установить, какие аспекты архитектуры традиционных СУБД приводят к появлению большинства наблюдаемых накладных расходов.
• После устранения всех этих накладных расходов общая производительность H-Store определяется эффективностью работы со структурами основной памяти, из чего следует важность оптимизации этих структур. Например, авторы обнаружили, что в H-Store достигается существенное повышение скорости обработки транзакций за счет простой оптимизации путем представления только читаемых таблиц в виде массивов.
• Если потребуется «бесшовное» сосуществование систем, подобных H-Store, с системами хранилищ данных, то существенной окажется интеграция со средствами поддержки хранилищ данных – путем использования, например, памяти с одноразовой записью и периодической выгрузки содержимого базы данных в хранилище данных.

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

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

Ссылки

[ABW06] A. Arasu, S. Babu, and J. Widom. “The CQL Continuous Query Language: Semantic Foundations and Query Execution.” The VLDB Journal, 15(2), June 2006.

[ACL87] Agrawal, R., Carey, M. J., and Livny, M. “Concurrency control performance modeling: alternatives and implications.” ACM Trans. Database Syst. 12(4), Nov. 1987.

[AMM+07] D. Abadi, A. Marcus, S. Madden, and K. Hollenbach. “Scalable Semantic Web Data Management Using Vertical Partitioning.” In Proc. VLDB, 2007.

[Ants07] ANTs Software. ANTs Data Server - Technical White Paper, 2007.

[BSR80] Bernstein, P.A., Shipman, D., and Rothnie, J. B. “Concurrency Control in a System for Distributed Databases (SDD-1).” ACM Trans. Database Syst. 5(1), March 1980.

[Bon02] P. A. Boncz. “Monet: A Next-Generation DBMS Kernel For Query-Intensive Applications.” Ph.D. Thesis, Universiteit van Amsterdam, Amsterdam, The Netherlands, May 2002.

[Dat76] C. J. Date. “An Architecture for High-Level Language Database Extensions.” In Proc. SIGMOD, 1976.

[Dat84] Date, C. J. “A critique of the SQL database language.” In SIGMOD Record 14(3):8-54, Nov. 1984.

[DGS+90] Dewitt, D. J., Ghandeharizadeh, S., Schneider, D. A., Bricker, A., Hsiao, H., and Rasmussen, R. “The Gamma Database Machine Project.” IEEE Transactions on Knowledge and Data Engineering 2(1):44-62, March 1990.

[Hel07] P. Helland. “Life beyond Distributed Transactions: an Apostate's Opinion.” In Proc. CIDR, 2007.

[HM93] Herlihy, M. and Moss, J. E. “Transactional memory: architectural support for lock-free data structures.” In Proc. ISCA, 1993.

[KL81] Kung, H. T. and Robinson, J. T. “On optimistic methods for concurrency control.” ACM Trans. Database Syst. 6(2):213-226, June 1981.

[LM06] E. Lau and S. Madden. “An Integrated Approach to Recovery and High Availability in an Updatable, Distributed Data Warehouse.” In Proc. VLDB, 2006.

[MHL+92] Mohan, C., Haderle, D., Lindsay, B., Pirahesh, H., and Schwarz, P. “ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging.” ACM Trans. Database Syst. 17(1):94-162, March 1992.

[Mil89] Mills, D. L. “On the Accuracy and Stability of Clocks Synchronized by the Network Time Protocol in the Internet System.” SIGCOMM Comput. Commun. Rev. 20(1):65-75, Dec. 1989.

[MM04] Manola, F. and Miller, E. (eds). RDF Primer. W3C Specification, February 10, 2004.

[RR99] Rao, J. and Ross, K. A. “Cache Conscious Indexing for Decision-Support in Main Memory.” In Proc. VLDB, 1999.

[RR00] Rao, J. and Ross, K. A. “Making B+- trees cache conscious in main memory.” In SIGMOD Record, 29(2):475-486, June 2000.

[RS79] L. A. Rowe and K. A. Shoens. “Data Abstractions, Views and Updates in RIGEL.” In Proc. SIGMOD, 1979.

[Rus74] Randall Rustin (Ed.): Proceedings of 1974 ACM SIGMOD Workshop on Data Description, Access and Control, Ann Arbor, Michigan, May 1-3, 1974, 2 Volumes.

[SAB+05] M. Stonebraker, D. Abadi, A. Batkin, X. Chen, M. Cherniack, M. Ferreira, E. Lau, A. Lin, S. Madden, E. O’Neil, P. O’Neil, A. Rasin, N. Tran, and S. Zdonik. “C-Store: A Column-oriented DBMS.” In Proc. VLDB, 2005.

[SBC+07] M. Stonebraker, C. Bear, U. Cetintemel, M. Cherniack, T. Ge, N. Hachem, S. Harizopoulos, J. Lifter, J. Rogers, and S. Zdonik. “One Size Fits All? - Part 2: Benchmarking Results.” In Proc. CIDR, 2007.
Перевод на русский язык: “Пригоден ли один размер для всех? Часть 2: результаты тестовых испытаний”

[SC05] M. Stonebraker and U. Cetintemel. “One Size Fits All: An Idea whose Time has Come and Gone.” In Proc. ICDE, 2005.
Перевод на русский язык: “"Один размер пригоден для всех": идея, время которой пришло и ушло”

[Sch80] Schmidt, J.W. et al. “Pascal/R Report.” U Hamburg, Fachbereich Informatik, Report 66, Jan 1980.

[TPCC] The Transaction Processing Council. TPC-C Benchmark (Revision 5.8.0), 2006.