Tag sql

Революция в мире баз данных

Как-то занимаясь разработкой ТЗ для одного заказчика столкнулся в очередной раз с проблемой хранения/выборки данных в кластере — как уже надоело препарировать проекты под NoSQL базы ! И тут как будто кто решил разом прекратить все эти мучения и уткнул меня носом прямо в NuoDB. «Это что-то !», как любят говорить герои в буржуйских фильмах. NuoDB — это новое слово в технологиях баз данных от самого Джима Старки ! Да, того самого Старки, который в свое время придумал многоверсионные базы и тип BLOB, создал Interbase, участвовал в разработке FireBird и MySQL. В 2008 году он перешел из MySQL в стартап Nimbus чтобы плотно заняться разработками в области облачных баз данных. Проект NuoDB (переименованный из NimbusDB) - это без сомнения то, чего уже много лет ждали многие разработчики, пользователи и просто бизнесмены. И теперь с уверенностью можно сказать что они таки-да, дождались ;) Менеджмент компании NuoDB любезно разрешил мне перевести и опубликовать документ «Introduction to NuoDB» с целью поближе познакомить русскоязычное комьюнити с этим необыкновенным продуктом. Как говорят — «совершенная технология неотличима от магии», чего же больше в NuoDB первого или второго, ее будущим пользователям вскоре предстоит узнать самим.
Итак, встречайте — NuoDB !


NuoDB, обзор продукта

Масштабируемость, ACID Транзакции, SQL

NuoDB это первая в мире облачная база данных, которая поддерживает транзакции. Частные и общедоступные облака — это новый, захватывающий способ предоставления компьютерных услуг с наблюдаемой тенденцией вполне определенной экономической неизбежности их распространения. Но на этом поприще существует и большая техническая проблема: управление транзакционными данными обычно не масштабируется более чем на один сервер или небольшой кластер, который ведет себя как однин сервер. До сегодняшнего дня в мире баз данных не существовало решений, которые бы могли одновременно предоставить масштабируемость, транзакции и SQL. NuoDB изменила этот мир. Представьте себе, что вы сможете динамически расширять свои транзакционные базы данных путем простого удаления или добавления узлов в живую, работающую систему. Представьте, что есть возможность перемещения работающей базы данных из датацентра в Нью-Йорке на сервера в Токио без простоя ваших приложений. Представьте что вы можете указать вашей базе данных задействовать несколько запасных серверов в Лондоне и получить эту дополнительную мощность всего через несколько секунд. Или что вы можете иметь сколь угодно много работающих копий ваших баз данных одновременно с минимальным влиянием на общую производительность. Представьте, что часть вашей базы данных может работать на серверах вашего частного датацентра, а часть на общественном облаке или что в моменты пиковой нагрузки вы можете мгновенно увеличить мощность базы поключив какие либо другие, внешние вычислительные ресурсы. Представьте, что вы в состоянии на лету решать, какие базы данных и на каких серверах или облаках должны быть размещены. Что вам никогда больше не нужно будет вручную оптимизировать вашу базу, и при всем этом она будет иметь производительность, которая значительно превосходит традиционные клиент-серверные и клиент-кластерные решения.
Эти и другие новейшие достижения возможны благодаря радикально новой архитектуре баз данных основанной на P2P технологиях. NuoDB снаружи выглядит и ведет себя точно так же как и традиционные SQL базы данных, но внутри вкорне от них отличается. Это новый класс решений для нового класса центров обработки данных. Когда промышленность перешла от мэйнфреймов к клиент-серверным архитектурам, возникла необходимость в базах данных нового образца и появились базы данных архитектуры клиент/сервер. Так и в настоящее время, когда все двигаются по направлению к публичным и частным облакам возникла необходимость в базе данных изначально созданной для работы в облаках. NuoDB иногда даже называют «Святым Граалем» облачных вычислений. Ведь любой другой подход использования облачных баз данных заставит вас отказаться от всех ваших успешных наработок, инструментов и навыков, забыть про SQL и ACID транзакции. Неужели это все должно быть принесено в жертву только для того чтобы перенести БД в облачный датацентр будущего ? К счастью запатентованная технология NuoDB навсегда избавляет от этих проблем так как блестяще сочетает возможности масштабирования, ACID и SQL. Эта статья ставит своей целью познакомить читателя с возможностями продукта NuoDB.

NuoDB изначально создана для работы в облаках.

NuoDB это:

1. SQL
2. Транзакции
3. Масштабируемость (Elastic)
4. Multi-tenant
5. Не требует администрирования (Zero admin)
6. Гео-распределенность
7. Non-Stop
8. Расширяемость в реальном режиме времени
9. Высокая производительность

