Comments 22
После прочтения захотелось в живую послушать.
Очень многое из сказанного прямо сразу хочется прогнать через тесты, потому что воспринимается очень спорным. Но в целом интересно, особенно этапы развития показывающие на чём нужно сосредоточиться в таких системах.
kostja, в статье упоминалась дороговизна обращения к сети из-за необходимости обращения к ядру ОС. Не рассматривались ли различные механизмы zero-copy вроде intel dpdk или freebsd netmap? Или же современных возможностей мультиплексирования вполне достаточного и применение этих механизмов ничего не дает?
Tarantool — открытый проект, и работает на стандартном оборудовании, на куче операционных систем и железа. Нам нужна архитектура, которая была бы одинаково эффективна при желании в том числе на Windows. Но сама по себе идея использоавть Intel DPDK очень здравая, есть такая СУБД Scylla, она сделана по очень похожей на нас архитектуре, там есть поддержка Intel DPDK. Рано или поздно придёт эра unikernel и эта проблема будет решена на корню.
я наверное глупость спрошу, но почему такой подход, синглтредет обработка очереди транзакций, применим только для Memory-СУБД?
Пару раз был на докладах по Тарантулу, и каждый раз попадал на какой-то, простите, маркетинговый булшит.
А вот это — прям офигительно. Лучшее, что я читал по СУБД. Обожаю такие доклады, в которых люди могут сложные вещи объяснить простым человеческим языком. Я ничего не понял, но ты достучался до моего сердца, бро. И вот такие именно доклады, а не рекламные, побуждают к использованию продукта.
Вот слушаю: свои легкие процессы — акторы, обмен сообщениями, аллокаторы, gc.
Сразу вспомнилось десятое правило Гринспена. И все время задаюсь вопросом, чего они такого сделали, чего нет в Erlang? Только скорость?
Спасибо, прослушал полностью, было интересно!
Сразу вспомнилось десятое правило Гринспена. И все время задаюсь вопросом, чего они такого сделали, чего нет в Erlang? Только скорость?
Спасибо, прослушал полностью, было интересно!
Ни разу не erlang'ист, но тут во главу угла поставлена производительность и memory footprint (второе, пожалуй, даже нужнее для in memory db). Не уверен, что в Erlang можно так же гибко управлять памятью, как в С, добиваясь максимального процента попадания в L3-кэш и максимально плотного размещения на страницах памяти.
Замечательный доклад. В силу специфики, на работе сейчас приходится самому реализовать низкоуровневый слой, на подобие, как у баз данных, для поддержки своих структур, так как появление готовых и легких решений,, чувствую, в ближайшее время ждать не стоит. Так вот, в плотную пришлось столкнуться с вещами которые описываются в докладе и самому рыть информацию из разрозненных источников, которых, к сожалению, очень мало, особенно на русском. Человек доходчиво, правда очень фрагментарно (в силу ограничения времени), дает теорию построения баз данных, причем с инженерной точки зрения, что очень порадовало.
P.S. Теперь самому интересно, почему в STL нет поддержки B+ деревьев, ведь в силу плотности упаковки данных, минимуме оверхеда, и с учетом устройства современных CPU данных структуры могут быть гораздо быстрее и удобнее.
P.S. Теперь самому интересно, почему в STL нет поддержки B+ деревьев, ведь в силу плотности упаковки данных, минимуме оверхеда, и с учетом устройства современных CPU данных структуры могут быть гораздо быстрее и удобнее.
Есть вот такое например: https://isocpp.org/blog/2013/02/b-tree-containers-from-google
https://code.google.com/archive/p/cpp-btree/
https://code.google.com/archive/p/cpp-btree/
Спасибо большое за ссылки. Я в курсе существования версии B-tree от Google. Когда я изучал возможность применения данной библиотеки, отзывы были противоречивые. В частности, где-то на форумах читал что в ней есть ошибки приводящие к потере консистентности. Может быть уже поправили.
Кстати, может быть вы, как эксперт, можете поделиться какими-нибудь ссылками по теории построения баз данных на низком уровне, с точки зрения инженера. Интересует уровень ниже таблиц, индексов и SQL, реализующий само транзакционное хранилище.
Кстати, может быть вы, как эксперт, можете поделиться какими-нибудь ссылками по теории построения баз данных на низком уровне, с точки зрения инженера. Интересует уровень ниже таблиц, индексов и SQL, реализующий само транзакционное хранилище.
Garcia-Molina H., Ullman J.D., Widom J. / Гарсиа-Молина Г., Ульман Дж.Д., Уидом Дж. — Database Systems. The Complete Book / Системы баз данных. Полный курс
Вот спасибо вам большое, вроде как-раз то что нужно. Пойду покупать.
А как вы определяете процент попадания в кэш процессора? Я так понимаю, что чисто интуитивно или есть какие-то интсрументы?
Есть множество разных ситуаций, которые так или иначе выражаются в одном выводе – локи не компоузебл
facepalm >_<
Sign up to leave a comment.
Что особенного в СУБД для данных в оперативной памяти