The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Первый релиз NoSQL БД OrientDB

15.05.2012 12:33

Вышел первый релиз OrientDB, системы управления базами данных, которая объединяет в себе возможности документо-ориентированной и графо-ориентированной БД. Даже при работы с документ-ориентированными данными взаимодействие между документами обрабатывается как в графо-ориентированной БД с определением прямых связей между записями. При этом пройти по цепочке содержимого деревьев и графов, как целиком так и частями, можно в считанные миллисекунды. Дополнительно поддерживается интерфейс объектно-ориентированной БД, который работает поверх документо-ориентированного слоя. Код OrientDB написан на языке Java и распространяется под лицензией Apache.

OrientDB отличается высокой скоростью работы, на обычном оборудовании позволяя сохранять до 150 000 записей в секунду. При тестировании производительности, один сервер с OrientDB оказался способен заменить собой 125 серверов MySQL. Распределённая сеть серверов способна обеспечить хранение до 9.223.372.036 миллиардов записей и 19.807.040.628.566.084 Тб данных. Оперирующий запросами ключ/значение кластер OrientDB может состоять из тысяч узлов, используя для организации единого хранилища алгоритм распределённой хэш-таблицы (DHT). Для непосредственного хранения данных используется собственный алгоритм RB+Tree, сочетающий в себе особенности Red-Black Tree и B+Tree, что позволяет добиться вдвое меньшего потребления памяти при сохранении скорости Red-Black Tree за счёт балансировки операций добавления и обновления данных.

