Как говорил один чудак — «с нашей планетой все в порядке, за X миллиардов лет она многое пережила, а вот человечеству — пожалуй, пиз#ец»
http://www.paradiseoroblivion.ru/watch.htm
«В конечном итоге, избранный нами путь выявит, существует ли на самом
деле разумная жизнь на Земле»
Jacque Fresco
Как-то занимаясь разработкой ТЗ для одного заказчика столкнулся в очередной раз с проблемой хранения/выборки данных в кластере — как уже надоело препарировать проекты под NoSQL базы ! И тут как будто кто решил разом прекратить все эти мучения и уткнул меня носом прямо в NuoDB. «Это что-то !», как любят говорить герои в буржуйских фильмах. NuoDB — это новое слово в технологиях баз данных от самого Джима Старки ! Да, того самого Старки, который в свое время придумал многоверсионные базы и тип BLOB, создал Interbase, участвовал в разработке FireBird и MySQL. В 2008 году он перешел из MySQL в стартап Nimbus чтобы плотно заняться разработками в области облачных баз данных. Проект NuoDB (переименованный из NimbusDB) - это без сомнения то, чего уже много лет ждали многие разработчики, пользователи и просто бизнесмены. И теперь с уверенностью можно сказать что они таки-да, дождались 
Менеджмент компании NuoDB любезно разрешил мне перевести и опубликовать документ «Introduction to NuoDB» с целью поближе познакомить русскоязычное комьюнити с этим необыкновенным продуктом. Как говорят — «совершенная технология неотличима от магии», чего же больше в NuoDB первого или второго, ее будущим пользователям вскоре предстоит узнать самим.
Итак, встречайте — NuoDB !
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 однозначно обеспечивает безгранично масштабируемые транзакции !
P.S. Стал доступен общий технический обзор NuoDB, в частности есть сравнения по масштабируемости и производительности — http://vimeo.com/33785505
Перепечатка и/или копирование данной статьи без письменного разрешения правообладателей запрещена.
Идеальный аппарат для develop’инга так как есть SBK (rev < B70) — можно ставить от бубунты до любых ондроедов. Чудес изображения у IPS матрицы не заметил, а вот неравномерную подсветку (отчетливо видную на черном фоне) — это да. GPS чувствительность похуже чем у N900 (в помещении глухо как в танке, в то время как рядом лежащая нокия четко ловит 3-4 спутника). Слот micro-SD нежный — при неосторожном обращении с картой можно сломать и то и другое. Разьем наушников можно было бы сделать гарнитурным (с внешним микрофоном), так как внутренний на записи издает какой-то довольно громкий высокочастотный шум и расположен он почему-то сбоку. Жаль что нет USB входа, носить уродливый гаджет-переходник, а тем более док-станцию как-то совсем не хочется. Пачкается экран от пальцев — наверное это общая проблема планшетов, а может свойство данного покрытия. В комплекте могли бы положить простенький чехол, так как дешевый пластик сзади может скоро превратиться в безобразие.
Из софта как всегда отличилась Adobe — флеш встроенные камеры в упор не видит — судя по всему адоб вообще тупо забил на всех Linux пользователей. Ну с первым выходом webrtc-enabled хрома (и/или oper’ы/firefox) весь Linux-мир окончательно забьет на адоб, ждать, судя по всему, осталось пару месяцев максимум. Неприятно поразил идущий в комплекте текстовый редактор — как можно не учесть в таком ПО работу под Android ? Если вас отвлекли и вы не сохранили документ и по прошествии какого-то времени OS вытеснила редактор из списка активных задач, то вы потеряете все изменения в редактируемом файле ! Так же непонятно почему нельзя разные обои на разные столы прицепить — я-то думал это уже пройденный этап. Заявленый FM приемник (и передатчик ?) «искаропки» — наглая ложь. Приемник удалось запустить чисто хакерскими способами (через broadcom bluetooth модуль, залитую левую утилитку и правленый alsamixer), но чувствительность не валом. Про передатчик вообще ничего не скажу. Вобщем если все хорошо обпилить грубым напильником — то как-то еще пользоваться этим девайсом можно.
Ну и напоследок — цена его никак не может превышать $300, но то ли у нас не ту страну назвали Гондурасом, то ли еще чего …
В процессе апгрейда с 500GB WD на 3TB Hitachi IBM оказалось, что Linux прекрасно себя чуствует — разбивает, видит, перносится (обычным ‘cp -a’ копированием) и грузится (LILO (!) пашет как часы, несмотря на отсутствие официальной поддержки динамических дисков) с GPT разделов на обыкновенном (Award) BIOS, что не скажешь за 7 ведро. Разбивка, форматирование, перенос EXT4, установка загрузчика LILO и получение полностью работоспособного Linux заняло 15 минут, с ведром я промучался два дня, и как понял зря. Короткий совет — не теряйте время — сносите и переставляйте ведро сразу — это займет от силы 1 час, но не многие часы утомительной и бесполезной битвы как это, в частности произошло со мной. Бестолковая венда (причем это последняя 64-bit SP1 семерка) до сих пор не умеет грузится с GPT на не EFI BIOS’ах. Сами диски, то она еще с грехом пополам видит — но глюки просто дикие — например разбитый в Linux GPT NTFS раздел она увидела как «шифрованный EFI диск», Linux’овому EXT4 разделу она вообще назначила букву E: и прямо заявила что дескать у нее есть программы, которые этот диск будут использовать (свят-свят-свят !), ну а вход в меню «Форматировать» активен, видимо, по принципу соответствия размера раздела и цвета колец Сатурна … жесть ! И не дай Бог при стандартной процедуре восстановления через оригинальный установочный диск ведро увидит в системе просто стоящий рядом GPT диск — тут же с ходу получите сообщение, что система дескать не поддерживается какой-то там «конфигурацией восстановления» и вообще типа — «чего пристали ?». Хотя восстанавливать я собирался обыкновенный MBR диск, так же установленный в системе. Ясен пень — перенести 7 ведро с одного MBR диска на другой (видать это какая-то спец-шаманская ботва в мире мокрософт) у меня так и не получилось, хотя XP в былые времена переносилось с лету. Были испробованы ряд средств — копирование системы в Linux, перенос с помощью Norton Ghost, перенос диска с помощью Acronis TrueImage и перенос раздела с помощью Acronis Home Director — ошибка всегда одна и таже — не могу дескать найти тут посреди себя свой диск и гайки — грузитесь, мол, с установочного диска и процедура восстановления вас однозначно спасет ! Вестись на этот дешевый рекламный трюк нет смысла — ежику понятно что мир спасет не установочный диск от m$, а красота и массовые расстрелы там же. Все произошло в точности по стандартному сценарию их очередного поделия — хваленая процедура восстановления бойко проделала первую операцию по корректировке размещения раздела в системе — перезагрузились, та же задница. Во второй раз ведро уже более печально просканировало все файлы инсталляции — естественно так и не найдя проблем, после перезагрузки аналогичный результат. И наконец в третий раз оно тупо выдало сообшение о своей полной и окончательной импотенции. Чтобы это бестолковое, уже седьмое как-бы по счету, ведро смогло выполнить свою единственную функцию — пришлось его полностью переставить, так как новый 2GB Radeon HD 6970 и Crysis2 уже давно ждут своего часа …
Ну ладно их глючный SIP телефон (попробуйте установить переадресацию с MTC), ладно их дебильный автоответчик, или tech-sup телефон, который никто не берет по полчаса, а если и удастся дозвониться, то этот типа круглосуточный support team только и может промычать что-то типа «завтра днем будем разбираться», ладно их цены выше крыши — но неспособность перевести меня из одного пакета в другой — это я думаю уже климакс. Платил им за WiFI (10 Гбайт) и за SIP телефон, хотел платить больше — [180 грн.] (2Mbit unlimited) + [35 грн.] за SIP — но судя по беседе с их «нас#рать на всех» менеджером это никому кроме меня не нужно. Были конечно подозрения что есть такие дефективные компании в природе, но теперь я точно знаю где они находятся Отключился от них нафиг — пусть для начала научаться уважать рядового клиента и выполнять хоть как-то свою работу. Про честность и порядочность там речь точно не идет — биллинг у ихней SIP телефонии считает звонки по городу набранные через 048X как междугородние Попадется им товарищ, которому не лень будет побегать по судам — просто выставит их на деньги. В общем говорить тут больше не о чем, как мудро отмечают восточные люди — «в засохшее дерево камней не кидают».
Бедное LILO, проект затерялся во времени, только debian его хоть как-то еще поддерживает. Трабл в том что arch/x86/boot/tools/build.c file определяет SETUP_SECT_MAX как число 64, но в lilo define равен 31, что и приводит к данной ошибке в случае последних ядер, собранных например gcc-4.6.0 (толстоват выходит код) или упакованных xz. Установка значения в 63 значительно облегчает жизнь.
После upgrad’а mdadm случилась такая фигня, лечится :
mdadm —stop /dev/md127
mdadm —assemble /dev/md0 /dev/sdX1 /dev/sdX2 … /dev/sdXn
SpyGroup application runs in Asterisk and MySQL environment and used for spying on predefined groups of VoIP users. The spying operation is protected by unique password that used to select which group will be spyed on. All the data (group numbers, extensions list, passwords) are stored in MySQL database. The setspygroupd daemon checks all active calls for database extension match, if exact match found — the extension will be added to predefined group number.
Если интересует XML вариант, то welcome to http:/sfinxsoft.com/products
P.S. Прикольная бага в glibc-2.12 — любое статическое приложение, использующее getpw* функции с незапущеным ncsd (кто ж его пущает ?!) получит что-то типа «../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0′ failed.»
Подробнее см. http://sourceware.org/bugzilla/show_bug.cgi?id=11929
По причине скропостижного ухода старого винта на ноуте, был приобретен новый WD на 750GB (хотел терабайт, но в Одессу его обещали везти не менее недели). WD винты — это середнячки в плане механики/электроники и совершенно глючная и недопетая песня в плане firmware. For example — кэш на запись у них включен всегда (!) и не запоминается его выключение через power off/power on cycle, так как на флаг keep_features_over_reset фирма WD просто забила (проверено через hdparm и их дефективный саппорт). В Linux’е это как-то не страшно, а вот в венде юзверя постоянно теряют файлы при неожиданном пропадании питания. Также у WD уникально (в любимом стиле brain-dead) реализована защита винта паролем — не дай Бог host пошлет link reset — винт опять заблокируется То, что link reset это нормальная операция по ходу работы SATA, в WD видимо не в курсе. В Linux на этапе загрузки достаточно задать ядру что-то типа libata.force=1:nohrst libahci.skip_host_reset=1, в венде, ясен пень, получим синий экран смерти с невнятным толкованием самой сути ошибки. И напоследок довольно грустная история о том, что WD втихаря перешла на 4K сектора, но никому об этом не сказала — винт предательски рапортует что у него они по 512 байт (видать из-за соображений совместимости со старыми BIOS) и соответственно все программы разбиения и создания файловых систем работают с неверным выравниваем. Цена такой ошибки может приводить к падению производительности в 5.5 раз (http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/2955) ! В общем Hitachi-IBM наш ответ Чемберлену — может WD и научатся писать firmware со временем, но пусть это будет их время.
Раз пошла такая история с винтами, решил — дай думаю, btrfs потестю — как она там бедная ? А то все ее пилят, дотачивают — мож уже в production пора ? Тупой тест распаковки на закэшированом несжатом tar файле (900M) с исходниками Linux показал, что ext4 справляется с этой незатейливой операцией за 12.5 секунд, а btrfs за 26.5. Хуже всего с удалением всего того, что было распаковано, ext4 — 2.7 секунды, а btrfs — 14.5 секунд. Ядро 2.6.35.5, последние btrfs-tools, железо — старенький Acer Ferrari 1100 (2 AMD ядра 2.3 GHz, SB600 чипсет, 4GB RAM, SATA WD Scorpio 750GB). Вобщем btrfs пока нельзя рассматривать как достойную замену существующим FS, разве что очень нужны snapshot’ы.
Subscribe