NuoDB основана на реляционной модели данных, с всеми современными расширениями. Поддерживается стандартный язык запросов SQL и API стандарт JDBC. Ее внешняя модель данных — те же строки и таблицы. С точки зрения клиента базы данных NuoDB, она ничем не отличается от обычных клиент-серверных баз данных, которые в настоящее время используются почти в каждом бизнесе на планете. Весь доступ к данным осуществляется через ACID транзакции: атомарные, согласованные, изолированные и долговечные. Все транзакции NuoDB или удачны или нет, т.е. выполняется принцип атомарности. Управление конкурентным доступом с помощью многоверсионности (MVCC) дает возможность каждой NuoDB транзакции иметь согласованное представление о данных — принцип согласованности. Ни одна транзакция не увидит незавершенные действия другой транзакции — принцип изолированности. И наконец соблюдение принципа долговечности достигается благодаря тому что в NuoDB данные распределяются в виде обьектов между всеми ее серверами в облаке, которые специально предназначены для хранения информации. NuoDB работает на динамически изменяемой группе машин, которая называется »Хор». Хор включает в себя два типа узлов: узлы транзакций и узлы архивирования, которые соответственно обрабатывают транзакции и выполняют операции записи и чтения с диска. Любое количество транзакционных и архивных узлов могут быть добавлено или удалено в любой момент, но минимальный хор должен обязательно содержать один транзакционный и один архивный узел. Добавление транзакционного узла не требует какой либо настройки для БД — вы просто указываете базе имя нового сервера и учетные данные для доступа к нему. Добавление транзакцонных узлов увеличивает общую пропускную способность БД, удаление соответственно уменьшает. Добавление архивых узлов увеличивает обьем и избыточность хранения данных в базе вместе с увеличением ее пропускной способности. Узлы в хоре NuoDB могут быть гетерогенными, состоять их произвольного набора различных серверов, аппаратных средств и операционных систем с совершенно разной производительностью. Любое количество экземпляров NuoDB может работать на любом наборе NuoDB узлов. Любой узел может быть выделен для отдельной БД или использоваться несколькими базами данных в любой конфигурации. Другими словами хоры могут иметь выделенные узлы, могут частично перекрываться узлами с другими хорами или могут даже полностью с ними совпадать. Традиционно SAAS поставщики предоставляют multi-tenant сервисы для приложений своих клиентов, разместив данные нескольких клиентов в одной клиент-сервер/клиент-кластер базе данных. Конечно, это решение будет работать и в NuoDB, но это более не является необходимым. Несколько баз данных NuoDB может запросто сосуществовать на общей серверной ферме. Это позволяет датацентрам применять решения, которые максимально используют их серверные и сетевые ресурсы. Т.е. персонал публичного облака, которое имеет более чем 10000 баз данных своих клиентов сам сможет решить, какие базы данных, в каком количестве и на каких машинах будут размещены, и все это можно проделать в режиме реального времени. Инсталляция NuoDB очень проста. В отличие от традиционных баз данных, которые могут потребовать несколько дней на конфигурацию прежде чем их можно будет использовать, NuoDB является простой системой, которая может быть запущена на любом узле в течение нескольких минут. Ценное время DBA должно быть потрачено на проектирование баз данных, а не конфигурацию компьютера.

Настройка традиционной базы данных занимает 10-15% всего времени администраторов баз данных.

NuoDB не требует тюнинга. Данные автоматически распространяются через хор, по необходимости. NuoDB не нуждается в partitioning, sharding или striping. На производительность NuoDB существенно не влияет ни размер дискового блока ни любые другие связанные с диском параметры. Отсутствие процедуры тюнинга БД как такового значительно сокращает обьем работы DBA. Балансировка нагрузки в хоре NuoDB происходит автоматически и не требует никаких усилий от DBA. NuoDB гарантирует, что все узлы под управлением данной базы данных в равной степени буду заняты и использованы. Таже не существует какого-либо отдельного механизма балансировки нагрузки. Более отзывчивые узлы в хоре просто получат больше работы. В сочетании с multi-tenant способностью использование облака может быть оптимизировано очень небольшими административными усилиями.

Репликация и High Availability (HA) составляют более 10% времени администрирования обычных БД.