Основные особенности:

  • Полная поддержка ACID транзакций;
  • Поддержка подмножества языка SQL для выполнения запросов c использованием конструкции SELECT (OrientDB не является реляционной БД, поэтому в полной мере все возможности SQL не поддерживает);
  • Поддержка хранения данных без описания предварительной схемы, с описанием полной структуры или в смешанном режиме;
  • 100% совместима со стандартом TinkerPop Blueprints для графо-ориентированных БД;
  • Поддержка языка запросов Gremlin;
  • Нативно поддерживает HTTP, RESTful и JSON протоколы без использования сторонних компонентов;
  • Возможность работы как в режиме встраивания в другие приложения, так и в качестве выделенного сервера;
  • Возможность отката внесённых в документ локальных изменений (ODocument.undo);
  • Имеет очень малый размер и не имеет сторонних зависимостей;
  • Поддерживается строгая политика разграничения доступа на основе ролей и полномочий пользователей;
  • Дистрибутив полностью самодостаточен;
  • Поддерживает отказоустойчивые конфигурации и репликацию (архитектура OrientDB изначально рассчитана на мультимастер репликацию);
  • Поддержка запуска скриптов на стороне сервера (Server Side Scripting);
  • Доступна коммерческая поддержка.


  1. Главная ссылка к новости (http://groups.google.com/group...)
Автор новости: Yarick
Тип: Программы
Короткая ссылка: https://opennet.ru/33847-orientdb
Ключевые слова: orientdb, database, nosql, graph
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (63) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Тузя (ok), 13:38, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Скриншот, прямо таки, завораживает...
     
  • 1.2, Аноним (-), 13:40, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Угу, а при замене жавы на С(++) можно будет заменить одним сервером 125 жаватормозил.
     
     
  • 2.5, Аноним (-), 14:09, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скорее, 500 MySQL сервером. Ну чтоб покруче выглядело :)
     
     
  • 3.8, Proud Anon (?), 14:22, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Замена 500 MySQL серверов - это киллер-фича следующего релиза
     
  • 2.11, thelamon (ok), 15:13, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.

    В яве multithreading лучше, и JITовые оптимизации толковые. Реально тормозов там мало - GC самый существенный, остальное несущественно. Так что берём много памяти и не жужжим :)

     
     
  • 3.16, Аноним (-), 15:47, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Когда нечем крыть, ничего не остаётся кроме как закрыть уши руками и говорить б... большой текст свёрнут, показать
     
     
  • 4.26, thelamon (ok), 17:54, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> В яве 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, жава
    > только сама выжирает половину.

    Так и скажите, что вам жалко памяти. Вы или платите за плюсы платформы доп/памятью, или жужжите на С++.

    Я не говорю, что С++ говно - у него безусловно есть свои сферы применения, и кстати я бы не сказал, что сильно пересекающиеся с явой, но запросто поливать её грязью - это надо её сильно ненавидеть.

     
     
  • 5.32, MacMan (?), 20:16, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/

    > Fork/Join API (JDK 7))

    Вот это даа! Сорок лет спустя они осилили unixway.

     
     
  • 6.33, Nope (?), 20:29, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Просвещайся: http://www.rsdn.ru/forum/philosophy/2840588.1.aspx
     
  • 5.37, arisu (ok), 22:55, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Поэтому в C++ (< C++XX) double-checked locking невозможен, и невозможны lockless-алгоритмы.

    обалдеть. я великий маг и волшебник, я использую lock-free в c++. и stm (shared transactional memory). а это, оказывается, невозможно. вот жеж блин, чего мне сразу-то никто не сказал, что невозможно? я бы и не пробовал даже!

     
     
  • 6.39, thelamon (ok), 23:10, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А без gcc(msvc/вставить нужное)-dependent фич сможете?

    Невозможно в рамках языка. Потому что на уровне языка не определена видимость переменных в разных потоках. Жду вашего решения...

     
     
  • 7.40, arisu (ok), 23:24, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А без gcc(msvc/вставить нужное)-dependent фич сможете?

    будет медленней, но, кажется, возможно. сейчас не готов ответить точно.

    > Потому что на уровне языка не определена видимость переменных в разных потоках.

    что совершенно неважно, важно наличие атомарных операций. на одном камне — однозначно можно, ибо операции с интами атомные. на SMP — сложнее, придётся воротить черезанусные псевдосинхронизации.

    более конктретного ответа не дам, потому что голова болит. %-) но почти уверен, что ответ положительный.

     
  • 7.41, Аноним (-), 23:32, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Невозможно в рамках языка. Потому что на уровне языка не определена видимость переменных в разных потоках. Жду вашего решения...

    боже мой.. какие же бывают тупые люди

     
     
  • 8.42, thelamon (ok), 23:34, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ваще ни о чем Проясните глубину мысли ... текст свёрнут, показать
     
  • 7.44, Crazy Alex (ok), 23:47, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем? GCC есть чуть ли не под все мыслимые платформы. Готовый стандарт де-факто.
     
  • 3.24, Аноним (-), 17:27, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так
    > и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.

    А чего там слышать? Достаточно посмотреть на бенчмарки одних и тех же алгоритмов и просто как жабисты вечно с профайлингом долбутся, с поводом и без.

     
     
  • 4.27, thelamon (ok), 17:55, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так
    >> и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.
    > А чего там слышать? Достаточно посмотреть на бенчмарки одних и тех же
    > алгоритмов и просто как жабисты вечно с профайлингом долбутся, с поводом
    > и без.

    Одааа, с С++ники сразу пишут идеальный с точки зрения перфоманса код. И без утечек. Смешно...

     
     
  • 5.45, Аноним (-), 00:06, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У  них запас для косяков гораздо бОльший
     
  • 2.13, ДяДя (?), 15:35, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вам бы ещё по ссылкам ходить. Ребята давно этим занимаются. Была реализация на C++. Потом всё переписали на Java.

    P.S.
    И кстати, реляционная h2db на Java, таки быстрее PostgreSQL и MySQL http://www.h2database.com/html/performance.html

     
     
  • 3.23, ыгчч (?), 16:31, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    "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"

    Размер тестируемой базы не указан.

    Овечье дерьмо цена таким тестам.

     
  • 3.25, Аноним (-), 17:28, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И кстати, реляционная h2db на Java, таки быстрее PostgreSQL и MySQL

    Не, ну а функционал постгра или хотя-бы мускуля оно обеспечивает? А то жабисты вечно сравнивают теплое с мягким. А вот почему-то одинаковые реализации алгоритмов - тупят раза в три. На яве понятный хрен.

     
     
  • 4.29, Аноним (29), 18:58, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> И кстати, реляционная h2db на Java, таки быстрее PostgreSQL и MySQL
    > Не, ну а функционал постгра или хотя-бы мускуля оно обеспечивает? А то
    > жабисты вечно сравнивают теплое с мягким. А вот почему-то одинаковые реализации
    > алгоритмов - тупят раза в три. На яве понятный хрен.

    Наверное потому, что пхпешники считают что на жаве нужно писать драйвера а на сях сайты, не?

     
  • 2.28, Аноним (29), 18:44, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, вот Вы и займитесь. Постепенно, я надеюсь, вы поймёте почему разработчики выбрали жаву.
     

  • 1.3, o (?), 13:43, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    К сожалению ява..
    Все такие богатые что ли.
     
  • 1.4, MaMoHT (?), 14:01, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Что интересно понимается под обычным оборудованием... :-)
    Это что надо сделать с мускулом, чтобы жаватормозила смогла заменить аж 125 мускулов ...
     
     
  • 2.7, ыгчч (?), 14:19, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Написать идиотских кривых запросов и никогда не использовать EXPLAIN.
     
  • 2.9, anonymous (??), 14:53, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.

    100k+ и acid на "обычном" железе это забавно, fsync не делают? или коммит длится несколько секунд?

     
     
  • 3.17, Yarick (?), 15:56, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.

    Именно!
    Дело не в Java, а в NoSQL.

    neo4j ищет всех друзей за 2 микросекунды, а на MySQL это занимает 2 секунды. Есть разница? При этом были тесты, в которых OrientDB в графовых задачах обходила neo4j. При этом OrientDB не просто графо-ориентированная БД.

     
     
  • 4.49, MaMoHT (?), 04:26, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.
    > Именно!
    > Дело не в Java, а в NoSQL.
    > neo4j ищет всех друзей за 2 микросекунды, а на MySQL это занимает
    > 2 секунды. Есть разница? При этом были тесты, в которых OrientDB
    > в графовых задачах обходила neo4j. При этом OrientDB не просто графо-ориентированная
    > БД.

    Согласен есть разница. В реалиоционных БД, есть такой термин, как денормализация, который как раз и предназначен для решения подобных проблем.

     
     
  • 5.55, Tameo (?), 11:53, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Денормализация не даёт общего решения подобных проблем. В частности, для предложенной задачи ( поиск друзей N-го уровня ) сложность решения, имхо, растёт по экспоненте.
     
  • 2.14, ДяДя (?), 15:44, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Простите, у вас образование есть ?

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

     
     
  • 3.35, filosofem (ok), 21:59, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >В современном железе нет проблем с производительностью процессора

    Вы недооцениваете способности современных Джава(и не только джава, но в первую очередь джава) кодеров.
    Образование и опыт работы есть если что. Прощаю за того парня.

     
  • 3.47, MaMoHT (?), 04:23, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Простите, у вас образование есть ?

    Прощаю, есть :-)

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

    Вы сами это написали. Из привиденных чисел становится понятно, что с дисковой подсистемой они и на мутили (а может смухлевали и диском вообще не пользовались в указанных тестах, либо fsync не вызывают, да мало ли чего еще). Если в MySQL использовать движок, хранящий данные в памяти, то там тоже производительность дикая.

      

     
  • 3.48, MaMoHT (?), 04:25, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Простите, у вас образование есть ?
    > В современном железе нет проблем с производительностью процессора, а есть проблемы с
    > производительностью дисковой подсистемы. В этом случае решают лишь алгоритмы.

    Да, и у конкретно Джавы помимо дисковой подсистемы есть другие места, где она дико тормозит. Проблема пожалуй не в железе, а в платформе. Ну совсем не верится, что на тормозной платформе можно сделать нечто, что дают нормальную производительность.

     
     
  • 4.57, ДяДя (?), 12:44, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уважаемый!
    Дело не в платформе, как здесь уже отметили, а в отличии чисто реляционных БД и NoSQL. Сейчас есть тенденция использовать реляционные БД повсеместно. На это есть свои объективные причины. Однако в последнее время накопилось множество задач, которые решают при помощи SQL, но с дикими компромиссами в плане эффективности.

    Грубо говоря, ради чего пихать объект(или JSON или ещё чего) в SQL-базу, когда можно выкинуть весь ненужный слой SQL и получить увеличение производительности на порядки.

    Я уже писал, что ребята из проекта OrientDB писали БД на C++. Могли бы вообще на голом C или ассемблере (Oracle 2 была чисто на нём). Потом они решили, что это не существенно. MongoDB на С++, OrientDB на Java и обе они по производительности обходят SQL БД на порядки.

     

  • 1.6, Аноним (6), 14:11, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > При тестировании производительности, один сервер с OrientDB оказался способен заменить собой 125 серверов MySQL

    Круто.

     
  • 1.15, Kodirr (?), 15:45, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ладно, жабу как-нибудь перетерпим, теребит другой вопрос: уже существующие NoSQL базы - в них что, нельзя получить зависимые документы? Мне эти "графы" пофиг, у меня просто есть "Документ"->"Ордер". Какое преимущество мне дадут графы?
     
     
  • 2.19, Yarick (?), 16:06, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще у OrientDB есть уровень Ключ-значение. Поверх него реализован документный уровень. Поверх документного реализованы граф-уровень и объектный уровень.
    Т.о. можете графы вообще не использовать, а сохранять просто документы.
    Из Java же можно объекты аннотированных классов напрямую сохранять.
     

  • 1.18, umbr (ok), 15:57, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Initial revision" проекта датирована 1 апреля 2010 :)
    Извините за оффтоп.
     
  • 1.20, taryk (ok), 16:07, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а есть живые графо-ориентированной БД на C/C++ ?
     
     
  • 2.21, umbr (ok), 16:09, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В тексте новости есть похожая ссылка на Википедию: http://en.wikipedia.org/wiki/Graph_database#Graph_database_projects
     

  • 1.22, aikus (?), 16:16, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно сравнить с другими граф-ориентированными базами.
     
  • 1.30, Veter (??), 18:58, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Феерично... "Имеет очень малый размер и не имеет сторонних зависимостей;" - и притом написана на джаве - никаких сторонних зависимостей, ага. Кроме маркетинга этим "разработчикам" стоило бы еще и программированием заниматься :D
     
     
  • 2.31, Человек (??), 19:49, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, тогда почти у всего ПО есть зависимости - API OS.
     
     
  • 3.34, Aleks Revo (ok), 21:04, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И это ещё не зашла речь про железо! ))
     
  • 2.43, grmmhnd (?), 23:45, 15/05/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Любезный, не путайте платформу, как таковую, и зависимости от сторонних библиотек.
     

  • 1.36, f (??), 22:46, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Крутая штука!
     
  • 1.50, mma (?), 05:31, 16/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто в каких задачах использовал подобные БД? С какими отрицательными/узкими/проблемными местами сталкивались?
     
  • 1.51, Аноним (51), 06:51, 16/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вообщето ява по скорости проигрывает только С++ и то, процентов 30-50, на хабре была статья с графиками 10 языков. Остальные языки, особенно интерпретируемые отстают от С++ уже в разы или даже десятки раз.
    А в некоторых алгоритмах скорость явы практически равна С++

    С таким же успехом как вы про тормознутость явы, я могу заливать про дырявость С++ программ, утечки памяти, необходимость вручную выделять и удалять память, медленность разработки и т.д.

     
     
  • 2.53, Аноним (-), 10:59, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    тут как бы нужно смотреть не только проигрыш на небольших интервалах времени, но и особенности GC, которые часто выливаются в большие "магические" грабли. Это примерно как запустить проект написанный на ЯП с динамической типизацией, поставить его поработать на пару часиков, убедиться что всё ок. А потом, через несколько дней, обнаружить косяки в коде до которого выполнение ещё не доходило начальные часы.
     

  • 1.52, hummermania (ok), 10:29, 16/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И всё было бы классно если бы не Ява. К языку претензий не имею, но вот к ее владельцам - еще как. Завтра корпорации бобра взбредет в голову какая то бяка - и вперед за покупками. И даже OpenJDK не сильно спасет.
     
     
  • 2.54, Аноним (51), 11:17, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И всё было бы классно если бы не Ява. К языку претензий
    > не имею, но вот к ее владельцам - еще как. Завтра
    > корпорации бобра взбредет в голову какая то бяка - и вперед
    > за покупками. И даже OpenJDK не сильно спасет.

    Тысячи компаний по всему миру сидят на яве и не думают переходить. Да и некуда. А у вас видите ли подозрения


     
     
  • 3.56, Гость (?), 12:19, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    это из области "тысячи мух не могут ошибаться"
     
     
  • 4.58, Aleks Revo (ok), 19:58, 16/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда уже скорее "миллионы мух обречены на правильный выбор" :-))
     

  • 1.61, JD (ok), 13:02, 17/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "...на обычном оборудовании позволяя сохранять до 150 000 записей в секунду" мягко говоря это неправда, ибо физически невозможно, а по сути наглый пизде$$$...
     
     
  • 2.62, Yarick (?), 11:44, 18/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Интересное утверждение.
    Физически невозможно - это записать за секунду на диск данных больше, чем позволяет пропускная способность диска.

    Где вы видите информацию о размере записи ???
    Современные HDD даже на ноутбуке позволяют записывать порядка 100 Мб/сек. SSD так ещё больше.

    В данном случае размер данных не важен, ибо это будет тест дисковой подсистемы. Количество сохранённых мелких записей позволяет судить об эффективности алгоритма. При этом утилизировать даже всего 100 Мб/сек обычного диска представляется весьма сложной задачей.  Достаточно чтобы размер был менее килобайта.

    RB+Tree позволяет быстро читать и при этом быстро записывать.

     
     
  • 3.63, JD (ok), 08:39, 19/05/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >[оверквотинг удален]
    > Физически невозможно - это записать за секунду на диск данных больше, чем
    > позволяет пропускная способность диска.
    > Где вы видите информацию о размере записи ???
    > Современные 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
    done

    END='date +%s'

    RES=0;

    let RES=END-START
    echo $RES

     
     
  • 4.64, nvkz2007 (?), 02:14, 20/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ты забыл про файловую систему, которая мало того что пишет файлы блоками большего размера чем сам файл, так еще и таблицу с индексами создает.
     
  • 4.68, Yarick (?), 11:13, 21/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Обязательно попробую.

    В OrientDB есть понятие кластера. Кластер - это, грубо говоря, предварительно созданный файл обычно небольшого размера. Когда пишутся новые записи, то они редко требуют выделения нового места на ФС. Также для каждого кластера есть другой специальный кластер для удалённых записей. В него заносятся пометка о том, что такая-то запись удалена. Т.о. непосредственное добавление или удаление одной записи не приводит в выделению места на ФС.
    А вот хороший алгоритм нужен для быстрого нахождения требуемого адреса внутри кластера. И такой алгоритм есть и он работает.

     
  • 2.69, anton0xf (?), 12:10, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    $ 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.65, artist60 (ok), 15:04, 20/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    1) MySQL тратит ресурсы на проверку пользователя при соединении.
    2) Больше времени уходит на сортировку данных, а не взятие их из БД, в мускуле тоже есть NoSQL.
    И про 125 серверов однозначна пиздеж.

     
  • 1.66, Cerberix (?), 21:05, 20/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кто-то ее пробовал для 1С-ки ?

    Как сумеете прикрутить, отпишитесь плизз тут. Интересен результат.

     
  • 1.67, Аноним (-), 09:01, 21/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Кто в каких задачах использовал подобные БД? С какими отрицательными/узкими/проблемными местами сталкивались?"
    Все проигнорировали товарища, который спрашивал для чего кто использует...
    Значит ли это, что никто из "здешних" их не использует?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру