В нашей архитектуре есть возможность реализовать 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 это интересная фича, мы ей займёмся, но не сейчас. Сейчас есть достаточно много интересных задач и без этого (например добавление индексов без дампа данных).
Рассказать не получится, могу вместе с Вами попробовать прикрутить. Например на DevConf. Слишком там код быстро меняется, надо по месту понимать что и как патчить.
Тарантул — имеет копию данных на диске (уже очень давно), и она не ломается, если сервер или машина падает.
Если Вы цените Ваши данные — думаю это важно.
То же самое с репликацией — в Tarantool она уже довольно давно.
Протокол в Tarantool бинарный, в Редисе текстовый — соотв. бинарный быстрее.
Хранимые процедуры в Tarantool пишутся один раз, компилируются один раз, выполняются много раз, в Redis'е только недавно появился eval, то есть каждый раз компилируется.
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
Если Вы цените Ваши данные — думаю это важно.
То же самое с репликацией — в Tarantool она уже довольно давно.
Протокол в Tarantool бинарный, в Редисе текстовый — соотв. бинарный быстрее.
Хранимые процедуры в Tarantool пишутся один раз, компилируются один раз, выполняются много раз, в Redis'е только недавно появился eval, то есть каждый раз компилируется.
Советую использовать ветку 'master-stable'