Уникальные возможности Tarantool

tarantool get --index 0 --space 0 --key 42 не сложнее чем select * from table where id = 42. это как сравнивать русский и английский языки.

Redis и Hadoop изначально были opensource и только потом получили поддержку VMWare и Cloudera.

Я все полгода, что знаю, думал о пауках :)

и я тоже :)

а логотип давно надо было придумать :)

Кстати, на счет монго — говорил с одним приятелем (гуру от разработки) — говорит, пробовали этот монго и отказались. Ну т.е. не то чтобы совсем отказались, но в нем хранятся только некритичные и/или временные данные, т.к. надежность и целостность у него в заднице. Если реплицировать на кучу машин — то да, но на 1—2 просто опасно.
Собственно, он вроде и проектировался как раз для больших репликаций, так что тут сложно сказать баг это или фича, но как есть…

Спасибо.
Просто есть планы сделать один проект, который, надеюсь, будет highload :) И сейчас как раз думаю над тем, что на чем реализовывать.

Из всего вышесказанного сделал предвариттельный вывод, что сессии и очереди событий (т.е. то что по факту запрашивается исключительно по ключу) лучше хранить в redis, а вещи вроде юзер-профайлов (которые чаще всего запрашиваются по ключу, но иногда нужен и поиск по другим полям) — в тарантуле.
Ну и для некоторых вещей РСУБД.

А как у тарантула с репликацией?

А как с CAP? Храним сессии в Хабаровском ЦОД'е, который не успел целиком зареплицироваться в Новосибирский, упал под ударом молнии, пользователь получает сообщение «подождите, ждём восстановления ХЦОД» или «ваша сессия не установлена»?

а при чем тут nginx? Там немного другой, как мне кажеться, сценарий использования. Да и Lua они тоже не используют. И судя по очень дискутирующей и в чем-то провокационной статье Игоря, там была совсем в другом проблема (а точнее — просто несогласованость с архитектурой nginx-а). При этом заметьте, JS не ограничиваеться именно v8, а статья Игоря как раз про встраивания не языка а аконкретного движка в нгинкс. Так что пока Вы не ответили на мой вопрос :)

Если бы я занимался разработкой in-memory databases, я бы лучше ответил на этот вопрос. Но я потребитель — и я возмущён медлительностью.

Попробую повторить вопрос, где вы увидели эту смешную цифру?

Для начала — Tokyo Tyrant базируется на Tokyo Cabinet, у которого есть 4-5 совершенно разных вариантов организации данных со своими плюсами и минусами. О которых из них мы говорим?

Мы тестировали большинство хранилищ на очень банальной задаче: есть ключ (например, 128-битный хэш), для него нужно хранить строчку байт на 100-200 и делать expiration — выкидывать строчки, к которым не обращаются, скажем, в течение 3 суток. Объем — порядка 5-7 млрд. строчек в сутки, ~70-80% уникальные по ключам, т.е. в среднем около 50-80 тысяч записей в секунду. Чтение при этом пренебрежимо малое — в пике несколько тысяч чтений в минуту, в среднем — порядка сотен. Общий объем хранилища таким образом что-то чуть меньше терабайта в сутки, за 3 суток — соответственно, под 3 терабайта.

Redis бодро начал, но производительность довольно быстро (через час-два после начала) просела на пару порядков — до совершенно неприемлемых уровней — меньше тысячи записей в секунду на один сервер.

Tokyo Tyrant (со структурой на базе хэш-таблиц) справлялся существенно лучше, стабильно сохраняя порядка 10-12 тысяч записей в секунду на один сервер, с параллельно идущим expiration. Tokyo Tyrant с fixed-size записями и деревьями для сравнения работал еще раза в 3-4 быстрее, но для нас это был не вариант, т.к. в таком случае нет корректного expiration.

Redis субъективно хорош не тем, что он какой-то сверхскоростной, а скорее фичами, которые позволяют его использовать во многом как альтернативу более традиционным реляционным базам данных. Судя по тому, что я вижу — Tarantool — тоже ориентируется в основном на такую feature-full нишу.

HandlerSocket хорошо работает с primary key.
А вы представляете, например, насколько небыстрыми будут апдейты на таблицах с десятками миллионов записей с включенными secondary индексами?