The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Первый релиз NoSQL БД OrientDB, opennews (ok), 15-Май-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


4. "Первый релиз NoSQL БД OrientDB"  –2 +/
Сообщение от MaMoHT (?), 15-Май-12, 14:01 
Что интересно понимается под обычным оборудованием... :-)
Это что надо сделать с мускулом, чтобы жаватормозила смогла заменить аж 125 мускулов ...
Ответить | Правка | Наверх | Cообщить модератору

7. "Первый релиз NoSQL БД OrientDB"  +3 +/
Сообщение от ыгччemail (?), 15-Май-12, 14:19 
Написать идиотских кривых запросов и никогда не использовать EXPLAIN.
Ответить | Правка | Наверх | Cообщить модератору

9. "Первый релиз NoSQL БД OrientDB"  +5 +/
Сообщение от anonymous (??), 15-Май-12, 14:53 
например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

17. "Первый релиз NoSQL БД OrientDB"  +/
Сообщение от Yarick (?), 15-Май-12, 15:56 
> например, чтобы найти друзей друзей, через таблички для N уровня вложенности больше чем 4, решение влоб на mysql может и сильнее тормозить.

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

55. "Первый релиз NoSQL БД OrientDB"  +/
Сообщение от Tameoemail (?), 16-Май-12, 11:53 
Денормализация не даёт общего решения подобных проблем. В частности, для предложенной задачи ( поиск друзей N-го уровня ) сложность решения, имхо, растёт по экспоненте.
Ответить | Правка | Наверх | Cообщить модератору

14. "Первый релиз NoSQL БД OrientDB"  +/
Сообщение от ДяДя (?), 15-Май-12, 15:44 
Простите, у вас образование есть ?

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

35. "Первый релиз NoSQL БД OrientDB"  +/
Сообщение от filosofem (ok), 15-Май-12, 21:59 
>В современном железе нет проблем с производительностью процессора

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

Ответить | Правка | Наверх | Cообщить модератору

47. "Первый релиз NoSQL БД OrientDB"  +/
Сообщение от MaMoHT (?), 16-Май-12, 04:23 
> Простите, у вас образование есть ?

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

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

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

  

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

48. "Первый релиз NoSQL БД OrientDB"  +/
Сообщение от MaMoHT (?), 16-Май-12, 04:25 
> Простите, у вас образование есть ?
> В современном железе нет проблем с производительностью процессора, а есть проблемы с
> производительностью дисковой подсистемы. В этом случае решают лишь алгоритмы.

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

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

57. "Первый релиз NoSQL БД OrientDB"  +/
Сообщение от ДяДя (?), 16-Май-12, 12:44 
Уважаемый!
Дело не в платформе, как здесь уже отметили, а в отличии чисто реляционных БД и NoSQL. Сейчас есть тенденция использовать реляционные БД повсеместно. На это есть свои объективные причины. Однако в последнее время накопилось множество задач, которые решают при помощи SQL, но с дикими компромиссами в плане эффективности.

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

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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