Есть, таки, в сети мудрые люди.
Интересная точка зрения на ситуацию с развитием и перспективы СУБД и обработки данных из СУБД.
Вообще, такой большой по размеру вменяемый текст на LOR-е — это очень большая редкость. Тем более от анонимного автора. Просто феномен какой-то 🙂
Привожу сюда, это интересно
запись из сетей: https://plus.google.com/+YuriZhloba/posts/APTcyafAvoT
сам комент https://www.linux.org.ru/news/mozilla/12291462/page9#comment-12301917
текст собственно
Тут возникло некоторое непонимание. Я говорил о том, что аналитика больших данных переходит на С++. Прозвучало название PostgreSQL, и я сказал, что ему тоже будет полезен переход на С++. И дальше мы заговорили за СУБД. Тут мне надо пояснить, чтобы все понимали, о чем мы говорим.
В базах данных есть два больших направления — это OLTP и аналитика. Направления очень различных. И, хотя на выходе один и тот же SQL/JDBC, пот капотом используются совсем разные решения. Например, построчное хранение в OLTP и поколоночное в аналитике. Динамичные структуры данных в OLTP и статичные в аналитике и т.д.
Далее. Были несколько периодов развития баз данных, на каждом из которых возможности аппаратных средств определяли программную архитектуру. То, что мы называем традиционными СУБД, а это MySQL, PostgreSQL, MSSQL, Oracle, DB2 и т.д. — это всё решения, которые возникли и развились тогда, когда БД была надстройкой над медленным диском, поэтому подсистема ввода-вывода решала всё. В этом случае не так уж важно, с какой скоростью обрабатывается отдельный элемент данных, если потом мы ждем следующую страницу индекса с диска «целую вечность». Поэтому интерпретируемый SQL рулил. Поэтому Java-middleware взлетело.
Но ситуация изменилась. Во-первых, оперативной памяти стало достаточно много, чтобы датасеты помещались в ней целиком и сразу существующая архитектура стала поперек горла. Сначала стали отказываться от SQL-надстройки, а затем, под горячую руку, и от транзакций. Появились высокоскоростные in-memory БД, в которых скорость обработки данных в памяти уже имеет решающее значение. И SQL стал компилируемым: так делают MemSQL и Apache Spark. Но вылезла другая проблема…
Сейчас ввод-вывод больше не является узким местом. SSD-шки успешно штурмуют второй GBps. Датацентры дают 10Gbps сетку и пичкают машины SSD-шками. Народ, работающий со Spark/Hadoop внезапно обнаружил, что узким местом стала сериализация данных при переходе от диска к памяти и обратно. Когда данные представлены в виде объектов на куче (а как же еще?), сериализацию невозможно сделать достаточно быстрой, чтобы использовать все возможности современного IO. Но это еще не вся беда…
Сейчас быстрой памяти относительно много. На сервера ставят 256GB и более. 512 не редкость, да и конфигурации с 1TB уже не экзотика. А за этим терабайтом памяти стоит SSD-массив на 10-100TB. Классические кучи на таких объемах становятся катастрофически медленными. Как оказалось, классическая куча для объектов на основе ссылок оказалась немасштабируемой абстракцией. И, если дизайн языка прибит гвоздями к куче, как это сделано в Java, Haskell и OCaml, при переходе к ручному управлению памятью мы теряем все «батарейки». Такой язык нам больше ничего не может предложить. Тут нужен язык, в котором абстракции памяти являются гражданами первого класса. Это С++, Rust и D.
СУБД, которые адресуют эту проблему, называют себя NewSQL. Они хотят соединить OLTP и аналитику в рамках одного решения и сразу создаются с учетом возможности работы в большой памяти и распределенном режиме (предполагающем интенсивный IO). PostgreSQL, при всем моем уважении к нему, в текущем виде на этот поезд не вспрыгнет. MongoDB совсем не в этой категории, как и RethinkDB. Последнюю можно было бы смело писать на лиспе, как и сделал автор Datomic.
Александр
27.01.2016 в 13:13И, если дизайн языка прибит гвоздями к куче, как это сделано в Java, Haskell и OCaml, при переходе к ручному управлению памятью мы теряем все «батарейки».
Насчет гвоздей не согласен. Уже сейчас люди используют offheap вовсю, всякие direct-буфера для этих целей. Да и к тому-же оптимизации на escape-анализе типа alocation elimination никто не отменял.
А вообще, начиная с 10 версии (предположительно) в java появятся value-типы (гуглить проект Valhalla) — эти самые отодранные от кучи pojo (добавляете одно ключевое слово к вашему классу бизнес объекта, получаете нехилый boost).
В 9 версии будут VarHandle — в некоторых случаях легальная замена Unsafe (как раз для offheap подходит).
Также на горизонте проект Panama — убер быстрая замена JNI (по скорости будет как работа с напрямую с памятью).
Про внутренности ghc не в курсе, но не очень понимаю что мешает такому высокоабстрактному языку как Haskell заиметь объекты вне хипа. OCaml более приземлен, но и тут все может изменится.
Михаил Павлов
27.01.2016 в 17:34можешь написать тут в паре фраз что это вообще такое ?
нагуглил это http://openjdk.java.net/projects/valhalla/
ту не понятно что к чему.
java останется java ? со своим JIT ? ой, еще вопрос. я знаю что java VM существует много, не все они развиваются также быстро как развивается стандарт.
с ними что будет ? они застрянут на старых версиях java ?
Александр
27.01.2016 в 18:17Valhalla — комплексная фигня. Подпроекты:
* Value Types — классы, которые ведут себя как примитивные типы (гоняются через стек, инлайнятся в массивы, не учитываются GC).
* Generic Specialization — базируется на Value Types. Становится возможным писать так Collection вместо Collection — никакого боксинга, и данные размещаются непосредственно в памяти-контейнера, а не мыссивы ссылок, как сейчас. Дает сумашедшие приросты производительности при итерировании (memory prefetcher friendly).
* Enhanced volatiles — это больше про внутреннюю кухню jvm. Ну и легальная альтерантива Unsafe.compareAndSwap()
Valhalla — самое большое нововведение со времен java 6. Позволит писать код сравнимые по производительности с C, без ацких нагромождений массивов примитивов на кажде поле псевдо-pojo (так сейчас делают highload на java). Халявная абстракция, короче.
java останется java — да. У Oracle в стратегии развиятия jvm на 20 лет вперед прописано — compatiple with old jars. Насколько мне известно текущая реализация Valhalla ничего не ломает.
Альтернативные jvm постоянно в роли догоняющих, тут ничего не поделаешь. С HotSpot тяжело тягаться, особенно в области передовых разработок. Мне известны 2 альтернативные комерческие jvm, которые в чем-то hotspot обгоняют (уверен есть еще). Например zing от azul — решили проблему GC-STW утроенным перерасходом памяти (они и железо свое продают вроде). Excelsior JET — статическая java-компиляция (вкрапления jit прямо в код) + просто в целом быстрее работает. Но законодатель тут — Oracle и все нехотя будут за ним плестись. Думаю тяжело им будет поддержать нововведения Valhalla (изменения на сверхнизком уровне архитектуры JIT).
Михаил Павлов
27.01.2016 в 19:10ну вот первые три пункта это похоже на обычный ffi wraping например тут http://luajit.org/ext_ffi_api.html ffi.new делает любую структуру но следит за ней GC если это комбинация примитивных известных типов, а чтобы самом у управлять способом GC юзаешь ffi.gc…
для JS это тоже есть например в asm.js сделаи свой вариант.
Есть node-ffi show usage link https://habrahabr.ru/post/136185/
тоже всё руками можно. так то идея старая.
для Java тоже должна быть ffi, я уверен. и понятно что совместимым образом можно делать тоже самое.
Но тут я думаю не то же самое. Тут типа в язык вточили а не в либу ?
Александр
27.01.2016 в 19:40Нет, то что ты описал — это проект Panama. А Valhalla это про работу с объектами как со значениями, которые и на низком уровне ведут себя как значения. «Codes like a class, works like an int!» D
Можно будет писать
вместо