Привет, тут надо учитывать что чтение по вторичному ключу ходит в первичный ключ за данными. Систему это не кладёт, но в целом, конечно, тут есть куда ускоряться: можно например при чтении по диапазону запросы в первичный ключ делать параллельно, а не последовательно, как сейчас.
Сергей, спасибо что включаешь меня в соавторы, но по правде сказать я был тогда такой зелёный, что разве что мог послужить «подопытным кроликом». Шаги протокола несколько раз прокрутил в голове в процессе реализации, уязвимостей придумать так и не смог. А ещё мне до сих пор стыдно за CVE с nil-terminated string в MYSQL CHANGE USER который я в своё время проморгал.
Это не такой уж кактус, если бы не приходилось работать с презентациями в формате .ppt. На родных презентациях он не так уж тупит. Если вы про онлайн-инструменты, то презентации часто приходится пилить в самолёте или прямо перед докладом, и там не до поисков работающего wi-fi. В общем, всё дело в неправильных привычках :)
Tarantool — открытый проект, и работает на стандартном оборудовании, на куче операционных систем и железа. Нам нужна архитектура, которая была бы одинаково эффективна при желании в том числе на Windows. Но сама по себе идея использоавть Intel DPDK очень здравая, есть такая СУБД Scylla, она сделана по очень похожей на нас архитектуре, там есть поддержка Intel DPDK. Рано или поздно придёт эра unikernel и эта проблема будет решена на корню.
София сейчас по нашим оценкам достаточно хорошо работает с объёмом данных до 500ГБ на инстанс, сейчас пытаемся сделать так чтобы нормально работала с терабайтными объёмами. Из существенных ограничений — пока нет вторичных ключей. Многокомпонентные ключи есть. В проде в mail.ru пока нигде нет — нам нужны как раз терабайтные объёмы, пытаемся запустить.
Мастер-мастер асинхронный, синхронный делаем в 1.7, который должен выйти в этом году.
Я на знаю к кому Вы обращаетесь во множественном числе, это видимо твёрдая вера в то что всё заказано, проплачено и везде пиар :)))
e-sha один из наших пользователей, ему http насколько я знаю не нужен, поэтому он Вам не ответит. А другим http внутри — удобно.
Ещё пару слов про Редис. На мой взгляд, Редис — отличный пример работы сообщества, выбирающего простоту.
Но с точки зрения архитектуры, например, на мой взгляд, преимущества Редиса являются его же и недостатками. Изобретение своего «языка» данных уже сделало целый ряд задач невозможным — например, нормальную интеграцию с хранимыми процедурами.
Отсутствие каталога метаданных не позволяет именовать объекты
СУБД, управлять ими. Отсутствие концепции типа данных создаст проблемы при попытке реализовать поддержку таких типов как точки, полигоны, деньги.
Отсутствие абастракции модели хранения от модели представления приводит к избыточности хранения, если нужны вторичные индексы.
Этот список можно продолжать.
В целом, эти проблемы можно было бы и не «изобретать — это 70е годы 20го века, иерархическая модель данных и т.п. уже показали ущербность таких подходов, но не уверен, что Сальваторе что-то знал про проблематику когда создавал своё решение.
Но их „понадобилось“ изобрести чтобы достаточно удачно спозиционироваться в растущем сообществе молодых Web-разработчиков. Чтобы „было просто, проще некуда“.
Параллельно Редис уже в 2004 г. был продукт NDB Clsuter — in-memory database, с открытым исходным кодом, по фичам на порядок превосходящая
Редис. Community сформировалась тем не менее вокруг Редиса. Можно долго рассуждать про позиционирование, но имхо всё проще — чтобы сообщество сформировалась, его нужно формировать. Пусть даже меня не понимают большинство юзеров, но если я не буду оставлять своих
попыток объяснить, что я делаю, мы найдём общий язык. Тем не менее, я порой предпочитаю более технически сложное решение, но более „долгоживущее“ с точки зрения архитектуры, чем простоту артикуляции наших фич для community.
Вы всё правильно пишете про позиционирование, как известно, автомобиль — это безлошадная повозка. Но меня задела фактическая сторона вопроса. В Редис не 4 структуры данных, а 6 или 7, цитирую с главной: «Redis is… a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs». И в Тарантуле нет фич которые надо удалять — мы всё «устаревшее» удалили между 1.5 и 1.6, чем вызвали плач Ярославны от нашего существующего community.
Это троллинг, и он не по существу. Редис *начинал* как простая база данных, с несколькими структурами. В настоящий момент это под 200 команд, и для каждой новой структуры данных понадобится добавлять новую. Мы изначально пошли по парадигме не структур данных, а модели данных на основе таплов и пространств, что позволяет нам иметь потенциально больше возможностей не расширяя синтаксис. Наш синтаксис — обычный Lua, т.е. это просто методы, они не засоряют пространство имён, не добавляют новых ключевых слов и т.п.
Мы добавляем фичи для пользователей, но говорить что мы «обросли фишками» — это чушь, мы ещё не имеем и половины тех фич что должны иметь. Назовите одну «левую» фичу которую нужно удалять, и мы сможем продолжить разговор. Вот Редису как раз пришлось удалять неудавшийся дискстор — потому что сделали они его изначально неправильно. Я реально не против Редиса, классное решение, отлично развивается, но Вы просто не знаете что такое Тарантул, поэтому лучше не пишите всякую ерунду.
https://code.google.com/archive/p/cpp-btree/
София сейчас по нашим оценкам достаточно хорошо работает с объёмом данных до 500ГБ на инстанс, сейчас пытаемся сделать так чтобы нормально работала с терабайтными объёмами. Из существенных ограничений — пока нет вторичных ключей. Многокомпонентные ключи есть. В проде в mail.ru пока нигде нет — нам нужны как раз терабайтные объёмы, пытаемся запустить.
Мастер-мастер асинхронный, синхронный делаем в 1.7, который должен выйти в этом году.
вчера выложили, новая реализация бинарного протокола на новом plugin api
пока ещё сыро :)
Сам протокол описан вот здесь:
tarantool.org/doc/dev_guide/box-protocol.html
Теперь для работы с сервером нужен msgpack.
e-sha один из наших пользователей, ему http насколько я знаю не нужен, поэтому он Вам не ответит. А другим http внутри — удобно.
Но с точки зрения архитектуры, например, на мой взгляд, преимущества Редиса являются его же и недостатками. Изобретение своего «языка» данных уже сделало целый ряд задач невозможным — например, нормальную интеграцию с хранимыми процедурами.
Отсутствие каталога метаданных не позволяет именовать объекты
СУБД, управлять ими. Отсутствие концепции типа данных создаст проблемы при попытке реализовать поддержку таких типов как точки, полигоны, деньги.
Отсутствие абастракции модели хранения от модели представления приводит к избыточности хранения, если нужны вторичные индексы.
Этот список можно продолжать.
В целом, эти проблемы можно было бы и не «изобретать — это 70е годы 20го века, иерархическая модель данных и т.п. уже показали ущербность таких подходов, но не уверен, что Сальваторе что-то знал про проблематику когда создавал своё решение.
Но их „понадобилось“ изобрести чтобы достаточно удачно спозиционироваться в растущем сообществе молодых Web-разработчиков. Чтобы „было просто, проще некуда“.
Параллельно Редис уже в 2004 г. был продукт NDB Clsuter — in-memory database, с открытым исходным кодом, по фичам на порядок превосходящая
Редис. Community сформировалась тем не менее вокруг Редиса. Можно долго рассуждать про позиционирование, но имхо всё проще — чтобы сообщество сформировалась, его нужно формировать. Пусть даже меня не понимают большинство юзеров, но если я не буду оставлять своих
попыток объяснить, что я делаю, мы найдём общий язык. Тем не менее, я порой предпочитаю более технически сложное решение, но более „долгоживущее“ с точки зрения архитектуры, чем простоту артикуляции наших фич для community.
Мы добавляем фичи для пользователей, но говорить что мы «обросли фишками» — это чушь, мы ещё не имеем и половины тех фич что должны иметь. Назовите одну «левую» фичу которую нужно удалять, и мы сможем продолжить разговор. Вот Редису как раз пришлось удалять неудавшийся дискстор — потому что сделали они его изначально неправильно. Я реально не против Редиса, классное решение, отлично развивается, но Вы просто не знаете что такое Тарантул, поэтому лучше не пишите всякую ерунду.