Category Блоги

OrientDB C++ driver intro

23 Февраль, 15:16, by Rus Метки:

The C++ connector to OrientDB can be used in various applications that need simple remote access to this DB. Connector uses the OrientDB Network Binary Protocol and supports three query languages — SQL, JavaScript and Gremlin.

SQL access example :

#include "db.h"
using namespace OrientPP;
...
orientsrv server("localhost", "root" , "root_pass");
if (!server.dbexists("test_db"))
server.createdb("test_db", AS_GRAPH_DB, DB_LOCAL_STORAGE);
orientdb db(server);
db.open("test_db", AS_GRAPH_DB, "admin", "admin");
clog << "DB size: " << db.size() << endl;
clog << "DB records count: " << db.count() << endl;
orientquery q(db);
q << "select * from ouser where name = 'admin'";
orientresult_ptr res = q.execute(AS_SQL);
dump_result(res);
db.close();

JavaScript query example :

orientsrv server("localhost", "root" , "root_pass");
orientdb db(server);
db.open("test_db", AS_GRAPH_DB, "admin", "admin");
q << "var r = db.query('select from ouser');print(r);r";
orientresult_ptr res = q.execute(AS_JAVASCRIPT);
dump_result(res);

Gremlin query example :

orientsrv server("localhost", "root" , "root_pass");
orientdb db(server);
db.open("test_db", AS_GRAPH_DB, "admin", "admin");
q << "v = g.addVertex()";
orientresult_ptr res = q.execute(AS_GREMLIN);
dump_result(res);

The demo dump_result() code can be taken from orientpp test.cpp file and looks like :

string dump_record(orient_record_t &r);

void dump_result(orientresult_ptr res)
{
clog << "Result has " << res->records.size() << " records" << endl;
for (u32 r = 0; r < res->records.size(); r++)
clog << "#" << r << " " << dump_record(res->records[r] << endl);
}

string dump_record(orient_record_t &r)
{
stringstream ss;
if (r.rid.valid) {
if (r.is_document()) {
ss << string(r.rid) << " class:" << r.classof();
for (property_iterator it = r.properties.begin();
it != r.properties.end(); it++) {
property_t p = it->second;
ss << " t:" << p.type2str() << " n:" << p.name << " v:" << string(p);
if (p.type == ORIENT_RECORD_TYPE_COLLECTION) {
ss << " [";
for (uint i = 0; i < p.embedded.size(); i++) {
if (i)
ss << " | ";
ss << "t:" << p.embedded[i].type2str();
if (p.embedded[i].name.size())
ss << " n:" << p.embedded[i].name;
ss << " v:" << string(p.embedded[i]);
}
ss << " ]";
}
}
} else
ss << string(r.rid) << " " << string(r);
} else
ss << string(r);
return ss.str();
}

OrientDB или здравствуй дерево !

Несмотря на избитость и некую внешнюю пошарпанность темы, я все-таки подниму ее из пыли земной, слегка отряхнув, зажгу и воткну пылающим факелом знаний в темную ж… БД-невежества.

«Если в руке SQL база, то все вокруг кажется таблицами»

Народная программистская пословица

2D Тупик

И года не может пройти в нашем беспокойном мире без революций в той или иной сфере, конечно, не считая вечно кровавого политического болота. К счастью не политики, а именно окружающий мир (где они, к сожалению, тоже присутствуют) и определяет как будут выглядеть базы сегодняшнего и завтрашнего для. Наблюдается опеределенная тенденция — устаревшие реляционные 2D базы со своим псевдо-стандартным SQL отходят в прошлое, их место занимают более востребованные облачные БД с новыми возможностями и новыми языками запросов (NewSQL), а порой вовсе без них (NoSQL). Двухмерные таблицы старых БД не в состоянии обеспечить поддержку, по крайней мере, двух самых насущных парадигм, применяемых при решении современных социально-ориентированных задач, в которых первостепенную роль играют связи (виды связей) и/или отношения между обьектами. Первая парадигма — это иерархичность (трехмерность) классов обьектов и связей между ними (for ex. тот же социум со своими связями разного масштаба, производственные процессы, базы знаний и т.д.) Вторая — обьектно-ориентированная природа данных в задачах и, как следствие, желание естественным образом сохранить ее в БД. Увы, 2D базы никогда не были в состоянии хранить и более менее сносно осуществлять поиск в древовидных и графоподобных структурах данных, так как тяжеловесность доступных алгоритмов просто выходит за всякие рамки. Приведу яркий пример для MySQL (привет фэйлбук !) — табличка времени исполнения, на современном 4-ядерном лаптопе с 8GB RAM, запроса выдачи дерева друзей для всего 1000 юзеров при разной, и совершенно не впечатляющей глубине, (до 5) дерева [взято из книги "Neo4j in Action"] :

ГлубинаВремя выполнения (секунд) для 1`000 юзверейРезультат (записей)
20.028~900
30.213~999
410.273~999
592`613.150~999

Вот оказывается почему большинство социальных сетей жутко тормозит и глючит ;)

А если мы усугубим ситуацию и добавим поиск сразу по нескольким разным классам отношений между обьектами, например — выдать дерево всех друзей юзеров и их друзей и друзей их друзей и т.д., которые смотрели фильм X И играют в игру Y, поиск производить по уровню вложенности не более 5, результат ограничить уровнем вложенности 3 ? Думаю любая 2D база тупо загнется при таком JOIN запросе даже на смешном, по понятиям социальных сетей (несколько тыщ), количестве пользователей. А если типов связей больше сотни и дерево глубиной в сотни тысяч уровней ? Об осуществлении каких либо сложных аналитических операций над таким обьемом данных здесь можно сразу напрочь забыть, тут бы как-то справится со стандартной web нагрузкой. Та база, о которой пойдет речь в этой заметке легко осуществляет такой поиск за единицы миллисекунд — можете сопоставить ее мощность с вышеприведенными данными для 2D баз. Эх, как же сложно выживать фэйлбукам в обнимку с MySQL, т.е. с орками^H^H^H^H^HOracle в этом жестоком мире …

От синематографа к HD3D

Занимаясь, на досуге, разработкой облачной персональной базы знаний, я вновь уперся в старое и уже порядком доставшее противоречие — невозможность эффективного использования современных (в том числе и облачных) БД для простеньких задач представления знаний. Эти БД — просто «не тянут», применяемый там язык SQL похоронен под бетонным непрактичным стандартом (несмотря на трезвый анализ могучего Стонебрейкера «Future Trends in Database Systems», сделанный еще в конце 80-ых, который видимо пофигу, считающими себя не менее могучими, разработчикам современных БД), а их «универсальные» типы данных — это все тот же каличный набор от древних компьютерных мастодонтов 60-х, с небольшими вариациями.

Гуголь на вопрос «что же теперь делать ?» выдал две фотки грустных обезьянок, одну карикатуру на Гитлера, рисующего черной краской на стене надпись «П.здец всему» и ссылку на OrientDB. О, пожалуй, последнее стОит более тщательного рассмотрения …

«Выборы, выборы, кандидаты …» (C) Ленинград

Так какие же сытные ништяки обещает нам OrientDB по сравнению с общепринятыми решениями ?

Кратко :

  1. обьектная база по определению, что позволяет создавать афигенские типы данных включая, например, такую экзотику в БД как абстрактные классы (!)
  2. NoSQL с поддержкой SQL — вот такой вот хитрый и завораживающий микс
  3. поддержка ACID транзакций (вот Вам батенька и тупой NoSQL …)
  4. поддержка скриптовых языков на стороне клиента и сервера — из впечатляющих бонусов: Javascript (!).
  5. поддержка stored procedures, которые можно ваять на Javascript, Ruby, Scala, Java или печальном Groovy. Процедуры могут вызывать друг друга, поддерживаются рекурсия, вызов через REST, авто-маппинг параметров по имени и работа с обьектами от плагинов
  6. работа с деревьями, включая расширения SQL аля create vertex/edge и traverse с кипой примочек
  7. поддержка distributed и HA в ввиде master-master репликаций
  8. эффективная поддержка multi-tenancy и partitioned данных вплоть до уровня одной записи и легко вытекающая отсюда возможность использовать security at record level (horizontal security)
  9. open source, т.е. открыты исходники, протоколы и документация. Последняя в принципе далека от идеала, так что пользу придется извлекать в основном из первых двух источников
  10. неплохая скорость работы и отсутствие требований к гигабайтам свободной памяти как, к примеру, у БД от патентных троллей и скупщиков кр^H^H opensourc’а
  11. несмотря на то что сама база писана на джаве, имеются коннекторы под другие языки и довольно подробно описан бинарный протокол, зная который можно за короткий срок написать свой собственный коннектор под какой-нить новый супер-пупер язык (у меня ушло всего 2 дня на беглую реализацию варианта для C++). Есть коннекторы под PHP, NodeJS, etc. и наконец есть возможность работы просто через REST.

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

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

