На проходящей в эти дни конференции Cassandra Summit 2015 представлена новая открытая СУБД ScyllaDB (http://www.scylladb.com/), в рамках которой предпринята попытка переписать СУБД Apache Cassandra (https://www.opennet.ru/opennews/art.shtml?num=42717) с Java на C++. ScyllaDB обеспечивает полную совместимость с NoSQL СУБД Cassandra, но позволяет добиться существенного увеличения производительности, демонстрируя скорость обработки запросов и отзывчивость на уровне СУБД Redis (https://www.opennet.ru/opennews/art.shtml?num=41958). Новую СУБД представили Ави Кивити (Avi Kiviti) и Дор Лаор (Dor Laor), в своё время создавшие такие известные открытые проекты как гипервизор KVM и операционную систему OSv (https://www.opennet.ru/opennews/art.shtml?num=37936) с воплощением идеи запуска приложений поверх гиперевизора. Код проекта распространяется (https://github.com/scylladb/scylla) под лицензией AGPL.По заявлению разработчиков ScyllaDB обеспечивает (http://www.scylladb.com/technology/cassandra-vs-scylla-bench.../) десятикратное увеличение пропускной способности обработки запросов на каждом узле по сравнению с оригинальной Apache Cassandra, в 99% случаев успевая обработать запрос менее чем за миллисекунду. Например, на типовом узле ScyllaDB способен (http://www.scylladb.com/2015/09/22/watching_scylla_serve_1m/) обрабатывать около одного миллиона транзакций в секунду. Возможность обработать больше запросов на одном узле, позволяет существенно снизить затраты на кластер, в котором для достижения заданных характеристик потребуется на порядок меньше узлов, чем при создании кластера на основе классической СУБД Cassandra. ScyllaDB также упрощает создание запаса производительности, необходимой при обработке нетипичных пиков нагрузки.
<center><a href="http://www.scylladb.com/technology/cassandra-vs-scylla-bench... src="https://www.opennet.ru/opennews/pics_base/0_1443007184.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>Одним из факторов, позволившим добиться подобных показателей производительности, является использование разработанного теми же авторами C++ фреймворка Seastar (http://www.seastar-project.org/), нацеленного на создание сложных серверных приложений, обрабатывающих запросы в асинхронном режиме с учётом особенностей современного оборудования (распараллеливание на многоядерных системах, учёт попадания данных в процессорный кэш, оптимизация для накопителей SSD и полная утилизация пропускной способности 10/40-гигабитных сетевых карт).
<center><a href="http://www.scylladb.com/technology/cassandra-vs-scylla-laten... src="https://www.opennet.ru/opennews/pics_base/0_1443007225.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
ScyllaDB также обладает такими свойствами, как избавление от задержек при проведении упаковки и восстановления целостности БД, отсутствие сборщика мусора, возможность переконфигурации кластера (удаление/добавление узлов) без остановки работы, линейная масштабируемость при которой производительность находится в прямой зависимости от числа процессорных ядер, наличие средств для пакетной загрузки и выгрузки больших объёмов данных из хранилищ Hadoop и Spark.
ScyllaDB поддерживает модель хранения данных на базе семейства столбцов (ColumnFamily, хэши с несколькими уровнями вложенности) и позволяет использовать SQL-подобный язык структурированных запросов CQL (Cassandra Query Language).URL: http://developers.slashdot.org/story/15/09/22/2145258/cassan...
Новость: https://www.opennet.ru/opennews/art.shtml?num=43017
Эпично
> ЭпичноА где же изен? С его рассказами про Java Не Тормозит!!!111
Изен? Это по-хакасски "здравствуйте".
> А где же изен? С его рассказами про Java Не Тормозит!!!111Тормозят KAV и Яндекс-бар, а Java просто работает там, где необходимо.
Cassandra написана для использования Java 7 ( http://wiki.apache.org/cassandra/HowToBuild ) и не использует новых возможностей по работе с потоками из Java 8. (JVM, кстати, написана на C++. Может в этом причина тормозов, а?)
> Тормозят KAV и Яндекс-бар,Ты о чем, изя? О том что у тебя тырят файлы и "кашпировский", и яндекс, и майкрософт, и на всех вместе ресурсов уже не хватает? :)
> а Java просто работает там, где необходимо.
Попроси кашпировского переписать его безобразие на яве. Узнаешь как сделать винду однозадачной :)
> Cassandra написана для использования Java 7
Изя, помаши яве ручкой :P.
Поколение Z. Ты снова не подходишь. Ищи другую работу.
> Поколение Z. Ты снова не подходишь. Ищи другую работу.Да, изя, ВАМ я точно не подхожу. Работать с такими как ты и под виндой - это надо себя очень сильно не уважать.
> Ты о чем, изя?изя тормозит.
> JVM, кстати, написана на C++. Может в этом причина тормозов, а?Точно! Надо переписать JVM на Java!
>> JVM, кстати, написана на C++. Может в этом причина тормозов, а?
> Точно! Надо переписать JVM на Java!Внезапно это уже сделали. Но, к сожалению, не успели внедрить - JVM.go оказалась перспективнее. ;)
> Внезапно это уже сделали. Но, к сожалению, не успели внедрить - JVM.go
> оказалась перспективнее. ;)Тогда go.go будет еще интереснее. А уж go.go.go... :)
>> Внезапно это уже сделали. Но, к сожалению, не успели внедрить - JVM.go
>> оказалась перспективнее. ;)
> Тогда go.go будет еще интереснее. А уж go.go.go... :)Отписался от этого бреда.
Так вроде была новость, что Go вроде уе на Go написан или я что-то путаю?
Меня только один вопрос интересует, а именно можно ли этот их GC выключить и самому когда надо удалять обьекты.
можешь выключить, но что бы удалить объекты надо будет вручную вызывать весь GC
> можешь выключить, но что бы удалить объекты надо будет вручную вызывать весь
> GCХотя можешь переменные на стеке хранить. этот подход моден в Go
Обычно проблема не в языке, а в том как его использовать.>> Программа среднестатистического студента на C++ работает медленнее чем тоже самое, написаное им же, на Java (c)
Часто слышу такое высказывание. Пруф будет?
> Часто слышу такое высказывание. Пруф будет?просто такие студенты не умеют ещё и в бенчмарки. сначала запускают цпп‐вариант на жирном файле, а сразу за ним жабу. прогретые файловые кэши? не, этому не учили.
> Часто слышу такое высказывание. Пруф будет?Пруф на что? На то как плохо можно написать программу на любом языке?
Зачем надо было вообще писать базу данных на тормозной Java?
Чтобы потом переписать на быстром С++
а потом на ещё быстром C? ))
А почему думаете, что C перестанет быть быстрым?
я как раз и написал что после C++ возможно следующим щагом будет переписать на C (который быстрее), а потом уже конечно на асемблере! ;)
Вас и спрашивают, почему вы думаете что на С или ассемблере будет работать ощутимо быстрее, чем на С++?
Потому, что лишнего не делает, когда не просят.
---
#include <iostream>
using namespace std;int main()
{
cout << "Hello, world!" << endl;
return 0;
}
$ strace ./cpp.out 2>&1 | tee | wc -l
63
int main()
{
write(1, "Hello, world!\n",14);
return 0;
}
$ strace ./c.out 2>&1 | tee | wc -l
50Мало? Ну лови дальше.
$ gcc test.c -s
$ cat test.s
.file "test.c"
.section .rodata
.LC0:
.string "Hello, world!\n"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $14, %edx
movl $.LC0, %esi
movl $1, %edi
movl $0, %eax
call write
movl $0, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Debian 4.9.2-10) 4.9.2"
.section .note.GNU-stack,"",@progbitsА теперь куча говна на С++
$ g++ test.cpp -S
$ cat test.s
.file "test.cpp"
.local _ZStL8__ioinit
.comm _ZStL8__ioinit,1,1
.section .rodata
.LC0:
.string "Hello, world!"
.text
.globl main
.type main, @function
main:
.LFB1020:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $.LC0, %esi
movl $_ZSt4cout, %edi
call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
movl $_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_, %esi
movq %rax, %rdi
call _ZNSolsEPFRSoS_E
movl $0, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1020:
.size main, .-main
.type _Z41__static_initialization_and_destruction_0ii, @function
_Z41__static_initialization_and_destruction_0ii:
.LFB1029:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $16, %rsp
movl %edi, -4(%rbp)
movl %esi, -8(%rbp)
cmpl $1, -4(%rbp)
jne .L3
cmpl $65535, -8(%rbp)
jne .L3
movl $_ZStL8__ioinit, %edi
call _ZNSt8ios_base4InitC1Ev
movl $__dso_handle, %edx
movl $_ZStL8__ioinit, %esi
movl $_ZNSt8ios_base4InitD1Ev, %edi
call __cxa_atexit
.L3:
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1029:
.size _Z41__static_initialization_and_destruction_0ii, .-_Z41__static_initialization_and_destruction_0ii
.type _GLOBAL__sub_I_main, @function
_GLOBAL__sub_I_main:
.LFB1030:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $65535, %esi
movl $1, %edi
call _Z41__static_initialization_and_destruction_0ii
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1030:
.size _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main
.section .init_array,"aw"
.align 8
.quad _GLOBAL__sub_I_main
.hidden __dso_handle
.ident "GCC: (Debian 4.9.2-10) 4.9.2"
.section .note.GNU-stack,"",@progbits
Фкурил?
Какая глупость мерять oneliner-ом. А на проекте из 500килострочек си может оказаться быстрее (а джава ещё быстрее).
> Какая глупость мерять oneliner-ом. А на проекте из 500килострочек си может оказаться
> быстрее (а джава ещё быстрее).Жаба по определению не может быть быстрее.
> Потому, что лишнего не делает, когда не просят.в с++ для корректной работы main() необходимо сделать предварительные танцы с бубном, вроде настройки переменных std::cout. так что это необходимое зло. вы бы еще включили полный rtti что бы браузер не вынес ноши :))))))
з.ы. есть такая удобная штука http::/pastebin.org
> вы бы ещеА если я С начну оптимизировать?
void main() { char A[] =
"\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\x0b\x00"
"\xc7\x46\x0c\x00\x00\x00\x00\xb8\x0b\x00\x0b\x00"
"\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80";
int *ret;ret = (int *)&ret+2; (*ret) = (int)A;}
Не быстрее
> а потом уже конечно на асемблере! ;)конечно на ассемблере!!! как neon на армах и прочие simd + публикация исходников микрокода на vhdl всех железных оптимизаций!!!:)
похожий пример. я разрабатываю протокол, после отладки прототипа python + protobuf + kivy и запуска минимального функционала - будет нативный клиент на с++.
Высокоуровневые средства разработки и отладки, в частности пайтон с киви идеально подходят для прототипирования. nb protobuf - позволяет сохранять совместимость между языками программирования на сетевом уровне.
вместо чтобы сразу взять нормальный язык — D, например, — и не писать мусорных прототипов. впрочем, чего хорошего можно ожидать от гвидобейсиковцев…
Если учесть что понять яву ни сколько не проще, чем понять пюсы, вообще странно ...
ну это скорее вопрос упоротости разрабов, а не языка ))
Проще её понять. Она громоздкая как чёрт знает что для практических применений (потому что по факту она нужна только вместе со знанием J2EE), но сам язык прост. Плюсы - сами сложны, но это избавляет от громоздких фреймворков вокруг - если хотеть, конечно.
> Проще её понять. Она громоздкая как чёрт знает что для практических применений
> (потому что по факту она нужна только вместе со знанием J2EE),
> но сам язык прост. Плюсы - сами сложны, но это избавляет
> от громоздких фреймворков вокруг - если хотеть, конечно.Если Java-библиотеки (т.н. Jar-hell) переписать на С++, что-то в них станет проще?
Будет еще больший hell из-за разных соглашений, стилей и использования подмножеств языка.
У одних будет все через смартпоинтеры STD, у других через смартпоинтеры Boost, у третьих черех Qt, а у четвертых все через &. В документации каждой либы будет дисклеймер, что нужно глобально использовать аллокатор именно этой либы, иначе все рухнет.И интегрируй потом это все в один конечный продукт за разумное время...
Я что-то писал про "проще"? Менее громоздко - станет. За счёт возможности выкинуть половину объектных иерархий в пользу статического полиморфизма и иcпользования duck typing. Не D, конечно, в котором код, парсящий JSON в статические структуры, занимает пару экранов, но тоже весьма неплохо. А компактный код лучше помещется в голову иЮ соответствено, алгоритмически оптимизируется.А что до соглашений - берите целый стек и будет счастье. std - занчит, std (что самое правильное, кстати). boost отлично подружится и смарт поинтеры будет использовать std, кстати, если версия плюсов свежая (а она везде сейчас свежая есть). Зависли на Qt - сидите на его стеке либ, делов-то. нужен вам ручной мемори менеджмент - вперёд. И да, если либы пишутся не идиотами (а другие зачем брать?) то авторы о совместимости подумали. насчёт аллокаторов - это в сях любят свои аллокаторы, в плюсах как раз такого нет, если у вас не закрытые либы, компилированные чёрт знает чем, конечно.
И, опять же, интеграция этого дела, если у вас хоть какая-то архитектура есть, будет очень проста даже при зоопарке - разложили на слои, в каждом слое - своё, интерфейс к вышележащему - на том, что него, своих кишок - на том, что в них. И всё.
Да уж, без библиотек и фреймворков на сипипи всё так легко и быстро пишется. 8))))Погуглим банальнейшее "convert wstring to string" и мозг лопается - кучи нюансов и несовместимостей на уровне "в C++11 одно, в более новом режиме другое, под виндой третье, в linux четвертое". А начнём стек писать самописный, а потом отлаживать - так вообще и протрезветь можно!
Это, кстати, ответ на вопрос: за что жабисты не любят си. А вот за что сишники не любят жабу - мистика. Наверное банальная зависть?
Конечно зависть.
Один человек на Java EE делают за четыре дня программу лояльности аналогичную "Связной Клуб". Польза для бизнеса огромная. Иные не на Java втроём за полгода делают на 50% меньше функционал. А ЗП хотят такую же. А бизнесу где деньги брать, если ещё не работает то, что должно их приносить ???
>А вот за что сишники не любят жабу - мистикаДа просто выжгли себе мозг пытаясь понять всю тупость спецификации C++
1) человек в вопросе пытается сделать фигню, так как, похоже, воощбще не понимает. что он делает. Здесь это ему детально объяснили: http://stackoverflow.com/a/4805122
2) Если есть решение для C+11 - им и надо пользоваться. Плюсы до 11 давно можно забыть, а то, что есть в них - просто и абсолютно осмысленно - преобразование с указанием, в какой кодировке string.А не любят, потому что на все гвозди - один микроскоп. Со стратегий работы с памятью начиная и заканчивая убогим map.Get.
Мы прямо щас пишем прожку в VS10, никакого C+11 там нет.Именно в теме на SO во всех подветках куча воплей:
-это не работает в linux
-некоторые символы стрипаются
-в ICU это надо делать по другому
итд
Ваши проблемы, если вы сидите на каой-то хрени, которая отродясь стандарты не могла толком поддерживать. И напоминаю, на каком сайте вы находитесь. При чём здесь проприетарщина от MS?Да, в плюсах до 11 не было вменяемой поддержки кодировок. Теперь она есть.
> Мы прямо щас пишем прожку в VS10, никакого C+11 там нет.Оно даже в С99 не может, куда им до новых плюсов-то.
пишете на RUST
> Мы прямо щас пишем прожку в VS10а на программируемых калькуляторах не пробовали? там ещё больше можно задолбаться — ведь это же и есть цель.
Я всегда думала, что так же быстра как и C++.
Но при переписывании на C++, как правило, появляется огромное число уязвимостей, т.к. Java гораздо безопаснее C++ (поэтоу софт для банковских сфер и пр. ответвенных направлений пишется на Java). Вообщем жду новости такого типа: "злоумышленники взломали ScyllaDB и получили доступ к 100500 банковским картам, банк срочно откатывается назад на Cassandra"
Если взять "средних" разработчиков на плюсах и яве - так и было бы. Но эту штуку писали отнюдь не "средние", а высококвалифицырованные спецы. У которых нет проблем с архитектурой и пониманием, как что происходит - поэтому не будет там никакого огромного числа уязвимостей.
зуб даешь?
Что спецы высококвалифицированные? Разумеется. По тому, что вообще подобное осилили, видно. Что штука годится в продакшн? Нет, конечно. Подождём пару лет, поглядим - если хорошо себя покажет - можно будет пользоваться. Такие вещи длдя мелочей не применяются, так что спешить не надо.
> зуб даешь?ты, когда всё‐таки найдёшь правильный сайт стоматологии, ещё и к окулисту запишись — оно пригодится.
> Java
> безопасность
Возможное появление уязвимостей при переписывании на C++ с лихвой компенсируется уязвимостями в JVM. Разница лишь в том, что для С++ нужно проверять только качество кода программы, а для JVM и программы, и JVM.
> Возможное появление уязвимостей при переписывании на C++ с лихвой компенсируется уязвимостями
> в JVM. Разница лишь в том, что для С++ нужно проверять
> только качество кода программы, а для JVM и программы, и JVM.А приведите примеры опасного кода на Java
Я большого опыта программирования на нем нет, но хотел бы иметь представление, чтобы пердеть в джавистов заряженными эм... орешками)
public class MainClass {public static void main(String[] args) {
int inChar;
System.out.println("Enter a Character:");
inChar = System.in.read();
System.out.print("You entered ");
System.out.println(inChar);
}
>А приведите примеры опасного кода на Java
>> public class MainClass {
>> public static void main(String[] args) {
>> int inChar;
>> System.out.println("Enter a Character:");
>> inChar = System.in.read();
>> System.out.print("You entered ");
>> System.out.println(inChar);
>> }да здравствует говнокод. Если ты даже в такой простой программке умудрился допустить столь грубую ошибку, наверное тебе пора в школу собираться. Хотя бы так написал бы так
import java.io.IOException;
public class MainClass {public static void main(String[] args) throws IOException {
int inChar;
System.out.println("Enter a Character:");
inChar = System.in.read();
System.out.print("You entered ");
System.out.println(inChar);
}Но и этот говнокод безопаснее кода на C/C++.
>> Я большого опыта программирования на нем нет, но хотел бы иметь представление,
>> чтобы пердеть в джавистов заряженными эм... орешками)боюсь, что у вас не хватит квалификации, чтобы совершать данные деяния, ибо среднестатический джавист уммнее среднестатического анонимуса с опеннета.
> Я всегда думала, что так же быстра как и C++.Вот это - совершенно не факт. У явы рантайм делает много чего лишнего. И на чисто алгоритмическом коде, например сжатии - ява продует сям разика так в три. И вообще, рантайм явы может подложить немало подлян, странно реализуя самые базовые операции. Так что в иных случаях и в 10 раз быстрее - не предел.
> Но при переписывании на C++, как правило, появляется огромное число уязвимостей,
А то что в жабистом рантайме их затыкают по 30 штук в каждой версии - вас не смущает?
> взломали ScyllaDB и получили доступ к 100500 банковским картам, банк срочно
> откатывается назад на Cassandra"Ну вот когда и если - тогда и приходите. А учитывая квалификацию жабистов - скорее взломают кассандру. Ну а что, вон кучу всего на питонах, пыхе, рубях и прочая - ломают. И вебня давно обставила си в вопросах дырявости.
> Вот это - совершенно не факт. У явы рантайм делает много чего
> лишнего. И на чисто алгоритмическом коде, например сжатии - ява продует
> сям разика так в три. И вообще, рантайм явы может подложить
> немало подлян, странно реализуя самые базовые операции. Так что в иных
> случаях и в 10 раз быстрее - не предел.На задаче - обрабатывать файл с недействительными паспортами РФ (качается с сайта ФМС), это 93 миллиона коротких стрингов (номер+серия), джабка оказалась быстрее си. Ну, рамы ела 4ГБ против 1, но это ерунда.
Полностью смысл задачи - взять сегодняшний файл и вчерашний, выделить дельту и засунуть в базу - последний шаг уже не бенчмаркался. Хотя jdbc-драйвер для Оракла на джаве тоже прямее, чем сишная поделка :)
Запросто, как раз тот случай, когда в сях у тривиальной реализации с аллокациями тормоза, а в жабе они шустрые, а gc на такой адачке вообще ни разу не запустится, скорее всего. Решаемо при чуть вдумчивом подходе, рзумеется, чуть позже накидаю для примера.
> Запросто, как раз тот случай, когда в сях у тривиальной реализации с
> аллокациями тормозану дык тело, похоже, даже в более‐менее нормальную реализацию хэш‐таблиц не смогло. максимум смогло скачать, и то профэйлило в использовании.
Тьфу, что-то я туплю. Какие джавы? Какие самописные программы? sort (если оригинал не сортирован) + diff решат все ваши проблемы. Сортированный файл хранить до завтра, разумеется, и второй раз не сортировать.
> Тьфу, что-то я туплю. Какие джавы? Какие самописные программы? sort (если оригинал
> не сортирован) + diff решат все ваши проблемы. Сортированный файл хранить
> до завтра, разумеется, и второй раз не сортировать."вчера" хранится в СУБД. Если хранить его ещё и в файле, то возможна неконсистентность.
Просто загрузка в СУБД (Oracle) нового файла - тормоза на полчаса.
Штатный линуксовый diff между 2 файлами по 100млн строк - тормоза на "больше часа".
Проги на джаве и си "выгрузить из СУБД, найти дельту, загрузить в СУБД" примерно одинаково на уровне 4-5 минут. На джаве шаг "найти дельту" около 40 секунд отрабатывает с fastutil.
Программу накидал за полчаса на стандартных и протестированных компонентах. Сишник 2 дня чё-то писал, переписывал, оптимизировал, в итоге скорость чуть ниже и ДРУГИЕ цифры. Т.е. у него ещё и баги надо было искать ;) При том, что сишник как прогер намного сильнее меня.
> Штатный линуксовый diff между 2 файлами по 100млн строк - тормоза на
> "больше часа".Кстати, "Штатный линуксовый diff" написанный на си (даже не с++ наверное), кушает 8-9ГБ ОЗУ при сравнении двух файлов с 100млн строк :) Джава 3.5-4.
Хм, уже интересно стало, сейчас докачается - пропробую наваять наскидку - тоже в рамках получаса. Завтра ещё обновлённую базу скачаю, чтобы реальные данные были. Но насчёт памяти - точно странно, там же потоковая обработка, как можно приней сожрать больше, чем суммарный объём двух файлов - не понимаю. Впрочем, раз оно в базе - можно голову не морочить.
А в чём проблемы с загрузкой 100 млн. строк в оракл? 1 Гб. данных на час что-то странное.
> А в чём проблемы с загрузкой 100 млн. строк в оракл? 1
> Гб. данных на час что-то странное.Хотя если на каждую строку один запрос то возможно :)
Убейте архитектора системы - можно об стенку. такие вещи НЕ пишут на java/c и прочей лабуде- это задача (обратный поиск к пересечению) делает сама субд на раз! Подключаешь файл как таблицу и один селект вытягивает новые данные из нее, затем insert. Даже мускль сделает вашу java как младенца.зы. И этот ананист учит нас жизни???
> Убейте архитектора системы - можно об стенку. такие вещи НЕ пишут на
> java/c и прочей лабуде- это задача (обратный поиск к пересечению) делает
> сама субд на раз!Oracle за полчаса. Читать учись. Или мускуль такой крутой стал что делаем меньше. Чем за 40 сек то, что Оракля за полчаса?
> На задаче - обрабатывать файл с недействительными паспортами РФ (качается с сайта
> ФМС), это 93 миллиона коротких стрингов (номер+серия), джабка оказалась быстрее си.
> Ну, рамы ела 4ГБ против 1, но это ерунда.рукожопие — это врождённое, потому что.
> Я всегда думала, что так же быстра как и C++.
> Но при переписывании на C++, как правило, появляется огромное число уязвимостей, т.к.
> Java гораздо безопаснее C++ (поэтоу софт для банковских сфер и пр.
> ответвенных направлений пишется на Java). Вообщем жду новости такого типа: "злоумышленники
> взломали ScyllaDB и получили доступ к 100500 банковским картам, банк срочно
> откатывается назад на Cassandra"Банки любят Oracle и всякие WebSphere с поядерными лицензиями. Возможно откаты, возможно на душе спокойнее: размывание отвественности, типа мы же заплатили за продукт и за ТАКИЕ ДЕНЬГИ нам должны были поставить суперустойчивое ПО, а мы руками трогать не можем и если что - "это не мы". Или только частично мы, а не полностью.
Вот же жесть. Забаньте уже эту блондинку тролля. Молю.
Вы наверное прочитали только первые два абзаца. Там ниже, под картинками, архитектура описывается. Наверное ЛЬВИНАЯ доля выигрыша именно в ней, а не в C++: убрали разделение данных (и, соответственно, диспетчеризацию доступа) между разными обработчиками, каждый из которых прикреплен к своему ядру процессора, а если взаимодействие/синхронизация какая-то нужна - то только через отправку сообщений, а не через механизмы блокировок/синхронизации операционной системы. А как тебе такой прием - свой оптимизированный TCP/IP стек, напрямую работающий с сетевой картой и стек этот находится в обработчике запросов, работа происходит в юзерспейсе, т.е. переключений контекста выполнения - минимум. Выигрыш тут больше из-за архитектуры, чем из-за C++. Заслуга C++ наверное тут только в том, что он позволяет делать ручные низкоуровневые оптимизации и легче организовывать прямой доступ к железу. Ну и конечно у него нет приостановок выполнения из-за сборки мусора, это бесспорно. Зато теперь появится возможность появления толпы ошибок, которые в яве невозможны. Даже несмотря на авторитет и профессионализм разработчиков (все совершают ошибки).
Современная беда - это разные уровни развития ЦП и ОЗУ.
>Заслуга C++ наверное тут только в том, что он позволяет делать ручные низкоуровневые оптимизации и легче организовывать прямой доступ к железу.Теперь на Java это проще. Даже блог есть: http://java-is-the-new-c.blogspot.de/
Например, одно слово final и JIT сохраняет переменную в регистрах. Как на C++ это сделать ? Вы должны дружить с процессором. Только тогда будет производительность. От языка это не зависит ВООБЩЕ.
У современных процессоров беда с кэшем - false sharing. Ребята, которые делали Disruptor, сделали небольшой костыль для выравнивания адреса переменной на 64 байта. Производительность возросла в разы, но это просто дружба с ЦП, а не заслуга языка/платформы. В Java 8 этот приём вошёл.
У современных процессоров есть ещё куча иных квантовых эффектов, кроме кэша. Их можно использовать. http://www.youtube.com/watch?v=RGFJjQKChNQhttp://mechanical-sympathy.blogspot.ru/
http://psy-lob-saw.blogspot.ru/
Для Cassandra это, пожалуй, приговор.
Через пару-тройку лет, если эта штука покажет свою надёжность - может и да. Сегмент такой, что никто резкие движения совершать не будет, тем более, что это БД, а не хрен собачий.Ну и не оставляет чувство, что какой-то подвох всё же есть. В прирост раза в полтора-два я бы поверил, но пять-десять... Хотя было бы приятно, конечно.
Возможно прирост производительности по большей части за счет Seastar, чем за счет смены языка.
Возможно у Java просело из-за переключений контекста пользовательский процесс - ядро.
Если графики на Seastar про memcached посмотреть, то там тоже прирост колоссальный.
http://www.scylladb.com/technology/status/ говорит, что еще есть спектр задач, которые не выполнены - потом производительность может чуть осядет.> Scylla currently lack support for TABLE UPDATE, DROP, TRUNCATE and pagination
вот с pagination вообще не понял - если оно не работает, смысла от этой бд не много
> Возможно у Java просело из-за переключений контекста пользовательский процесс - ядро.Или просто трэша в рантайме. Там такого есть. На хабре навалом примеров как можно ускорить в 100500 раз жабу если написать самому. Правда, спрашивается, нафига тогда вообще эта жаба и ее стометровый рантайм нужны...
Вроде бы как в новости описан и подвох. Там, где про карты интела.
Избавление от лишних абстракций на уровне, близком к железу, легко разгоняет программы, интенсивно его использующие. Но может приготовить вам сюрприз на другом железе.
> Избавление от лишних абстракций на уровне, близком к железу, легко разгоняет программы,...только если бы там была Ява - это были бы мертвому припарки.
Ага, вижу - это позже добавили, кажется. Но это небольшой подвох - там, где нужна Cassandra/Hadoop, подобрать железо/ОС под задачу - не проблема.
> подобрать железо/ОС под задачу - не проблема.Проблемы могут появиться, когда это подобранное железо устареет.
Впрочем, пока сабж с Кассандрой совместимы, можно и пошалить...
Это не один год, елси будет хоть какой-то интерес - будут поддерживать. Да и совместимо снизу вверх будет почти наверняка. В общем, риск не особо большой, я бы сказал
Более того: там где нужны Cassandra/Hadoop, добавить поддержку нужной железки - тоже не запредельная задача, поэтому поддержкой хорошего железа это хозяйство обрастёт достаточно быстро.
> Через пару-тройку лет, если эта штука покажет свою надёжность - может и
> да. Сегмент такой, что никто резкие движения совершать не будет, тем
> более, что это БД, а не хрен собачий.
> Ну и не оставляет чувство, что какой-то подвох всё же есть. В
> прирост раза в полтора-два я бы поверил, но пять-десять... Хотя было
> бы приятно, конечно.Вряд ли разрыв сохранится на годы. Затюнят Java под конкретный case и разрыв станет типичные 30%.
Installing Scylla on Ubuntu or Debian-based systems
Coming Soon
Ну логично - редхаты и производные им всяко важнее, а вылавливать приколы платформ лучше, когда хоть где-то есть уверенность, что всё работает как надо.
Ключ/значения уже мало, а хэши нормальные только в Cassandra. Давно хотел её попробовать, но Java пугала. ScyllaDB - просто мечта.
крутые программисты эти Ави Кивити и Дор Лаор (кстати, имена как из научной фантастики, к примеру, жителей Марса)
Ага, как в книгах про Джона Картера ))
Из Ефремова, например.
Кстати да
Видимо теперь чтобы писать на сях - надо родиться на марсе. Угрюмое будущее.
что за чушь? обычные для Израильтян имена
> что за чушь? обычные для Израильтян именавнезапно, «туманность андромеды» заиграла совсем новыми и неожиданными красками…
Если найдется фрик который фо фан перепишет на pure c то ждем еще двухкратного выигрыша в перфомансе.Хотя и так неплохо получилось.....
На правах тролля: зачем нам эти жалкие полумеры, asm!
> На правах тролля: зачем нам эти жалкие полумеры, asm!На правах гипертролля: зачем нам эти жалкие полумеры? Только машинный код, только покатушечная прошивка!
Очень не факт. Низкий уровень там и так, похоже, выжали как могли (и плюсы в этом ни разу не помеха), а более высокий уровень на плюсах куда больше шансов эффективно сделать. Правда, плюсы уметь надо - но эти, похоже, умеют.
Раз не факт, то что на C быстрее Плюсов, то может поправишь плюсовый код для бэнчмарков, где половина тестов показывает 2-ух кратное превосходство C над С++
http://benchmarksgame.alioth.debian.org/u32q/c.php
k-nucleotide?
Нет тут помощник нужен :)
Раз С быстрее плюсов (и вообще, всего остального), может поправишь сишный код так, чтобы он не сливал в девять раз плюсовому?
http://benchmarksgame.alioth.debian.org/u64q/performance.php...Или расту http://benchmarksgame.alioth.debian.org/u64q/performance.php...
Или в полтора раза той же скале (не говоря о плюсах) http://benchmarksgame.alioth.debian.org/u64q/performance.php...
Ну или хоть не продувать тому же хацкелю в 30(!) раз?
http://benchmarksgame.alioth.debian.org/u64q/performance.php...
а может лучше подучите плюсы и перестаните злоупотреблять ооп и шаблонами?
школота обычно не очень отличают, например, шаблоны, которые являются скорее препроцессором, чем компилятором, от просто функций/методов, которые суть код.
отсюда большинство проблем с производительностью.
Хм, а вот обратный пример: http://benchmarksgame.alioth.debian.org/u32/performance.php?...Но вообще - чем мельче задача, тем больше плюшек от низкого уровня. Чем сложнее - тем более важна хорошая архитектура, которую на чистых сях задолбаешься делать.
Сравнения производительности с MongoDB еще нигде не засветились?
А чего там смотреть?
Тут вон приведён график с _миллионом_ транзакций в секунду на запись.
Причём запись у них быстрее чтения
У кассандры запись всегда была быстрее чтения
На сферическом сервере в вакууме?
> На сферическом сервере в вакууме?На продакшн MongoDB тем более лучше не ставить.
https://github.com/scylladb/scylla/wiki/Scylla-and-Cassandra...Если писать из /dev/zero да сохранять в /dev/null, да еще и __только__ под fedora/redhat и только для intel... Верю! (с) !Станиславский.....
>учёт попадания данных в процессорный кэшСупер! Отлично продемонстрирован нехороший эффект от false sharing.
Возьмите в Java обычный AtomicLong и выровненный по линии кэша LongAdder.
Результат будет аналогичный. И не нужно C++ использовать :-D !!!
Ну да, только там еще в рантайме потом какая-нибудь пакость с жуткой неоптимальностью вылезет и прочая. И придется половину рантайма переписать. А запоминать раскартировку грабель в таком монстре - это крындец.
Количество "not supported" настораживает. Бесполезная технодемка какая-то.
оно умеет читать и менять ключ в одной транзакции залочив ключ или хотя бы как memcaced через CAS?
данные там (или в кассандре) резервируются на разных серверах?
не получится ли так что одна и та же запись есть на сервере X и на сервере Y и в какой-то момент сеть упала и какое-то приложение изменило запись на X а другое на Y а потом сеть восстановилась - что будет при этом? записи сольются? по какому правилу? или такой вариант поведения не возможен?
читаем доки по кассандре, не ленимся
дружище ответь на вопросы. ПОЖАЛУЙСТА. может оно мне вообще не подходит и копать не стоит в эту сторону, а может это именно то что нужно, ты ведь знаешь ответы это ведь не трудно?
> ты ведь знаешь ответы это ведь не трудно?вот только ни одной причины, по которой другие должны читать документацию за тебя, ты не привёл. Отцы, значит, не ленились немного своего времени потратить, а современная хипстота уверена, что ей все вокруг обязаны.
Как я понял все зависит от настроек если replication_factor = 1 то всегда храниться одна копия данных (вопрос насколько надежно и насколько легко делать и востанавливать бекапы во всем этом). Если же replication_factor например 2 то храниться уже две копии и главной считается та у которой время обновления больше. Те возможен вариант что клиент покупает товар (X) - он помещается в первую копию (A), а во вторую копию (B) из за проблем сети нет. Соответственно с одного узла у клиента есть товар, с другого нет. Потом клиент покупает еще один товар Y и он попадает в копию (B) где товара еще нет (ожидает синхронизации) и не попадает в копию (A) из за проблем сети. Потом сеть востанавливается, происходит синхронизация и поскольку последнее время изменения в копии (B) выходит что у клиента только товар Y, а товар X потерян. Если я прав (а похоже это так), то не ясно кому вообще может быть нужен такой глюкодром? Может быть все сложнее и для копии храниться не только время последнего изменения но и история времен изменения? Тогда не ясно как все это мержится... Кто нибудь может это прокомментировать?
Задачса с товарами - для реляционной БД.
Cassandra менее удобна, менее стандартизирована, не транзакционна, с бедными возможностями.Недостатков много. Если есть возможность использовать реляционную БД - её нужно использовать.
Если у вас трилионы покупок (или хотябы миллиард), то вам возможно подойдёт кассандра и тут нужен правильный дизайн. высказывание "клиент покупает товар (X) - он помещается в первую копию (A)" не совсем понятно, копию чего?
Если каждая запись о покупке товара - в отдельной строчке - проблем нет.
А что же скажет Изен?
А можно я вместо него:https://github.com/scylladb/scylla/wiki/Scylla-and-Cassandra...
- несколько пунктов полюбому вызовут ощутимое просаживание быстродействия (триггеры, пермишены, опции создания таблицы, влияющие на запись)
- у Java старый и универсальный стек для IO (Linux, Max OS X, Windows), здесь же в основе низкоуровневый фреймворк для сети, заточенный не только под одну ОС (в данный момент только RedHat Linux) да и вообще под конкретного производителя сетевого железа (Intel). И даже более того: последних поколений этого железа.Какой там будет прирост, если все фичи будут реализованы и запустить все это на другом железе, не ясно.
Подгонка под железо/ОС - ерунда. Не на неведомых арендованых VDS же кластер гонять. А вот насчёт фич - вопрос более серьёзный.
linux only
> linux onlyАналитические выводы с высоты дивана?
Как будто что-то плохое.
вендор локин - это всегда "что-то плохое". доказанно виндой/ia32
Ай-яй-яй, опять буратина пролетел со своей бздой, как фанера над парижем. Кушай-кушай, не обляпайся.
Для любителей ПЭКЭДЖЕЙ.
> Разница в скорости в 10 разОтлично, есть ведь ещё люди...
> собственный оптимизирванный TCP/IP-стекЭэээ стоп-стоп-стоп... А ну ка поподробнее - они переписали всё на плюсах и прикрутили свой TCP-стек и достигли повышения производительности *только* в 10 раз при сравнимых задержках? ДА ЭТО ЖЕ ЭПИЧНЕЙШИЙ ФЭЙЛ!!!
> А ну ка поподробнее - они переписали всё на плюсах и прикрутили свой TCP-стек и достигли повышения производительности *только* в 10 раз при сравнимых задержках? ДА ЭТО ЖЕ ЭПИЧНЕЙШИЙ ФЭЙЛ!!!https://en.wikipedia.org/wiki/Data_Plane_Development_Kit
Реализация ipsec без DPDK - 4 Gbit.
Реализация на userspace - 40GBit.Когда речь уже идёт о миллионах запросов (или даже пакетов) в секунду, десятикратное увеличение производительности даётся очень тяжело, даже если у нас неограниченное количество ядер и только 1-4 сетевых интерфейса.
Зацени производительность всего стека linux на сороковке и десятке:
https://rhsummit.files.wordpress.com/2012/03/wagner_network_...
https://wiki.chipp.ch/twiki/pub/CmsTier3/NodeTypeFileServerH...на роутинг 8-9 гигабит с трудом прокачивается
>[оверквотинг удален]
> https://en.wikipedia.org/wiki/Data_Plane_Development_Kit
> Реализация ipsec без DPDK - 4 Gbit.
> Реализация на userspace - 40GBit.
> Когда речь уже идёт о миллионах запросов (или даже пакетов) в секунду,
> десятикратное увеличение производительности даётся очень тяжело, даже если у нас неограниченное
> количество ядер и только 1-4 сетевых интерфейса.
> Зацени производительность всего стека linux на сороковке и десятке:
> https://rhsummit.files.wordpress.com/2012/03/wagner_network_...
> https://wiki.chipp.ch/twiki/pub/CmsTier3/NodeTypeFileServerH...
> на роутинг 8-9 гигабит с трудом прокачиваетсяХа, отлично, зато синтетика тесты прямо ураган когда с темиже BSD сравнивают… ))))
Эти попугаи, которых в десять раз больше - не о чем. Миллион запросов в секунду с машины они могли получить при чтении очень маленьких не меняющихся данных из кэша в ОЗУ в пределах одной стойки. Такой тест не имеет вообще ничего общего с реальной жизнью, т.е. ни о чем не говорит.
Вполне может быть (я бы поставил на это), что на реальных задачах и паттернах использования все эти нано-оптимизации дают прирост производительности в лучшем случае в считанные проценты. Более того, код оптимизированный под один миллион попугаев в секунду может работать хуже на других более полезных в реальной жизни задачах.
Итак, их тесты - фуфло, реальная польза от их работы неизвестна. Так-то, дорогие джавахейтеры.
Подозрительным выглядит демонстрацию тестов одного узла и отсутствие тестов кластера.
Но архитектура там сохранена и авторы "стрелянные воробьи", прирост всё равно должен быть ощутимым.
> Эти попугаи, которых в десять раз больше - не о чем. Миллион
> запросов в секунду с машины они могли получить при чтении очень
> маленьких не меняющихся данных из кэша в ОЗУ в пределах одной
> стойки.Очнись, современные SSD выдают 2.5 Гбайта в секунду и 300-800 тысяч IOPS с одной железки. 40Gbit на серваках уже не экзотика.
Текущий стек ядра что для блочных устройств, что для сети не может прокачать железо и его меняют/пробивают более короткие пути от приложения к железу. Процессоры быстрее не становятся, задержка прохождения данных через стек стала очень важна, чтобы была возможность обрабатывать данные на разных ядрах а не висеть на блокировках. NUMA уже много лет в каждом сервере. А ты толкуешь про чудесную java для таких нагрузок, которая с железом общается через тяжёлые обёртки над posix.
Java хороший, правильный инструмент, но не для системного софта. На java надо приложения писать а не хранилища для кластера/мейнфрейма
> На java надо приложения писать а не хранилища для кластера/мейнфреймаВидели мы те приложения, угу. Майнкрафт запускать - ещё не всякий дектоп потянет, а кулерами начинает выть так, как будто полёт на альфу центавра считает. Или тот же vuze - торренты покачать - 3х гигов памяти как не бывало. Spark запустишь - ещё гиг-полтора долой.
KDE столько ресурсов не жрёт, сколько одно жабье приложение.
> Очнись, современные SSD выдают 2.5 Гбайта в секунду и 300-800 тысяч IOPS
> с одной железки.Это где такие скорости? В лабораторных условиях, разве что.
У современных SSD 80000 IOPS - максимум.
> У современных SSD 80000 IOPS - максимум.А ты ынтырпрайзные SSD видал когда-нибудь? В PCI-E например втыкаемые. Они быстрые как ракета. Но правда и стоят они тоже как ракета.
>> У современных SSD 80000 IOPS - максимум.
> А ты ынтырпрайзные SSD видал когда-нибудь? В PCI-E например втыкаемые. Они быстрые
> как ракета. Но правда и стоят они тоже как ракета.Так и сравнивать их надо с пачкой саташных "коробочек", а не с одной. Учитывая, что рейд у них уже на борту и оптимизирован под конкретное железо - "пачка коробочек" с аналогичной производительностью окажется дороже.
> Итак, их тесты - фуфло, реальная польза от их работы неизвестна. Так-то,
> дорогие джавахейтеры.В тесте натянуто все. Упираются в сетевой IO, о влиянии дискового IO информации нет. Процент попаданий кэша и реалистичность запросов - информации нет.
Фактически тест прямого доступа к сетевой карте и нового эффективного фреймворка ручного распеределения тредов и аллокаторов по ядрам.
На счет Java vs C++Я думаю спорить незачем. С++ дефакто к сформирован коммьюнити разработчиков.
И за хрен знает сколько лет они так и не смогли договориться между собой буквально ни об одном стандарте до С11.Стандартизация есть обязательное условие для разработки проекта большим количеством людей. Стандартизация всего включая форматтинг кода.
Это печальный факт но потребовалось чтобы одна комания (Sun) сказала будет только так как мы сказали все кому не нравится - пшли вон. И их язык стал самым популярным. При том что он сначала задумывался как язык для всего включая кофеварку (абсолютно дебильная идея) что не стало мейнстримом языка.
К сожалению то что я прочитал в очередной раз продемонстрировало неприятие С++ программистами потребности в стандартах. Вы уже пользуетесь С11 но желание стандартизировать и унифиаировать совместную разработку это не порождает.
Но рынок софта показал что за стандартизацией всего и вся будущее.
Спорить об этом смысла нет.
> рассуждает о Java vs C++
> путает стандарт C++11 и C11
Это никак не меняет все мои доводы.
>> рассуждает о Java vs C++
>> путает стандарт C++11 и C11Чем больше циферка после С++XX и CXX - тем больше языки становятся похожи друг на друга. В конце концов придут к общему знаменателю(названию).
Вангую - щас "знатоки" вылезут будут за синтаксис языка демагогию разводить… (facepalm)
> Но рынок софта показал…
> Спорить об этом смысла нет.а вот тут согласен: о чём можно «спорить» с дешёвой глупой проституткой?
Кстати,Java Concurrency in 2015
New, asynchronous "shared-nothing" platforms and APIs like Vert.x and Play / Akka and Qbit have emerged. These platforms use a different concurrency model than the standard Java / JEE concurrency model of threading, shared memory and locking. New non-blocking concurrency algorithms have been published, and new non-blocking tools like the LMax Disrupter have been added to our toolkits. New functional programming parallelism has been introduced with the Fork and Join framework in Java 7, and the collection streams API in Java 8.
в общем, Кассандре можно тоже придать волшебного ускорительного пенделя при желании :)
А некоторые даже почти без генерации мусора обходятся, если цель есть такая : http://vanillajava.blogspot.ru/2015/09/low-latency-fix-engin...
