Мэйл хранит сессии в Tarantool тоже. Все хранимые процедуры, которые использует mail открыты в github.com/mailru/tntlua. Возможно это кому-то ещё пригодится. Если Вы напишете свои хранимки, постучитесь пожалуйста в список рассылки или мне, я добавлю вас в список коммиттеров на github — я лично очень хотел бы чтобы всё что делалось было open source.
Даже полгода назад у нас ещё был совсем другой «продукт».
А в целом, по-моему правильнее в Вашем случае написать свой обзор типа «почему Tarantool — @@%@#$», а не постить картинки.
Попробуйте найти подобный обзор любой современной nosql системы — днём с огнём не сыщешь. Вон про Моно один аноним решился написать, и то чуть не заклевали:
И ещё, от того, что в России вдруг все будут любить или не любить Tarantool мало что зависит, русская programming community замкнута на себе (мы в этом похожи на японцев), так что «втюхивать» ей что-то смысла просто нет.
Во-первых, когда вообще на это нужно смотреть: если у вас высокие нагрузки и есть очень горячие данные, которые кладут традиционную систему (MySQL, PostgreSQL, тот же Mongo).
При этом на железо деньги выкидывать совсем не хочется (и РСУБД можно масштабировать, прсото там выше издержки на запрос).
Хранение сессий, профилей, нотификаций и т.д.
Вы начинаете смотреть в сторону сначала Memcached, потом Redis, Citrusleaf и т.л.
Так вот ключевая возможность Tarantool — возможность на Lua реализовать свой pattern и бизнес-логику на сервере. Мы, вполне возможно, уступаем Redis по тем структурам, которые в него заложены — очереди, списки и т.д., но у нас есть возможность атомарно реализовать доступ к данным под конкретный проект, то есть что-то, что на структуры «из коробки» неудобно ложится.
Ну и плюс мы более тщательно подходим к надёжности данных, система изначально использовала Write Ahead Log, и была написана под транзакции.
У монго javascript. У нас Lua.
У монго данные в память могут не влезать. У нас пока такого нет.
У монго в коробке клластер. У нас кластер надо с помощью вспомогательных инструментов сооружать самим.
Мы ещё не доросли по функционалу до Монго. Но на signle-server у нас производительность существенно выше (как и у Редиса, кстати).
Одноклассники используют Tarantool как back-end к Project Voldemort, таким образом получают кластер.
В нашей архитектуре есть возможность реализовать ACID по принципу pay per use — то есть, эффекта на производительность запросов состоящих из одной команды поддержка acid не окажет. У нас уже есть write ahead log, и предусмотрена возможность отката последнего запроса. Осталось лишь расширить поддержку на несколько запросов.
Редис Сальваторе изначально написал для решения задачи, поставленной ему работодателем, потом стал делать full time. Hadoop — open source реализация Google BigTable, созданная в Yahoo, т.е. тоже на коммерческой основе.
Большинство open source проектов так или иначе спонсируются — сначала одним вендором, потом, если проект успешен, сообществом.
Интерес Мейл.Ру в *открытой* разработке:
— во-первых, это важный компонент инфраструктуры, т.е. чем выше его качество — тем лучше для mail.ru. Опять же, если проект будет успешен, значит вложенные именно в *открытую* разработку деньги потрачены не зря — они вернутся в виде communinty feedback, патчей и т.д
— во-вторых, это технологический маркетинг — вот, например, эта ветка «льёт воду на мельницу» распространения среди engineering community технологий mail.ru, просто понимания того что она делает — что для компании ориентированной на создание софта немаловажно.
slab_alloc_arena эффективно ограничивает память под данные (но не под индексы). Однако WALы могут быть даже при фиксировнном размере данных очень большими, если update rate высок.
launchpad содержит не только bugs, но ещё и например blueprints.launchpad.net/tarantool, а также questions, milestones, series и т.д. У нас можно достаточно легко понять над чем мы работаем и что войдёт в 1.4.4, к примеру — достаточно зайти на launchpad.
Это интегрировнная среда open source разработки, на ней хостится куча open source projects, такие как, например, Drizzle, MariaDB, и т.д. Это не отменяет факт того, что у drizzle есть drizzle.org а у mariadb есть аж два сайта — askmonty.org, mariadb.org.
Github — отличный хост для Git репозиториев, с возможностю интеграции с кучей сторонних инструментов, но как issue tracker явно слаб.
Вики — мы ещё есть на en.wikipedia.org/wiki/Tarantool, но в целом документцию мы пишем в DocBook, а Wiki для текущих заметок и того, что в документацию ещё не попало.
Ещё у нас есть русскоязычный список рассылки, и англоязчный список рассылки.
Надеюсь, голова не закружилось: примерно так устроен любой open source проект, просто проекты повзрослее хостят всё на собственном домене.
Идея с номерами такая. Для скорости работы с сервером, простоты репликации и т.п. задач, каждый объект имеет числовой идентификатор. Мы уже сейчас (вот в ближ. месяцы скорее всего) будем добавлять спец. таблицу, где будет сидеть отображение имя->номер. Таким образом во всех клиентах можно будет использовать спокойно имена, просто клиент при коннекте будет скачивать эту (маленькую) системную табличку себе.
При именовании обычном объектов возникают всякого рода грабли с невозможностью эти объекты модифицировать без поломки активных соединений использующих этот объект.
Наш аллокатор — сильно доработанный напильником аллокатор memcached.
Фрагментация памяти на наших нагрузках — 1% (это оч. низко).
Посмотреть инфу по фрагментации можно всегда в админке вызвав show slab.
У нас снимки похожи на редисовские, но они не 100% памяти жрут. У нас хитро сделана организация кортежей, нет счётчиков для маленьких кортежей, они копируются чаще, за счёт этого нет page splitов в таком количестве как у редиса при форке.
Диск для данных, которые не умещаются в память мы не юзаем. Но у нас есть чёткий лимит на память задаваемый в конфиге, так что если он вдруг перестал влезать в память, он не вырастет за её пределы и не уйдёт в своп.
Disk Store это интересная фича, мы ей займёмся, но не сейчас. Сейчас есть достаточно много интересных задач и без этого (например добавление индексов без дампа данных).
Репликация есть, асинхронная, конфигурируется динамиески. Вот дока:
tarantool.org/tarantool_user_guide.html#replication
А в целом, по-моему правильнее в Вашем случае написать свой обзор типа «почему Tarantool — @@%@#$», а не постить картинки.
Попробуйте найти подобный обзор любой современной nosql системы — днём с огнём не сыщешь. Вон про Моно один аноним решился написать, и то чуть не заклевали:
nosql.mypopescu.com/post/12466059249/anonymous-post-dont-use-mongodb
И ещё, от того, что в России вдруг все будут любить или не любить Tarantool мало что зависит, русская programming community замкнута на себе (мы в этом похожи на японцев), так что «втюхивать» ей что-то смысла просто нет.
При этом на железо деньги выкидывать совсем не хочется (и РСУБД можно масштабировать, прсото там выше издержки на запрос).
Хранение сессий, профилей, нотификаций и т.д.
Вы начинаете смотреть в сторону сначала Memcached, потом Redis, Citrusleaf и т.л.
Так вот ключевая возможность Tarantool — возможность на Lua реализовать свой pattern и бизнес-логику на сервере. Мы, вполне возможно, уступаем Redis по тем структурам, которые в него заложены — очереди, списки и т.д., но у нас есть возможность атомарно реализовать доступ к данным под конкретный проект, то есть что-то, что на структуры «из коробки» неудобно ложится.
Ну и плюс мы более тщательно подходим к надёжности данных, система изначально использовала Write Ahead Log, и была написана под транзакции.
У монго данные в память могут не влезать. У нас пока такого нет.
У монго в коробке клластер. У нас кластер надо с помощью вспомогательных инструментов сооружать самим.
Мы ещё не доросли по функционалу до Монго. Но на signle-server у нас производительность существенно выше (как и у Редиса, кстати).
Одноклассники используют Tarantool как back-end к Project Voldemort, таким образом получают кластер.
blueprints.launchpad.net/tarantool/+spec/speed-up-wal-write
Большинство open source проектов так или иначе спонсируются — сначала одним вендором, потом, если проект успешен, сообществом.
Интерес Мейл.Ру в *открытой* разработке:
— во-первых, это важный компонент инфраструктуры, т.е. чем выше его качество — тем лучше для mail.ru. Опять же, если проект будет успешен, значит вложенные именно в *открытую* разработку деньги потрачены не зря — они вернутся в виде communinty feedback, патчей и т.д
— во-вторых, это технологический маркетинг — вот, например, эта ветка «льёт воду на мельницу» распространения среди engineering community технологий mail.ru, просто понимания того что она делает — что для компании ориентированной на создание софта немаловажно.
launchpad содержит не только bugs, но ещё и например blueprints.launchpad.net/tarantool, а также questions, milestones, series и т.д. У нас можно достаточно легко понять над чем мы работаем и что войдёт в 1.4.4, к примеру — достаточно зайти на launchpad.
Это интегрировнная среда open source разработки, на ней хостится куча open source projects, такие как, например, Drizzle, MariaDB, и т.д. Это не отменяет факт того, что у drizzle есть drizzle.org а у mariadb есть аж два сайта — askmonty.org, mariadb.org.
Github — отличный хост для Git репозиториев, с возможностю интеграции с кучей сторонних инструментов, но как issue tracker явно слаб.
Вики — мы ещё есть на en.wikipedia.org/wiki/Tarantool, но в целом документцию мы пишем в DocBook, а Wiki для текущих заметок и того, что в документацию ещё не попало.
Ещё у нас есть русскоязычный список рассылки, и англоязчный список рассылки.
Надеюсь, голова не закружилось: примерно так устроен любой open source проект, просто проекты повзрослее хостят всё на собственном домене.
При именовании обычном объектов возникают всякого рода грабли с невозможностью эти объекты модифицировать без поломки активных соединений использующих этот объект.
Фрагментация памяти на наших нагрузках — 1% (это оч. низко).
Посмотреть инфу по фрагментации можно всегда в админке вызвав show slab.
У нас снимки похожи на редисовские, но они не 100% памяти жрут. У нас хитро сделана организация кортежей, нет счётчиков для маленьких кортежей, они копируются чаще, за счёт этого нет page splitов в таком количестве как у редиса при форке.
Диск для данных, которые не умещаются в память мы не юзаем. Но у нас есть чёткий лимит на память задаваемый в конфиге, так что если он вдруг перестал влезать в память, он не вырастет за её пределы и не уйдёт в своп.
Disk Store это интересная фича, мы ей займёмся, но не сейчас. Сейчас есть достаточно много интересных задач и без этого (например добавление индексов без дампа данных).
Но его немножко надо вытащить наружу, т.к. он писался для тестирования в основном.
Пример использования этого драйвера — в test_suite.py, в test/lib.
Проект полностью открыт, так что коммиты которые делают driver подключаемым как питоновский модуль приветствуются.
www.xtranormal.com/watch/6995033/mongo-db-is-web-scale