1. убеждаемся что в системе стоит jdk, если нет — качаем его с файлопомойки патентного тролля-неудачника

2. Набираем :

svn checkout http://orient.googlecode.com/svn/trunk/ orient-read-only
cd orient-read-only
ant installg

installg соберет и поставит в ../releases/orientdb-graphed-x.x.x-SNAPSHOT полную, так называемую graph версию базы, где есть поддержка tinkerpop blueprints и gremlin. Зачем оно надо прямо сейчас ? — хрен его знает, но все равно приятно, что оно на всякий случай есть под рукой ;)

3. Заходим в …/orientdb-graphed-x.x.x-SNAPSHOT/bin и запускаем server.sh При первом запуске в config файле БД автоматически сгенерятся пароли для админки сервера (root user password) и дефолтный юзер/пароль для вновь создаваемых БД (обычно user:admin, pass:admin). Как видим запуск этой БД очень прост даже для искушенных в своем невежестве юзверей. Конфиг лежит в …/orientdb-graphed-x.x.x-SNAPSHOT/config/orientdb-server-config.xml, там же можно разрешить запускать скрипты на сервере (для этого надо выставить параметр enabled в true для com.orientechnologies.orient.server.handler.OServerSideScriptInterpreter класса)

4. На другом терминале запускаем …/orientdb-graphed-x.x.x-SNAPSHOT/bin/console.sh и попадаем в командный монитор БД. Нужен он для выполнения базовых операций с БД, как-то: ее создание, администрирование, проверка запросов и т.д., все выделенные ниже команды запускаются именно из него.

Итак создаем базу :

create database remote:/test root root_pass local graph

Параметр remote говорит нам о том, что с базой будем работать по сети, тип storage local значит, что база будет располагаться на файловой системе сервера (можно указать тип memory — тогда база самоликвидируется при перезапуске сервера) и graph обозначает тип базы (graph или document). Первый тип используется когда нужна вся мощь работы с графами, второй имеет более простую и быструю их реализацию — связи могут быть только однонаправленными, не могут иметь properties, отключен blueprints и gremlin и т.д.

Также как и в обычных БД, OrientDB оперирует записями. Есть разные типы записей, но в основном используется понятие «документа» (document) — это запись, принадлежащая определенному классу и имеющая набор произвольных атрибутов.  Атрибуты иногда называют полями (fields) или свойствами (properties). Ну а что такое класс, должны хорошо знать те, кто читал Страуструпа первой редакции на ночь для достижения быстрого, крепкого и безмятежного сна.

Посмотреть какие классы есть у нас в базе можно командой classes, создать новый класс командой create class :

create class Contacts

Классы с натяжкой можно было бы приравнять к таблицам в обычной 2D БД, если бы не одно но:

