Comments 30
Если грубо упростить, развитие индустрии заключается в придумывании на каждом витке новых терминов.
— «Эра NoSQL позади»
— Что, опять?
— «один из лучших выборов — платформа…, СУБД и сервер приложений в одном флаконе»
— Что, опять?
— Все NoSQL-решения добавляют SQL, просто не все это ещё успели сделать. Все SQL-решения добавляют NoSQL, просто не все это ещё успели сделать.
— Что, опять?
— «Борьба идёт за байты и инструкции, и сложный код просто не может работать эффективно.»
— Что, опять?
— «Эра NoSQL позади»
— Что, опять?
— «один из лучших выборов — платформа…, СУБД и сервер приложений в одном флаконе»
— Что, опять?
— Все NoSQL-решения добавляют SQL, просто не все это ещё успели сделать. Все SQL-решения добавляют NoSQL, просто не все это ещё успели сделать.
— Что, опять?
— «Борьба идёт за байты и инструкции, и сложный код просто не может работать эффективно.»
— Что, опять?
Это вообще характерное для любого явления развитие, не только в IT.
Константин Осипов работает в области баз данных уже несколько лет, а сейчас разработчик собственного NoSQL-решения. В Mail.RU Tarantool обслуживает сотни тысяч запросов в секунду. Мне кажется, что его мнение основано всё таки не на голословных утверждениях, а на реальной оценки ситуации.
А я думал, что NoSQL сейчас это нереляционные базы данных, хоть и в названии есть SQL.
На снимке экрана код на Lua, хотя в статье про него ни слова
Ну так встроенный язык в Tarantool — Lua.
Приложения под Tarantool пишутся на LuaJIT
Также имеется возможность написания модулей на C/C++ [1]. При помощи данного API можно подключить любой другой язык программирования или библиотеку, было бы желание. В частности, наш memcached[2] написан на сишном API.
[1]: tarantool.org/doc/reference/capi.html
[2]: github.com/tarantool/memcached
// Disclaimer: tarantool.org contributor
[1]: tarantool.org/doc/reference/capi.html
[2]: github.com/tarantool/memcached
// Disclaimer: tarantool.org contributor
Мне кажется, Non-Volatile Memory может очень сильно поменять ландшафт систем хранения данных, и систем обработки данных в целом.
это все баззворд очередной. По факту у нас сейчас в реальном мире есть иерархия памяти. Более быстрая — волатильна, более медленная персистентна. То, что мы сейчас называем оперативной памятью — ну да, волатильна. Но персистентность в этом месте стоит денег. Мы ведь с тобой понимаем, что чем ближе память к процу, тем она быстрее и дороже, а чем дальше — тем дешевле.
Так что я не соглашусь — с приходом NVM поменяется только свойства одного конкретного слоя, а не всей иерархии. Чтобы поменять ландшафт, нужно менять принципы, менять всю иерархию, а не только свойство конкретного слоя в нем.
Так что я не соглашусь — с приходом NVM поменяется только свойства одного конкретного слоя, а не всей иерархии. Чтобы поменять ландшафт, нужно менять принципы, менять всю иерархию, а не только свойство конкретного слоя в нем.
Если я верно понял весь сыр бор о том как правильно использовать большие обьемы данных размещенных в оперативной памяти. Иначе говоря, они уже уперлись в верхний потолок настолько, что выигрыш на сокращении таких издержек оказывается значимым.
То есть да, для разработчика БД в целом ничего не меняется. Все сливки для тех кто делает инструменты для разработчика. И когда говорят о структурном изменении какого то слоя иерархии — для них, тех кто делает инструмент, равнозначно изменению ландшафта в целом.
То есть да, для разработчика БД в целом ничего не меняется. Все сливки для тех кто делает инструменты для разработчика. И когда говорят о структурном изменении какого то слоя иерархии — для них, тех кто делает инструмент, равнозначно изменению ландшафта в целом.
согласен. Зааффектятся именно разработчики инструментов, условно говоря, того же MySQL или Tarantool. Они будут делать изменения именно в изменившемся слое (например, RAM) и соседних слоях.
Тем не менее, практически невозможно оценить impact абстрактного изменения памяти на абстрактную (неизвестно какую) NVM :)
Тем не менее, практически невозможно оценить impact абстрактного изменения памяти на абстрактную (неизвестно какую) NVM :)
Как раз мне кажется, что изменится поход. Зачем городить SQL запросы, если, грубо говоря, все состояние системы, удобно разложенное в родные рантаймовые структуры типа списков и мапов — durable из коробки.
Я говорю, может быть, не о 3d xpoint, который пока 1) помедленнее обычной памяти, 2) имеет чуть другой интерфейс, чтобы просто выбросить всю старую память и заменить на него. Но в перспективе 10, ну 15 лет, мне кажется, очевидно, что железячники закроют этот технологический зазор, и брать волатильную память не будет никакого смысла, потому что она будет стоить столько же и работать не быстрее.
Я говорю, может быть, не о 3d xpoint, который пока 1) помедленнее обычной памяти, 2) имеет чуть другой интерфейс, чтобы просто выбросить всю старую память и заменить на него. Но в перспективе 10, ну 15 лет, мне кажется, очевидно, что железячники закроют этот технологический зазор, и брать волатильную память не будет никакого смысла, потому что она будет стоить столько же и работать не быстрее.
за 10-15 лет столько всего может произойти, что ппц. Вот пришли лет 5 назад на рынок SSD, о которых 10 лет назад никто не слыхивал. Они на один-два порядка быстрее HDD десятилетней давности в разных сценариях. И что, разве мы можем сказать, что как-то принципиально изменились внутренности инструментов? Да нифига! Безусловно, разработчики инструментов и фреймворков адаптировали свои решения, но разве это было прямо-уж-так-заметно?
Технологии под капотом там практически одинаковые. Платформа позволяет заменить несколько решений сразу, например, недавно мы сделали Memcached plugin, который реализует бинарный протокол Memcached для Тарантула.
Документация
Tarantool does not support the binary protocol of Memcached. If top performance is a must, Tarantool's own binary protocol should be used.
Где искать?
github.com/tarantool/memcached
вчера выложили, новая реализация бинарного протокола на новом plugin api
пока ещё сыро :)
вчера выложили, новая реализация бинарного протокола на новом plugin api
пока ещё сыро :)
>>> В качестве бонуса пользователь получает все остальные наши возможности — мастер-мастер репликацию и подключаемые движки хранения, например.
Года два назад я слышал на каком-то докладе про то, что в тарантуле уже есть дисковый движок. Но по отзывам тех кто его пробовал — работа с ним была нестабильной и его использование в продакшене из-за этого было немного стремновато. Как сейчас с ним обстоят дела? Он уже стабилен и зарелизен или пока еще нет?
И еще вопрос про репликацию: мастер-мастер репликация — достаточно сложная, но нужная фича для отказоустойчивой работы системы. Правильно ли я понимаю, что тарантул умеет синхронно реплицировать данные между узлами, и в случае выхода из строя скажем одного из трех узлов продолжать работу и писать данные на оставшиеся два, и данные при этом остаются всегда консистентными?
Года два назад я слышал на каком-то докладе про то, что в тарантуле уже есть дисковый движок. Но по отзывам тех кто его пробовал — работа с ним была нестабильной и его использование в продакшене из-за этого было немного стремновато. Как сейчас с ним обстоят дела? Он уже стабилен и зарелизен или пока еще нет?
И еще вопрос про репликацию: мастер-мастер репликация — достаточно сложная, но нужная фича для отказоустойчивой работы системы. Правильно ли я понимаю, что тарантул умеет синхронно реплицировать данные между узлами, и в случае выхода из строя скажем одного из трех узлов продолжать работу и писать данные на оставшиеся два, и данные при этом остаются всегда консистентными?
Привет!
София сейчас по нашим оценкам достаточно хорошо работает с объёмом данных до 500ГБ на инстанс, сейчас пытаемся сделать так чтобы нормально работала с терабайтными объёмами. Из существенных ограничений — пока нет вторичных ключей. Многокомпонентные ключи есть. В проде в mail.ru пока нигде нет — нам нужны как раз терабайтные объёмы, пытаемся запустить.
Мастер-мастер асинхронный, синхронный делаем в 1.7, который должен выйти в этом году.
София сейчас по нашим оценкам достаточно хорошо работает с объёмом данных до 500ГБ на инстанс, сейчас пытаемся сделать так чтобы нормально работала с терабайтными объёмами. Из существенных ограничений — пока нет вторичных ключей. Многокомпонентные ключи есть. В проде в mail.ru пока нигде нет — нам нужны как раз терабайтные объёмы, пытаемся запустить.
Мастер-мастер асинхронный, синхронный делаем в 1.7, который должен выйти в этом году.
Разве на объемах 500ГБ на инстанс не выгоднее использовать шардированную реляционную или объектно-реляционную СУБД схожих объемов на инстанс, настроенную чтобы иметь большой дисковый кеш в ОЗУ?
По моему опыту, все inmemory db не дают таких же ACID гарантий как РСУБД, даже если СУБД используется как DataStore позади inmemory db
По моему опыту, все inmemory db не дают таких же ACID гарантий как РСУБД, даже если СУБД используется как DataStore позади inmemory db
А в чем разница Софии относительно LevelDB/RocksDB? Она работает поверх сырого блочного устройства или тоже поверх файловой системы?
> Мастер-мастер асинхронный
а это как?
а это как?
Все NoSQL-решения добавляют SQL, просто не все это ещё успели сделать.
Декларативный язык запросов и обновления упрощает работу с БД.
Но не то чтобы все, но многие… crate.io база на основе Elasticsearch — SQL JOINs are nearly ready
Sign up to leave a comment.
Эра NoSQL позади