Вышел (http://groups.google.com/group/orient-database/browse_thread...) первый релиз OrientDB (http://code.google.com/p/orient/), системы управления базами данных, которая объединяет в себе возможности документо-ориентированной и графо-ориентированной БД. Дополнительно поддерживается интерфейс объектно-ориентированной БД, который работает поверх документо-ориентированного слоя. Код OrientDB написан на языке Java и распространяется под лицензией Apache. На обычном оборудовании OrientDB позволяет сохранять 150 000 записей в секунду. При тестировании производительности один сервер с OrientDB оказался способен заменить собой 125 серверов MySQL.<center><a href="http://www.orientdb.org/images/graphed-tutorial-graph_small.... src="http://www.opennet.me/opennews/pics_base/0_1337073594.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
Основные особенности:
- Полная поддержка ACID транзакций;
- Поддержка SQL-запросов;
- 100% совместима со стандартом TinkerPop Blueprints для графо-ориентированных БД;
- Нативно поддерживает HTTP, RESTful и JSON протоколы без использования сторонних компонентов;
- Возможность работы как в режиме встраивания в другие приложения, так и в качестве выделенного сервера;
- Имеет очень малый размер и не имеет сторонних зависимостей;
- Дистрибутив полностью самодостаточен;
- Поддерживает отказоустойчивые конфигурации и репликацию (архитектура OrientDB изначально рассчитана на мультимастер репликацию);- Поддержка запуска скриптов на стороне сервера (Server Side Scripting);
- Доступна коммерческая поддержка.URL: http://groups.google.com/group/orient-database/browse_thread...
Новость: http://www.opennet.me/opennews/art.shtml?num=33847
Скриншот, прямо таки, завораживает...
Угу, а при замене жавы на С(++) можно будет заменить одним сервером 125 жаватормозил.
Скорее, 500 MySQL сервером. Ну чтоб покруче выглядело :)
Замена 500 MySQL серверов - это киллер-фича следующего релиза
Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.В яве multithreading лучше, и JITовые оптимизации толковые. Реально тормозов там мало - GC самый существенный, остальное несущественно. Так что берём много памяти и не жужжим :)
> Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.Когда нечем крыть, ничего не остаётся кроме как закрыть уши руками и говорить "бла-бла-бла".
> В яве multithreading лучше
Лучше? Это как? На сколько процентов? Конкретнее.
> и JITовые оптимизации толковые
Давайте по пунктам.
> Реально тормозов там мало - GC самый существенный
Одного только GC хватает с головой.
> Так что берём много памяти и не жужжим :)
С этого и надо было начинать :) Берём много памяти, много серверов, и оно работает хоть как-то сравнимо с C++ на одной древней машинке.
Вы бы, в общем, не позорились со своими представлениями о java на уровне теоретических россказней про "jit оптимизации". Я java решений навидался уже - когда на C++ в память сервера влезает весь workset, жава только сама выжирает половину.
>> В яве multithreading лучше
> Лучше? Это как? На сколько процентов? Конкретнее.Лучше - это значит работает. Тк JVM рассчитана на multithreading-окружение, а C++ ничего про потоки не знает. Поэтому в C++ (< C++XX) double-checked locking невозможен, и невозможны lockless-алгоритмы. А в java - пожалуйста, и high-perfomance примеров этого достаточно (Disruptor, Fork/Join API (JDK 7)). Про проценты - померяйте C++-ную многопоточную очередь и сравните с Fork/Join из JDK 7.
>> и JITовые оптимизации толковые
> Давайте по пунктам."In brief, HotSpot can and will:
Inline methods
Join adjacent synchronized blocks on the same object
Eliminate locks if monitor is not reachable from other threads
Eliminate dead code (hence most of micro-benchmarks are senseless)
Drop memory write for non-volatile variables
Replace interface calls with direct method calls for methods only implemented once
....." гугл давно закрыли?>> Реально тормозов там мало - GC самый существенный
> Одного только GC хватает с головой.
>> Так что берём много памяти и не жужжим :)
> С этого и надо было начинать :) Берём много памяти, много серверов,
> и оно работает хоть как-то сравнимо с C++ на одной древней
> машинке.Оюшки. Про много серверов вы сами додумали.
> Вы бы, в общем, не позорились со своими представлениями о java на
> уровне теоретических россказней про "jit оптимизации". Я java решений навидался уже
> - когда на C++ в память сервера влезает весь workset, жава
> только сама выжирает половину.Так и скажите, что вам жалко памяти. Вы или платите за плюсы платформы доп/памятью, или жужжите на С++.
Я не говорю, что С++ говно - у него безусловно есть свои сферы применения, и кстати я бы не сказал, что сильно пересекающиеся с явой, но запросто поливать её грязью - это надо её сильно ненавидеть.
> Fork/Join API (JDK 7))Вот это даа! Сорок лет спустя они осилили unixway.
Просвещайся: http://www.rsdn.ru/forum/philosophy/2840588.1.aspx
> Поэтому в C++ (< C++XX) double-checked locking невозможен, и невозможны lockless-алгоритмы.обалдеть. я великий маг и волшебник, я использую lock-free в c++. и stm (shared transactional memory). а это, оказывается, невозможно. вот жеж блин, чего мне сразу-то никто не сказал, что невозможно? я бы и не пробовал даже!
А без gcc(msvc/вставить нужное)-dependent фич сможете?Невозможно в рамках языка. Потому что на уровне языка не определена видимость переменных в разных потоках. Жду вашего решения...
> А без gcc(msvc/вставить нужное)-dependent фич сможете?будет медленней, но, кажется, возможно. сейчас не готов ответить точно.
> Потому что на уровне языка не определена видимость переменных в разных потоках.
что совершенно неважно, важно наличие атомарных операций. на одном камне — однозначно можно, ибо операции с интами атомные. на SMP — сложнее, придётся воротить черезанусные псевдосинхронизации.
более конктретного ответа не дам, потому что голова болит. %-) но почти уверен, что ответ положительный.
> Невозможно в рамках языка. Потому что на уровне языка не определена видимость переменных в разных потоках. Жду вашего решения...боже мой.. какие же бывают тупые люди
>> Невозможно в рамках языка. Потому что на уровне языка не определена видимость переменных в разных потоках. Жду вашего решения...
> боже мой.. какие же бывают тупые людиВаще ни о чем. Проясните глубину мысли?
А зачем? GCC есть чуть ли не под все мыслимые платформы. Готовый стандарт де-факто.
> Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так
> и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.А чего там слышать? Достаточно посмотреть на бенчмарки одних и тех же алгоритмов и просто как жабисты вечно с профайлингом долбутся, с поводом и без.
>> Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так
>> и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.
> А чего там слышать? Достаточно посмотреть на бенчмарки одних и тех же
> алгоритмов и просто как жабисты вечно с профайлингом долбутся, с поводом
> и без.Одааа, с С++ники сразу пишут идеальный с точки зрения перфоманса код. И без утечек. Смешно...
У них запас для косяков гораздо бОльший
Вам бы ещё по ссылкам ходить. Ребята давно этим занимаются. Была реализация на C++. Потом всё переписали на Java.P.S.
И кстати, реляционная h2db на Java, таки быстрее PostgreSQL и MySQL http://www.h2database.com/html/performance.html
"Please note this is mostly a single connection benchmark run on one computer."
"Version 5.1.47-community was used for the test."
"This test is run on Mac OS X 10.6. No virus scanner was used"Размер тестируемой базы не указан.
Овечье дерьмо цена таким тестам.
> И кстати, реляционная h2db на Java, таки быстрее PostgreSQL и MySQLНе, ну а функционал постгра или хотя-бы мускуля оно обеспечивает? А то жабисты вечно сравнивают теплое с мягким. А вот почему-то одинаковые реализации алгоритмов - тупят раза в три. На яве понятный хрен.
>> И кстати, реляционная h2db на Java, таки быстрее PostgreSQL и MySQL
> Не, ну а функционал постгра или хотя-бы мускуля оно обеспечивает? А то
> жабисты вечно сравнивают теплое с мягким. А вот почему-то одинаковые реализации
> алгоритмов - тупят раза в три. На яве понятный хрен.Наверное потому, что пхпешники считают что на жаве нужно писать драйвера а на сях сайты, не?
Ага, вот Вы и займитесь. Постепенно, я надеюсь, вы поймёте почему разработчики выбрали жаву.
К сожалению ява..
Все такие богатые что ли.
Что интересно понимается под обычным оборудованием... :-)
Это что надо сделать с мускулом, чтобы жаватормозила смогла заменить аж 125 мускулов ...
Написать идиотских кривых запросов и никогда не использовать EXPLAIN.
например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.100k+ и acid на "обычном" железе это забавно, fsync не делают? или коммит длится несколько секунд?
> например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.Именно!
Дело не в Java, а в NoSQL.neo4j ищет всех друзей за 2 микросекунды, а на MySQL это занимает 2 секунды. Есть разница? При этом были тесты, в которых OrientDB в графовых задачах обходила neo4j. При этом OrientDB не просто графо-ориентированная БД.
>> например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.
> Именно!
> Дело не в Java, а в NoSQL.
> neo4j ищет всех друзей за 2 микросекунды, а на MySQL это занимает
> 2 секунды. Есть разница? При этом были тесты, в которых OrientDB
> в графовых задачах обходила neo4j. При этом OrientDB не просто графо-ориентированная
> БД.Согласен есть разница. В реалиоционных БД, есть такой термин, как денормализация, который как раз и предназначен для решения подобных проблем.
Денормализация не даёт общего решения подобных проблем. В частности, для предложенной задачи ( поиск друзей N-го уровня ) сложность решения, имхо, растёт по экспоненте.
Простите, у вас образование есть ?В современном железе нет проблем с производительностью процессора, а есть проблемы с производительностью дисковой подсистемы. В этом случае решают лишь алгоритмы.
>В современном железе нет проблем с производительностью процессораВы недооцениваете способности современных Джава(и не только джава, но в первую очередь джава) кодеров.
Образование и опыт работы есть если что. Прощаю за того парня.
> Простите, у вас образование есть ?Прощаю, есть :-)
> В современном железе нет проблем с производительностью процессора, а есть проблемы с производительностью дисковой подсистемы. В этом случае решают лишь алгоритмы.
Вы сами это написали. Из привиденных чисел становится понятно, что с дисковой подсистемой они и на мутили (а может смухлевали и диском вообще не пользовались в указанных тестах, либо fsync не вызывают, да мало ли чего еще). Если в MySQL использовать движок, хранящий данные в памяти, то там тоже производительность дикая.
> Простите, у вас образование есть ?
> В современном железе нет проблем с производительностью процессора, а есть проблемы с
> производительностью дисковой подсистемы. В этом случае решают лишь алгоритмы.Да, и у конкретно Джавы помимо дисковой подсистемы есть другие места, где она дико тормозит. Проблема пожалуй не в железе, а в платформе. Ну совсем не верится, что на тормозной платформе можно сделать нечто, что дают нормальную производительность.
Уважаемый!
Дело не в платформе, как здесь уже отметили, а в отличии чисто реляционных БД и NoSQL. Сейчас есть тенденция использовать реляционные БД повсеместно. На это есть свои объективные причины. Однако в последнее время накопилось множество задач, которые решают при помощи SQL, но с дикими компромиссами в плане эффективности.Грубо говоря, ради чего пихать объект(или JSON или ещё чего) в SQL-базу, когда можно выкинуть весь ненужный слой SQL и получить увеличение производительности на порядки.
Я уже писал, что ребята из проекта OrientDB писали БД на C++. Могли бы вообще на голом C или ассемблере (Oracle 2 была чисто на нём). Потом они решили, что это не существенно. MongoDB на С++, OrientDB на Java и обе они по производительности обходят SQL БД на порядки.
> При тестировании производительности, один сервер с OrientDB оказался способен заменить собой 125 серверов MySQLКруто.
Ладно, жабу как-нибудь перетерпим, теребит другой вопрос: уже существующие NoSQL базы - в них что, нельзя получить зависимые документы? Мне эти "графы" пофиг, у меня просто есть "Документ"->"Ордер". Какое преимущество мне дадут графы?
Вообще у OrientDB есть уровень Ключ-значение. Поверх него реализован документный уровень. Поверх документного реализованы граф-уровень и объектный уровень.
Т.о. можете графы вообще не использовать, а сохранять просто документы.
Из Java же можно объекты аннотированных классов напрямую сохранять.
"Initial revision" проекта датирована 1 апреля 2010 :)
Извините за оффтоп.
а есть живые графо-ориентированной БД на C/C++ ?
В тексте новости есть похожая ссылка на Википедию: http://en.wikipedia.org/wiki/Graph_database#Graph_database_p...
Интересно сравнить с другими граф-ориентированными базами.
Феерично... "Имеет очень малый размер и не имеет сторонних зависимостей;" - и притом написана на джаве - никаких сторонних зависимостей, ага. Кроме маркетинга этим "разработчикам" стоило бы еще и программированием заниматься :D
Ну, тогда почти у всего ПО есть зависимости - API OS.
И это ещё не зашла речь про железо! ))
Любезный, не путайте платформу, как таковую, и зависимости от сторонних библиотек.
Крутая штука!
Кто в каких задачах использовал подобные БД? С какими отрицательными/узкими/проблемными местами сталкивались?
Вообщето ява по скорости проигрывает только С++ и то, процентов 30-50, на хабре была статья с графиками 10 языков. Остальные языки, особенно интерпретируемые отстают от С++ уже в разы или даже десятки раз.
А в некоторых алгоритмах скорость явы практически равна С++С таким же успехом как вы про тормознутость явы, я могу заливать про дырявость С++ программ, утечки памяти, необходимость вручную выделять и удалять память, медленность разработки и т.д.
тут как бы нужно смотреть не только проигрыш на небольших интервалах времени, но и особенности GC, которые часто выливаются в большие "магические" грабли. Это примерно как запустить проект написанный на ЯП с динамической типизацией, поставить его поработать на пару часиков, убедиться что всё ок. А потом, через несколько дней, обнаружить косяки в коде до которого выполнение ещё не доходило начальные часы.
И всё было бы классно если бы не Ява. К языку претензий не имею, но вот к ее владельцам - еще как. Завтра корпорации бобра взбредет в голову какая то бяка - и вперед за покупками. И даже OpenJDK не сильно спасет.
> И всё было бы классно если бы не Ява. К языку претензий
> не имею, но вот к ее владельцам - еще как. Завтра
> корпорации бобра взбредет в голову какая то бяка - и вперед
> за покупками. И даже OpenJDK не сильно спасет.Тысячи компаний по всему миру сидят на яве и не думают переходить. Да и некуда. А у вас видите ли подозрения
это из области "тысячи мух не могут ошибаться"
Тогда уже скорее "миллионы мух обречены на правильный выбор" :-))
"...на обычном оборудовании позволяя сохранять до 150 000 записей в секунду" мягко говоря это неправда, ибо физически невозможно, а по сути наглый пизде$$$...
Интересное утверждение.
Физически невозможно - это записать за секунду на диск данных больше, чем позволяет пропускная способность диска.Где вы видите информацию о размере записи ???
Современные HDD даже на ноутбуке позволяют записывать порядка 100 Мб/сек. SSD так ещё больше.В данном случае размер данных не важен, ибо это будет тест дисковой подсистемы. Количество сохранённых мелких записей позволяет судить об эффективности алгоритма. При этом утилизировать даже всего 100 Мб/сек обычного диска представляется весьма сложной задачей. Достаточно чтобы размер был менее килобайта.
RB+Tree позволяет быстро читать и при этом быстро записывать.
>[оверквотинг удален]
> Физически невозможно - это записать за секунду на диск данных больше, чем
> позволяет пропускная способность диска.
> Где вы видите информацию о размере записи ???
> Современные HDD даже на ноутбуке позволяют записывать порядка 100 Мб/сек. SSD так
> ещё больше.
> В данном случае размер данных не важен, ибо это будет тест дисковой
> подсистемы. Количество сохранённых мелких записей позволяет судить об эффективности алгоритма.
> При этом утилизировать даже всего 100 Мб/сек обычного диска представляется весьма
> сложной задачей. Достаточно чтобы размер был менее килобайта.
> RB+Tree позволяет быстро читать и при этом быстро записывать.Что же вы ерундой то болтаете???
Запустите скрипт на генерацию 150000 файлов объем каждого ~20 байт.
И скажите сколько МИНУТ он выполняется на обычном железе?#!/bin/bash
mkdir data
COUNTER=0
START=`date +%s`while [ $COUNTER -lt 150000 ]; do
echo The counter is $COUNTER > data/$COUNTER.txt
let COUNTER=COUNTER+1
doneEND=`date +%s`
RES=0;
let RES=END-START
echo $RES
Ты забыл про файловую систему, которая мало того что пишет файлы блоками большего размера чем сам файл, так еще и таблицу с индексами создает.
Обязательно попробую.В OrientDB есть понятие кластера. Кластер - это, грубо говоря, предварительно созданный файл обычно небольшого размера. Когда пишутся новые записи, то они редко требуют выделения нового места на ФС. Также для каждого кластера есть другой специальный кластер для удалённых записей. В него заносятся пометка о том, что такая-то запись удалена. Т.о. непосредственное добавление или удаление одной записи не приводит в выделению места на ФС.
А вот хороший алгоритм нужен для быстрого нахождения требуемого адреса внутри кластера. И такой алгоритм есть и он работает.
$ cat write-test.c
#include <stdio.h>#define RECORDS_COUNT 150000
int main(){
FILE *fp;
if((fp = fopen("records", "w")) != NULL){
unsigned char c = 0;
long int i;
for(i=0; i < RECORDS_COUNT; i++){ //пишем 150 000 записей в файл
fputc(c++, fp); //пишем запись из одного символа
}
fclose(fp);
return 0;
}else{
printf("Can't open file");
return 1;
}
}
$ cc -o write-test write-test.c
$ time ./write-test
./write-test 0.00s user 0.00s system 82% cpu 0.006 totalУМВР. ЧЯДНТ?
1) MySQL тратит ресурсы на проверку пользователя при соединении.
2) Больше времени уходит на сортировку данных, а не взятие их из БД, в мускуле тоже есть NoSQL.
И про 125 серверов однозначна пиздеж.
Кто-то ее пробовал для 1С-ки ?Как сумеете прикрутить, отпишитесь плизз тут. Интересен результат.
"Кто в каких задачах использовал подобные БД? С какими отрицательными/узкими/проблемными местами сталкивались?"
Все проигнорировали товарища, который спрашивал для чего кто использует...
Значит ли это, что никто из "здешних" их не использует?