|
| 1.2, Аноним (-), 13:40, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Угу, а при замене жавы на С(++) можно будет заменить одним сервером 125 жаватормозил.
| | |
| |
| 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.
| | |
| 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 [^] [^^] [^^^] [ответить]
| +/– | |
> Невозможно в рамках языка. Потому что на уровне языка не определена видимость переменных в разных потоках. Жду вашего решения...
боже мой.. какие же бывают тупые люди
| | |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
>> Вы еще не стали круглым как колобок? :) Ибо непомерно толсто. Так
>> и скажите - я не знаю явы и С++, но слышал, что ява тормоз. Бла-бла-бла.
> А чего там слышать? Достаточно посмотреть на бенчмарки одних и тех же
> алгоритмов и просто как жабисты вечно с профайлингом долбутся, с поводом
> и без.
Одааа, с С++ники сразу пишут идеальный с точки зрения перфоманса код. И без утечек. Смешно...
| | |
|
|
| |
| 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.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.30, Veter (??), 18:58, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Феерично... "Имеет очень малый размер и не имеет сторонних зависимостей;" - и притом написана на джаве - никаких сторонних зависимостей, ага. Кроме маркетинга этим "разработчикам" стоило бы еще и программированием заниматься :D
| | |
| |
| 2.43, grmmhnd (?), 23:45, 15/05/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
Любезный, не путайте платформу, как таковую, и зависимости от сторонних библиотек.
| | |
|
| 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 не сильно спасет.
Тысячи компаний по всему миру сидят на яве и не думают переходить. Да и некуда. А у вас видите ли подозрения
| | |
|
| 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 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"Кто в каких задачах использовал подобные БД? С какими отрицательными/узкими/проблемными местами сталкивались?"
Все проигнорировали товарища, который спрашивал для чего кто использует...
Значит ли это, что никто из "здешних" их не использует?
| | |
|