insert into Contacts (name,surname) values (‘James’,'Bond’)

select * from Contacts

#RIDnamesurname
0#13:0JamesBond

Здесь мы можем наблюдать прикольное свойство OrientDB — не обязательно задавать тип и перечень полей записи при создании определенного класса или самой записи — это можно делать на лету (при вставке например). Но это еще не все — набор полей может быть разным/индивидуальным для каждой записи данного класса или произвольно меняться для любой записи в операциях insert/update.  Это свойство позволяет OrientDB гибко работать с данными, набор параметров которых, к примеру, изначально не известен или меняется по ходу работы приложения:

insert into Contacts (name,age) values (‘Batman’,30)
update Contacts set city = ‘Gotham’ where name = ‘Batman’

select * from Contacts where name = ‘Batman’

#RIDnameagecity
0#13:1Batman30Gotham

Ясен пень — работать в режиме стандартной БД, уныло вставляя все поля в соответствии с жесткой схемой, заданной для каждой записи тоже можно. Другая фишка OrientDB, которая прямо вытекает из вышеприведенной — это непосредственное управление (произвольный CRUD для произвольной записи) данными типа «associative array» или «map» внутри любой записи. Для этого команда UPDATE расширена подкомандами ADD (для массива) PUT (для map) и REMOVE для обоих типов :

update Contacts ADD tags = ‘superhero’
update Contacts PUT phones = ‘mobile’, ‘+007′ where name = ‘James’
update Contacts PUT phones = ‘office’, ‘+MI5′ where name = ‘James’
select * from Contacts where name = ‘James’

#RIDnamesurnametagsphones
0#13:0JamesBond[1]{mobile=+007, office=+MI5}

orientdb> display 0
—————————————————
ODocument — Class: contacts id: #13:0 v.3
—————————————————
name : James
surname : Bond
tags : [superhero]
phones : {mobile=+007, office=+MI5}

Ну а юзать массивы и maps внутри записей можно также, как это обычно и принято, конечно если БД такое умеет и позволяет. В случае с OrientDB это делается где-то так :

select phones from Contacts where phones.size() > 0
select phones from Contacts where phones.keys() in ‘mobile’

Продолжение впереди …

Fuck you Hitachi !

28 Июль, 21:50, by Rus Метки:

В процессе сборки небольшого кластера для одного проектика (25 6-ядерных машин) столкнулся с безобразным отношением службы поддержки фирмы Hitachi (HGST Storage) к конечным пользователям. Всегда уважал качество винтов Hitachi, поэтому выбор пал на 7ZK500 серию, модель HTS725050A7E630. Этот винт идет с 32MB кеша, 7200 rpm, SATA-III, тонкий, легкий, экономичный и недорогой — вобщем то, что как раз и надо. Купил ящичек этих винтов, воткнул в серваки, включаю, то да се … и тут грабли ! Скорость записи на винт колеблется от 700kB/s до 20Mb/s, а в среднем составляет 2Mb/s ! Ну, серваки — Tyan, мамки — Tyan, память — ECC, питание — супер. Значит что-то между винтом, контроллером и драйвером OS. Подкидываю другие винты к этой мамке — скорость нормальная, втыкаю этот винт в другую мамку — скорость тоже Ok. Значит с OS — все пучком (Linux все таки), с контроллером — все пучком, предполагаю, что проблема в HDD firmware — как-то оно видать не так реагирует на этот SATA контроллер (диск — SATA-III, контроллер — SATA-II, вдруг чего не учли). Пишу в службу поддержки Hitachi, все-таки они специалисты, как минимум помогут разобраться — где же порылась собака. Так как в нашем европейском Гондурасе их представительства нету, отвечает мне перец из UK support, некто Niko Levenetz. А пишет он следующее :

«We as the drive manufacturer cannot ensure compatibility
of our drives with all third-party products in the market
.

Most server manufacturers like Dell for instance will use our drives
with their own firmware to ensure full compatibility and performance
with their product. They will test and provide information on compatibility
and if the drives have not been sold with the server, it is the buyers
responbility to make sure PRIOR to purchase that the drives are
approved and compatible with the controllers.

Please contact your server manfufacturer to inquire about
specific firmware for these drives (go by P/N).»

Явно видно, что мужика сняли вчера с какой-то пальмы, так как он сходу заявляет, что мол не только они пишут firmware для своих винтов (видимо branding and writing для него одно и тоже), и поэтому нужно сразу бежать и спрашивать с производителя материнки/сервера — вдруг он написал свое firmware для ихнего супер-пупер охеренного винта (блин а что же делать если все-таки не написал ?)  Но самое тупое в его логике другое — оказывается я, как покупатель,  перед покупкой их винтов (PRIOR to purchase) должен сам убедится (наверное применив какие-то, одному его племени известные, эктрасенсорные способности), что их диск совместим с моим оборудованием, несмотря на то, что письмо он сам безапелляционно начинает с заявления, что даже они не могут этого знать - «we as the drive manufacturer cannot ensure compatibility of our drives with all third-party products in the market». Ну и конечно вывод из своего бреда он делает простой и удобный для себя: если их винт по какой-либо причине глючит или не работает — так однозначно обо#рался тот, кто его купил, а совсем не тот, кто его сделал — «it is the buyers responbility».
Во-первых — я сдам все эти винты нахрен. Во-вторых — я больше никогда не куплю ни одного продукта фирмы Hitachi. И совсем не потому, что они не работают, а потому что в их фирме и в частности в саппорте сидят такие долбо#бы как Niko Levenetz и его прямое начальство. Если девайс не работает — это всегда можно исправить/починить/пропатчить. Но если фирме и людям в ней работающим откровенно нас#рать на своих пользователей/клиентов — то это уже неисправимо.

Fuck you Hitachi !

Fuck you Hitachi !

P.S. А проблема с этими долбаными винтами оказалась действительно неустранимой — выяснилось что катастрофическим понижением скорости записи до 700 кбайт/сек они реагируют на вибрацию от (!) вентиляторов. Писец …

Rigol DS1052D -> DS1102D (fw 3.0.1)

28 Июль, 13:44, by Rus Метки:

Для грядущих экспериментов было принято решение разжиться дешевым осциллом. Так как все они делаются в одной китайской деревне, то выбор пал на наиболее изученный в интернетах — DS1052E. Глянув на не шибко большую разницу в цене между DS1052D, был куплен последний. Мечталось, что приедет он с паршивкой 2.x и можно будет без суеты заапгрейдить его до 100MHz. Китайцы оказались проворней и аппарат пришел с версией 3.0.1, о которой никто еще ничего не слышал. Ждать я не люблю, поэтому моментально было принято мудрое решение хакнуть его самостоятельно. Применен самый быстрый и безопасный способ — бэкап флешки, затем замена образа на старый (2.x), хак и затем апгрейд на новую версию. Тело было вскрыто и определена схема подключения флешки. Подключена она оказалась к DSP BF531 и Lattice FPGA. Вариантов ее чтения/прошивки два — первый написать свой загрузчик для BF531 и загрузить его через штатный BF531 SPI разьем и второй — через JTAG. Так как написать загрузчик возможно лишь при знании ассемблера для BF531 (плюс пришлось бы изучить текущую прошивку на предмет управления адресными линиями флешки, которые подключены к FPGA), то этот вариант отпал сразу, так как эти знания мне даром не нужны, а время все-таки не резиновое.  Внутри скопа есть 3 разьема JTAG: 1 для BF531, 2 для Lattice FPGA и 3 для Cyclone логического анализатора, который для хака нафиг не нужен. Т.е. нужно соединить в цепочку всего два чипа — BF531 и Lattice. Была быстренько спаяна на коленке переходка для JTAG кабеля (байтбластера) :

ByteBlaster          Blackfin JTAG            Lattice JTAG
TMS              —            TMS           —           TMS
TCK              —            TCK            —           TCK
TDI               —            TDI
                                     TDO           —            TDI
TDO             —————————            TDO
GND             —             GND         —            GND
VCC              —————————            VCC

Lattice JTAG pinout (слева направо если смотреть сзади осцилла) :

1 — TCK
2 — GND
3 — TMS
4 — TDI
5 — TDO
6 — VCC

Распиновка Blackfin JTAG см. на http://rigol.codenaschen.de/index.php/JTAG

Был скачен первый попавшийся в google JTAG программатор (TopJtag). Хоть в нем и заявлена поддержка моего любимого LPT Byteblaster’а, но работает он с ним откровенно хреново — во-первых какого-то рожна скорость ограничена 200kГц, во-вторых даже на этой тормознутой скорости он умудряется допускать ошибки при работе с LPT портом. Выглядит это как случайные щелкания реле в осцилле при чтении флехи, что говорит о том, что биты задвигаются с серьезными ошибками. Щелкать реле должно только один раз — в начале и/или в конце процедуры. Посему был взят USB Byteblaster, с которым вышеописанной проблемы нет, но тормоз он все равно еще тот — чтение флешки обьемом 8 Mбайт проистекало 140 минут ! Далее был произведен беглый анализ дампа флешки и по смещению 0x1ff440 обнаружены ASCII строки модели и серийника тела. А что, если просто поменять модель и серийник ? Ведь старый хак именно так и работает — подумано, значит сделано. Кстати, перезапись флешки происходит быстрее, так как можно перезаписывать только нужный сектор — в нашем случае это будет 0x1f0000-0x1fffff. Читаем сектор, патчим (DS1052D -> DS1102D и DS1EC… -> DS1EA…), стираем, пишем, верифицируем, power off/on cycle и … хрен вам а не 100Mhz, сказала пластмассовая китайская шелезяка ! Могучие кетайцi решили сделать еще одну, совершенно бесполезную попытку, помешать русским все иметь на халяву. Т.е. в новом 3.x firmware они решили кроме запрета downgrad’а еще и залочить серийник. Так как исследовать как именно они это сделали не было никакого желания, то были тупо произведены сравнения дампа флехи и образа апгрейда — выяснено, что 0-0×15 в RGL это заголовок, с 0×15 до первых нулей — это «первая часть» и с 0×200000 до упора это «вторая часть». Затерев первой частью с 0 в дампе и второй частью с 0×400000 в дампе мы получим рабочий образ с нужной версией. Делаем для 2.02, шьем, перегружаемся — зашибись. Хачим, как обычно — :INFO:MODEL/:INFO:SERIAL — получаем 2ns в 2.02. Далее апгрейдим до 2.5 и потом до 3.01. Все в принципе круто, за исключением того что HardVersion у меня получилась пустой, кажись я кое-где промахнулся, где бы это …

Окончание следует …

[1] Файл проекта для TopJtag Programmer
[2] BSDL файл для BF531
[3] BSDL файл для Lattice

Asus, Bulldozer, Linux и грабли

11 Июль, 04:44, by Rus Метки: , , ,

Прикольно когда накладывается сразу три технических проблемы на ровном месте, например при попытке взять Asus M5A97 Pro и попытаться поставить на нее AMD FX-8150 и Linux. Вообще с этой мамкой что-то не так — наблюдаются артефакты и спецэффекты даже после проделанных ниже манипуляций [ потрескивание динамика при ping -f это что-то ;) ]. Стоит 7 раз подумать прежде чем ее юзать, да еще вкупе с бульдозером — есть SaberTooth, которая свободна от всех недостатков M5A97. Тем не менее ее можно заставить как-то работать, но для этого нужно немного магии или много пива. Ниже приведена пошаговая магия, так как пива уже нет :