NuoDB автоматически обеспечивает репликацию обьектов, которые находятся как в памяти так и и на диске. Все усилия администрирования сводятся к подключению по мере необходимости дополнительных узлов архива. Высокая доступность (HA) не является чем-то особенным для NuoDB — она является основой ее архитектуры. Эта база данных устойчива к отказам узлов, части облаков, датацентров или сетевой инфраструктуры. Архивные узлы в NuoDB содержат полноценные резервные копии данных — это значит, что больше не нужно заниматься бэкапами в традиционном их понимании. Естественно NuoDB позволяет это делать если по каким-то причинам это необходимо. Имея несколько архивных узлов вы можете просто перевести один в автономный режим и поместить его в хранилище. Или можете его отключить, сделать бэкап файловой системы и включить вновь. В подавляющем большинстве случаев вы можете смело забыть про необхоимость бэкапа вашей базы — намного проще и дешевле просто добавить еще один архивный узел для повышения избыточности ваших данных. Также удаленные или внешние архивные узлы смогут обеспечить актуальный бэкап даже в случае полного отказа вашего датацентра. Резервное копирование это просто еще одна DBA задача которая полностью автоматизирована в NuoDB. Апгрейд оборудования и/или операционных систем не влияет на работу NuoDB и может быть сделан постепенно прямо на живой системе. Машины можно отключать, обновлять и подключать вновь к работающему хору, без никакого влияния на приложения, работающие с данной базой данных. Машины могут быть заменены на совершенно другие с различной архитектурой, конфигурацией памяти, операционной системой и производительностью. В хоре более быстрые машины будут просто выполнять больше работы, чем более медленные. Также само программное обеспечение NuoDB можно обновлять постепенно — узел за узлом. В NuoDB при смене ПО базы данных на более новую версию нет необходимости в остановке обслуживания. Сравните ситуацию с обыкновенной реляционной базой: время перехода на новую версию БД может легко парализовать IT инфраструктуру на несколько дней. NuoDB может быть размещена одновременно в нескольких географически разнесенных центрах обработки данных, при этом будет обеспечиваться распределение нагрузки, отказоустойчивость и независимость такого разделения. Для таких инсталляций рекомендуется, чтобы каждый датацентр имел не менее двух транзакционных и двух архивных узлов. Дополнительные узлы могут быть добавлены и удалены по желанию. При этом если один из датацентров откажет или потеряет связь с другим — база данных останется полностью доступна для всех клиентов, которые все еще могут подключится к оставшейся части. Архивные узлы NuoDB могут быть размещены на удаленных серверах, например с целью резервирования. Живая копия базы может находится где-то в подземном бункере или на серверах любых компаний, которые предоставляют услуги хранения данных. СУБД облако NuoDB с двумя или более архивными узлами не имеет критических точек отказа — любой узел может выйти из строя или может быть удален, а оставшиеся узлы продолжат работу. Пока хотя бы один транзакционный и один архивный узлы продолжают работать, база данных остается доступной. NuoDB не нуждается в незагруженных или бездействующих серверах для обеспечения бесперебойности в ее работе. Целые сервера, в том числе и архивные узлы могут быть отключены для ремонта или апгрейда, после включения они сами синхронизируются и встанут в строй. Таким образом можно внутри облака постепенно обновлять и само ПО NuoDB особо не влияя на ее работу. Когда последний сервер будет обновлен, облако прозрачно переходит на новую версию БД. NuoDB не имеет ограничений по масштабируемости, следовательно производительность является простой функцией от количества машин, которые обслуживают базу. Помимо своей масштабируемости ядро системы по самой своей природе является чрезвычайно производительной базой данных. NuoDB можно рассматривать «базу данных-в памяти», в то же время не требующей, чтобы все данные хранились в памяти. Большинство высоконагруженных операций выполняется исключительно в памяти, по этой причине NuoDB быстрее на том же железе чем традиционные базы данных типичных клиент-сервер / киент-кластер архитектур.

Резюме

NuoDB является ключевым решением для облачных вычислений. Датацентры будущего будут основаны на масштабируемых, multi-tenant облаках из недорогих и взаимозаменямых машин. Существует все, необходимое для использования этой новой архитектуры центров обработки данных, как аппаратные средства, так и системное и прикладное программное обеспечение. А с NuoDB у нас теперь есть и решение последней оставшейся ключевой проблемы облаков :

NuoDB однозначно обеспечивает безгранично масштабируемые транзакции !

Copyright NUODB, Inc. All rigts reserved


P.S. Стал доступен общий технический обзор NuoDB, в частности есть сравнения по масштабируемости и производительности — http://vimeo.com/33785505 и обзор архитектуры + getting started - http://vimeo.com/48533135

Перепечатка и/или копирование данной статьи без письменного разрешения правообладателей запрещена.