Комментарии 32
Имхо, их некорректно сравнивать. Тарантул лучше сравнивать с redis. Один из разрабов тарантула на докладе делал упор на то, что тарантул быстрее, поскольку все данные держит в памяти.
Redis тоже прикольный — держит в памяти и периодически дампится на диск. Причем это можно отключить и преимущества сохранятся. А ввиду нашей энергетической нестабильности, дампы — это полезная штука)
Согласен. Внимание вопрос: чем Тарантул лучше Редиса? :)
Имхо редис намного более гибкое, быстрое и удобное решение.
Конечно если появятся реальные адекватные тесты Тарантул vs Редис, будет намного объективнее и справедливее. :)

p.s. тесты делать не буду ибо в Тарантула даже не верю )))
метод хранения в MongoDb BSON, в тарантул — hash/slab
В монго так же можно наклаывать индексы, но выбор из Tarantool за счет hash index знаительно быстрее.

По сравнению с редисом, Tarantool — более гибкое и производительное решение. Сравните даже возможности с тем же портом под PHP. Единственное, что нет в Tarantool — это списки, с помощью которых реализуют очереди. Но присутствует fider — собственный сервер очередей (честно говоря я пока его еще не копал, но надеюсь восполнить пробел в ближайшем будущем).

тесты производительности разных NoSQL готовлю к Hi++ (если пригласят выступать), так что выложу в скором будущем.
Тема тестов — это отдельная тема и тут нельзя подходить ламерски. Например, разработчики HandlerSocket утверждали, что производительность HandlerSocket больше, чем мемкеш, однако мои тесты этого не подтвердили. Сказать, что они не правы — я тоже не могу, так как тестировалось не только на разном железе, но и разными методами.

Производительность tarantool соизмерима с мемкешом, а Монго от мемкеша отстает. Это мои личные тесты.
НЛО прилетело и опубликовало эту надпись здесь
Наш аллокатор — сильно доработанный напильником аллокатор memcached.
Фрагментация памяти на наших нагрузках — 1% (это оч. низко).
Посмотреть инфу по фрагментации можно всегда в админке вызвав show slab.

У нас снимки похожи на редисовские, но они не 100% памяти жрут. У нас хитро сделана организация кортежей, нет счётчиков для маленьких кортежей, они копируются чаще, за счёт этого нет page splitов в таком количестве как у редиса при форке.

Диск для данных, которые не умещаются в память мы не юзаем. Но у нас есть чёткий лимит на память задаваемый в конфиге, так что если он вдруг перестал влезать в память, он не вырастет за её пределы и не уйдёт в своп.

Disk Store это интересная фича, мы ей займёмся, но не сейчас. Сейчас есть достаточно много интересных задач и без этого (например добавление индексов без дампа данных).
НЛО прилетело и опубликовало эту надпись здесь
1) существует репликация master-slave
2) запись на диск происходит соседним потоком, а не процессом (через fork) как в редисе
по какому алгоритмы в  tarantool происходит я не знаю, знаю как в редисе:
раз в 5 мин — если был хоть один set
раз в 1 мин если было 100 сетов
раз в 1сек если было 3000
каждые 300 000 сетов
может быть итерацию в 30 или 15 сек я пропустил…

по логам тарантула, сохранение после каждого инсерта, но не факт что именно после каждого, скорее алгоритм очень похожий на редисовский или период сохранения задается конфигом.

Лично, когда я разрабатывал похожее решение — у меня был простой подход,
сохраняем на диск соседним потоком каждую сек — если были внесены изменения.
Пожалуйста, скомпилируйте Wibdows-бинарник php_tarantool.dll этого модуля для php5.3.6, php5.2.17 и php4.4.9
сам Тарантул под Win не скомпилить, и даже под MacOx.
Это чисто серверное решение.
Сам тарантул пусть на сервере и сидит, там фри-бсд.
А, клиентскую-то часть хотелось бы на винде гонять.

Я использую php для запуска из-под FAR простеньких скриптов для командной строки.
очень не хватает простого хранилища key-value.

я обычно использую для этого кучу txt-файлов (что жутко неудобно).
ясно, к сожалению у меня винды нет…
и компилить под нее я не умею.

это не первый мой модуль, и не первая подобная просьба ;)
Есть, лежит в test/lib
Но его немножко надо вытащить наружу, т.к. он писался для тестирования в основном.

Пример использования этого драйвера — в test_suite.py, в test/lib.

Проект полностью открыт, так что коммиты которые делают driver подключаемым как питоновский модуль приветствуются.
Ужжос. Без констант код прекращается в тихий, нечитаемый, плохо поддерживаемый ужас.
Все ID, номера и тп — вынести в константы, файл констант держать рядом с конфигом базы, и многоаршинные комментарии что не забыть меняя одно обновить другое.
Иначе — привет проблемы.
это комментарий к примеру или исходникам?
все константы в исходниках в *.h

#define TARANTOOL_TIMEOUT 5 // sec
#define TARANTOOL_DEF_PORT 33013
#define TARANTOOL_ADMIN_PORT 33015

#define TARANTOOL_DEF_HOST "localhost"
#define TARANTOOL_BUFSIZE 256

#define TARANTOOL_INSERT 13
#define TARANTOOL_SELECT 17
#define TARANTOOL_UPDATE 19
#define TARANTOOL_DELETE 20
#define TARANTOOL_PING 65280

#define TARANTOOL_REQUEST_ID 8

#define TARANTOOL_OP_ASSIGN 0
#define TARANTOOL_OP_ADD 1
#define TARANTOOL_OP_AND 2
#define TARANTOOL_OP_XOR 3
#define TARANTOOL_OP_OR 4
typedef struct {
uint32_t type;
uint32_t len;
uint32_t request_id;
} Header;

typedef struct _tarantool_object {
zend_object zo;
char * host; // tarantool host
int port; // tarantool port
int bodyLen; // body len from tuples header
int countTuples; // count tuples
int readedTuples; //
int readed; // readed byte
uint32_t errorcode; // error code
php_stream * stream;
} tarantool_object;

#define HEADER_SIZE sizeof(Header)

typedef struct {
uint32_t count;
u_char data[];
} Tuple;

// sizeof(namespaceNo) + sizeof(flag) + sizeof(tuple.count)
#define INSERT_REQUEST_SIZE 12
typedef struct {
uint32_t namespaceNo;
uint32_t flag;
Tuple tuple;
} InsertRequest;

вроде как для чтения кода более менее понятно…
Я не об этом!

$tuple = array(1, 'x','abd', 1023 );
$res = $tnt->insert(0,$tuple);
var_dump($res);

что такое 0 в инсерте?
что означает
$tuple[0]?
$tuple[1]?
$tuple[2]?
$tuple[3]?

А если добавим поле между 1м и 2м в один прекрасный момент?
НЛО прилетело и опубликовало эту надпись здесь
$tnt->inc(0,1,3,-1);

Это write-only семантика. Поддерживать такое — убицца веником.
Именованные константы к этому надо сбоку пристраивать.
Идея с номерами такая. Для скорости работы с сервером, простоты репликации и т.п. задач, каждый объект имеет числовой идентификатор. Мы уже сейчас (вот в ближ. месяцы скорее всего) будем добавлять спец. таблицу, где будет сидеть отображение имя->номер. Таким образом во всех клиентах можно будет использовать спокойно имена, просто клиент при коннекте будет скачивать эту (маленькую) системную табличку себе.
При именовании обычном объектов возникают всякого рода грабли с невозможностью эти объекты модифицировать без поломки активных соединений использующих этот объект.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.