1. Шьем последний BIOS (1208), перезагружаемся, заходим в Setup

2. Включаем IOMMU — иначе отгребете еще больше левых багов. Также не пытаемся включать несколько настроек в BIOS за раз — в этой мамке (спасибо BIOS’о-писателям) это приведет к еще более странным глюкам. Т.е. поменяли одну настройку, сохранили, перезагрузились.

3. Выключаем Turbo Core, дабы не склеил ласты или не начал сбоить хилый источник питания матери, который явно рассчитан на работу в режиме 140W только в условиях суровых сибирских зим.

4. По той же причине включаем Extreme EPU mode и выключаем EPU Power Saving mode

5. Ставим как минимум 3.5-rc5 ядро, так как во-первых избавимся от страшных надписей «[Firmware Bug]: cpu 7, IBS interrupt offset 0 not available» при теплых перезагрузках, а во-вторых перестанет намертво отваливаться сеть с не менее страшными надписями  «AMD-Vi: Event logged [IO_PAGE_FAULT device=06:00.0 domain=0x001 address=0x00000000009cd000 flags=0x0050]«, «NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out» и совершенно левыми надписями «r8169 0000:06:00.0: eth0: link up» при железно подключенном кабеле сети.

6. Тестируем все это дело MemTest’ом, iperf’ом и ложимся спать, так как местами уже 5 утра ;)

Рай или забвение

15 Апрель, 03:15, by Rus Метки: , ,

Как говорил один чудак — «с нашей планетой все в порядке, за 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, обзор продукта

Масштабируемость, 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

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

Asus EEE Pad Transformer

12 Август, 05:48, by Rus Метки: , , , , ,

Идеальный аппарат для 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, но то ли у нас не ту страну назвали Гондурасом, то ли еще чего  …

HDD в 3TB и сражение длиной в weekend

09 Апрель, 09:08, by Rus Метки: , , , , , ,

В процессе апгрейда с 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 уже давно ждут своего часа …