|
|
3.5, Анонимус1 (?), 02:29, 18/12/2016 [^] [^^] [^^^] [ответить]
| +18 +/– |
Только плашки оперативки подкидывай, подкидывай давай.. чего остановился?
| |
|
4.7, Аноним (-), 02:51, 18/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
У Java тормозит только гуй. Безгуйные приложения на Java сопоставимы с безгуйными приложениями на С++ и проседают в производительности по сравнению с ними всего в полтора раза.
| |
|
|
6.20, Аноним (-), 07:06, 18/12/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> полтора-два раза
Может и 3 получиться. А сборщик мусора может все надолго клинить. Written once, profile evrywhere!
| |
|
7.33, Cpper (?), 13:33, 18/12/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Там есть разные реализации сборщика. Он может работать параллельно и не тормозить остальных.
| |
7.52, Вареник (?), 08:23, 23/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Подключи параллельный сборщик, задай максимальный интервал окна в несколько миллисекунд и будет тебе Soft RealTime счастье.
| |
|
|
5.10, leap42 (ok), 03:15, 18/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
всё немного сложнее: тормозит запуск виртуальной машины, потом какое-то время уходит на прогрев кэшей и оптимизацию кода. как результат, настольные приложения работают невыносимо медленно, но серверные, которые запускаются один раз и работают годами считают на скорости C (ну почти). все неверующие могут поискать бенчмарки на хабре.
| |
|
6.14, angra (ok), 03:57, 18/12/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> тормозит запуск виртуальной машины
Запусти hello world на жаве через time и узнай сколько миллисекунд на самом деле запускается jvm. Треск шаблона гарантирован.
> работают годами считают на скорости C (ну почти). все неверующие могут поискать бенчмарки на хабре.
Зачем хабр, если есть Benchmarks Game. Твое "почти" это в среднем в два раза на задачах, требующих сравнительно небольшого количества памяти. При этом кушает в среднем в 10 раз больше памяти. Но еще веселее становится, когда потребляемая память измеряется гигабайтами и неожиданно оказывается, что gc на таких объемах может очень сильно тормозить работу и разница в скорости куда больше двух раз.
| |
|
7.29, anonymous (??), 12:42, 18/12/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Допускаю, что скорость бывает даже соизмерима, но только в идеальных условиях - когда уже по куску кода прошелся JIT (на него кстати тоже тратится время на первых стадиях после запуска приложения) и если не дергается GC.
Второе может быть достигнуто только если писать код специальным образом, грубо говоря в особом процедурном стиле, что слабо читаемо, и вообще говоря противоречит всем практикам энтерпрайзного программирования. Вся инфраструктура также сделана в духе ООП.
Иначе говоря, GC всегда будет при работе. Естеcтсвенно, при этом отжирая время процессора - впрочем, в обычном случае нефатально.
Стоит упомянуть случай, если повезло меньше, и код оказывался недружелюбным для GC. Тогда большие тормоза, фризы обеспечены, а бороться с этим зачастую нетривиально. Надо осмысливать архитектуру приложения, прикидывать жизненный цикл объектов, их связи, и рефакторить со всеми вытекающими.
Итого, в Jave в обмен на более простой и быстрый цикл разработки ПО мы получаем бомбу замедленного действия в виде GC. В энтерпрайзе это оправдано, обычное приложение до такой стадии развития не доживает, а если все же оказывается таким большим и ценным (т.е. проект уже можно считать успешным), гипотетически можно привелечь команду гуру и все поправить.
| |
7.41, лютый жабист__ (?), 06:53, 19/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
>еще веселее становится, когда потребляемая память измеряется гигабайтами и неожиданно оказывается, что gc на таких объемах может очень сильно тормозить работу и разница в скорости куда больше двух раз
Все сишнеки знают, что GC в жабе тормозит проги с кучей на десятки гигабайт.
Насколько я знаю, подвисает на пару секунд.
Но почему все сишники забывают, что на си такие проги вообще никто никогда не пишет, т.к. такой сложности прога глючит так сурово, что не может в рабочее состояние выйти. Падает раньше чем бенчмарк отрабатывает.
| |
|
6.24, Ubuntu (?), 11:36, 18/12/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> настольные приложения работают невыносимо медленно
Приложения назовёте?
| |
|
|
|
9.45, Аноним (-), 14:24, 19/12/2016 [^] [^^] [^^^] [ответить] | +/– | Забавная штука, аналогично АМД пошли, те тоже сервис с вэб мордой на управление ... текст свёрнут, показать | |
|
|
|
6.36, Анын (ok), 16:21, 18/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
> на скорости C (ну почти). все неверующие могут поискать бенчмарки
> на хабре.
Посмотрите лучше бенчмарки ScyllaDB и Cassandra. Все вопросы отпадут.
| |
|
|
6.32, Аноним (-), 13:10, 18/12/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Имеется ввиду соснольное аппликэйшен, сервис (демон), етц. Написано на языке твоего тела.
| |
|
|
|
|
|
1.12, Аноним (-), 03:47, 18/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Не понятно, как они разруливают конфликты двух параллельных модифицирующих запросов для одних данных. На основе версий можно консистентно читать данные (пусть немного устаревшие), но как записывать мне не понятно. Для того и придуманы транзакции
| |
|
2.15, angra (ok), 04:02, 18/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
Элементарно - они на это забивают. Данная БД предназначена для случаев, когда данных очень много и потерей или некорректностью части из них можно спокойно пренебречь
| |
|
|
4.19, Аноним (-), 06:59, 18/12/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Мне сложно представить ситуации, когда можно использовать такие базы. Разве что для какого-нибудь кеша, но там, обычно, за глаза хватает key-value баз.
Если данные помещаются в базу, значит они ценны. Сейчас даже статистику терять жалко. Она, скорее всего, как-то обрабатывается и анализируется, и говорить, что сегодня отчетов не будет, так как наша бд после сбоя находится в непонятном состоянии, как то глупо.
Да и как делать более или менее сложные запросы, без транзакций? Обычно делаешь селект, обрабатываешь результаты и делаешь абдейт. Даже если это будет один сложный SQL запрос с селектом и апдейтом, все равно внутри бд должно существовать некое понятие транзакций
| |
|
5.23, A.Stahl (ok), 11:06, 18/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
>абдейт
Кстати, часто вижу такую необычную форму записи. Это какая-то шутка или обычная глупость уровня "андройд"?
| |
5.38, Crazy Alex (ok), 16:59, 18/12/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Как раз со статистикой - в самый раз. Не "говорить, что отчётов не будет", а просто самую малость упадёт их точность. Скорее всего - даже не упадёт, один хрен всё усреднится.
То же касается логов - крайне редко там важна одна-единственная конкретная запись из миллионов. Вообще, если не считать финансовые БД небольшая доля потерь частенько вполне приемлема.
| |
5.39, angra (ok), 20:59, 18/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Мне сложно представить ситуации, когда можно использовать такие базы.
Посмотри use cases их сайте. И речь идет не о крупной потере в результате сбоя, а о потере или неточности отдельных записей из-за отстутсвия транзакций.
| |
|
6.46, Аноним (-), 14:30, 19/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
>а о потере или неточности отдельных записей из-за
> отстутсвия транзакций.
Если у продукта А в БД вдруг стала цена от продукта Б (да мало-ли человек в двух табах нажал добавить товар в корзину, чисто гипотетически;) ), то ошибка конечно в конкретной строчке, но результат неверный совсем :).
| |
|
7.50, angra (ok), 02:44, 20/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
Еще раз для танкистов, посмотри для чего ее применяют. Подсказка, для магазинов/складов/бухгалтерии/итд такие БД не подходят и никто не предлагает их использовать, но мир не ограничен этой сферой.
| |
|
|
|
|
|
2.31, arzeth (ok), 13:07, 18/12/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
https://crate.io/docs/reference/sql/dml.html#updating-data
> If the same documents are updated concurrently an VersionConflictException might occur. Crate contains a retry logic that tries to resolve the conflict automatically.
Если данные будут модифицироваться одновременно, то выбросит VersionConflictException, а затем попытается снова выполнить запрос.
> Crate heavily relies on Elasticsearch and Lucene for storage
> and cluster consensus.
> Every replica shard is updated synchronously with its primary and
> always carries the same information. Therefore it does not matter if
> the primary or a replica shard is accessed in terms of
> consistency. Only the refresh of the ''IndexReader'' affects
> consistency.
Консистентна запись (insert, update, т.п.); консистентно получение данных с полным указанием primary key в WHERE.
Про консистентность тут написано: https://crate.io/docs/reference/architecture/storage_consistency.html
| |
2.44, fi (ok), 13:55, 19/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
Вот тут собственно ответ:
>CrateDB оптимально подходит для хранения и формирования выборок для различных автоматически генерируемых данных, таких как логи, результаты периодического опроса датчиков и параметры сетевого трафика.
Один источник - множество получателей. И никаких конфликтов. Самый простой и надежный способ.
| |
|
3.47, Аноним (-), 14:32, 19/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Вот тут собственно ответ:
>>CrateDB оптимально подходит для хранения и формирования выборок для различных автоматически генерируемых данных, таких как логи, результаты периодического опроса датчиков и параметры сетевого трафика.
> Один источник - множество получателей. И никаких конфликтов. Самый простой и
> надежный способ.
А чем это плохо работает в текущих решениях?
Есть к примеру firebird :)
| |
|
4.51, angra (ok), 02:49, 20/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
Скорость. Поинтересуйся, сколько транзакций в секунду может firebird.
Хотя надо сказать, что 40k insert без транзакций у сабжа тоже ни разу не впечатляют.
| |
|
|
|
1.22, Аноним (-), 10:46, 18/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На сколько я помню внутри elasticsearch живёт, почему в новости нет кпоминания о этом?
| |
1.25, anonymous (??), 11:39, 18/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
как тут с brainsplit? раз данные хранятся в виде нескольких копий значит менять эту копию нужно на сервере ответственном за запись, что будет при его падении? при его восстановлении? вообщем как тут под CAP теорему подстраиваются?
| |
1.49, ananim (?), 18:10, 19/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
таки железо уже с сотнями гигабайт уже выпускают, да и терабайтом тож. base in memo
| |
|