Да, к сожалению нам удаётся поддерживать в максимально активном состоянии не все коннекторы.
Видимо в случае JavaScirpt не оказалось ни одного активного пользователя, кто репортил бы проблемы.
Мы постараемся в ближайшее время обновить/актуализировать коннекторы для основных языков.
Если мы рассматриваем in-memory движок, то все данные должны помещаться в RAM. Иначе это уже не in-memory.
Для сценариев хранения данных больших, чем объём памяти есть несколько подходов. Можно либо воспользоваться встроенным дисковым движком на базе LSM-дерева (vinyl), либо воспользоваться подходящим внешним хранилищем, как вспомогательным, например Postgres. У Tarantool в поставке есть готовый коннектор к Postgres.
Во первых SQL Server — это Windows. Просто было негде — вся инфраструктура на линуксе.
Во вторых, если я правильно понял, то In-Memory OLTP в SQL Server не персистентен.
Спасибо!
Сначала полная картинка рисовалась в draw.io, потом экспортировалась в svg.
Далее делались разные картинки для поэлементного отображения и последовательно сибирались в гифку.
В целом, не было такой потребности. Обычно версия увеличивается, когда делаются какие то значительные изменения. Просто так переименовывать 0.х в 1.0 без изменений довольно странно.
Но в ближайшее время планируем серьёзные доработки в автоматику, можно будет и 1.0 сделать:)
Но очень не хватает цифр. Хотя бы сколько железа в каждом кластере тарантула, сколько шпинделей и петабайт, и сколько туда пролазит S3 Put-ов и Get-ов и с какой latency. Ну и что там за сеть конечно тоже интересно.
Storage. Сеть 10Gbps. 1500+. от 24 x 6Tb до 36 x 14Tb. Нарезано на ~ 200к двухтерабайтных volume. Совокупная полезная ёмкость больше 150Pb.
Охарактеризовать штуками нагрузку на S3 сложно: она зависит от сценария. Т.е. "жирных" путов пролезет одно число, "мелких" — другое. Причём, что интересно, пропускная способность упирается у нас во фронты и в расчёт MD5+SHA1+SHA256.
Гарантированная обслуживаемая проверенная нагрузка — от 30к RPS и 50Gbps
И еще вопрос — такой кластер существует в единственном экземпляре, бережно выпиленный напильником, или их несколько и Вы их сетапите по запросу?
Нет, существует ещё несколько приватно развёрнутых инсталляций в масштабах на единицы петабайт.
И еще вопрос — кому может понадобиться миллиард файлов в одном бакете?
Сорри, это не могу сказать.
И сколько времени он у вас листается, всмысле просто получение списка объектов в бакете? И сколько времени на нем выполняются лайфсайклы?
Время листинга: 1e9 / 1000 (кол-во объектов в одном листинге) / 300 (кол-во листингов в секунду) = 3333 сек ≈ 1 час.
Лайфсайклы работают "мгновенно", у нас архитектура функций жизненного цикла отличается от амазоновской. Каждый объект имеет timestamp применения lifeCycle и обработка объекта происходит в этот момент.
Простите, но еще вопрос — а кто хилинг делает (в видео упоминалось) FileDB?
Тему хилинга можно рассматривать отдельно, но в целом это демоны, работающие на стораджах, выполняющие проверку целостности и рекавери в случае необходимости и сверяющиеся с filedb.
Видимо идут по пути mongo — огребли с производительностью и надежностью и начали делать нормальную БД.
Тут вы не правы. Tarantool используется более 10 лет во многих проектах MRG. С производительностью не огребали, с надёжностью тоже. А вот добавление новой функциональности и возможностей, таких, как MVCC, может дать новые точки роста и применения
И да. У вас в комментариях довольно много слов нормальный. Не поделитесь ли критерием нормальности?
Представляете сколько данных можно потерять если на нагружённом сервере у tarantool случится out of memory?
Столько, сколько транзакций происходит за единицы миллисекунд, которые составляют лаг репликации.
Вы ведь не пытаетесь всерьёз рассматривать однонодовую систему, рассуждая о сохранности данных?
В старых инсталляциях, когда до кворумной синхронной репликации было далеко, в критических инсталляциях мы пользовались т.н. семи-синхронной репликацией: транзакция завершалась только тогда, когда мы убеждались в том, что она доехала хотя-бы до одной реплики (механизм wait_lsn).
Кластер выкатывается постепенно, по частям. Поскольку с другими частями системы взаимодействие идёт по API, то обновление на лету это API не ломает и обновление происходит незаметно.
Если же нужно выполнить breaking change, то выкатка выполняется в 3 этапа:
1. Выкатываем версию, которая поддерживает старое API и новое API. Выкатываем постепенно. Растянутость во времени не мешает, т.к. старая версия всё ещё работает. Если что-то идёт не так, можем откатить.
2. Выкатываем целевой софт, в котором меняем версию на новую. Поскольку поддерживаются обе версии, то проблем с длительностью выкатки нет.
3. Выкатываем версию, из которой просто удаляем роботу со старым API. Тоже ничто не мешает делать это постепенно.
Всё-таки неправильно разбирать начинать с правой стороны, т.к. парсится программа слева направо. Хотя итоговый разбор — верный.
Кстати, смотреть подобное можно с помощью Deparse:
$ perl -MO=Deparse -E 'Illegal division by zero at /tmp/quine.pl line 1.'
use feature 'current_sub', 'evalbytes', 'fc', 'say', 'state', 'switch', 'unicode_strings', 'unicode_eval';
'division'->Illegal('zero'->by('at' / 'tmp' / 'quine' . 'line'->pl(1)));
-e syntax OK
Конечно, вы по большей части правы, но есть и новые проекты.
Есть такой Perl, который весьма похож на Golang (демоны на AnyEvent + Coro), только с удобной динамической типизацией и прочими удобствами скриптовых языков.
Tarantool на процессорах Apple M1: первые результаты
Ну да, я как-то так и спросил :)
Архитектура in-memory СУБД: 10 лет опыта в одной статье
Да, к сожалению нам удаётся поддерживать в максимально активном состоянии не все коннекторы.
Видимо в случае JavaScirpt не оказалось ни одного активного пользователя, кто репортил бы проблемы.
Мы постараемся в ближайшее время обновить/актуализировать коннекторы для основных языков.
Архитектура in-memory СУБД: 10 лет опыта в одной статье
Если мы рассматриваем in-memory движок, то все данные должны помещаться в RAM. Иначе это уже не in-memory.
Для сценариев хранения данных больших, чем объём памяти есть несколько подходов. Можно либо воспользоваться встроенным дисковым движком на базе LSM-дерева (vinyl), либо воспользоваться подходящим внешним хранилищем, как вспомогательным, например Postgres. У Tarantool в поставке есть готовый коннектор к Postgres.
Архитектура in-memory СУБД: 10 лет опыта в одной статье
Во первых SQL Server — это Windows. Просто было негде — вся инфраструктура на линуксе.
Во вторых, если я правильно понял, то In-Memory OLTP в SQL Server не персистентен.
Архитектура in-memory СУБД: 10 лет опыта в одной статье
Спасибо!
Сначала полная картинка рисовалась в draw.io, потом экспортировалась в svg.
Далее делались разные картинки для поэлементного отображения и последовательно сибирались в гифку.
Новый релиз — Tarantool 2.7
В целом, не было такой потребности. Обычно версия увеличивается, когда делаются какие то значительные изменения. Просто так переименовывать 0.х в 1.0 без изменений довольно странно.
Но в ближайшее время планируем серьёзные доработки в автоматику, можно будет и 1.0 сделать:)
Tarantool vs Redis: что умеют in-memory технологии
Начнём с того, что мемкэш — это кэш. А тарантул — надёжная персистентная бд
Tarantool vs Redis: что умеют in-memory технологии
Думаем насчёт поддержки WSL2. Не буду прям обещать когда будет, но думаем.
Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
Хотя впрочем...
Про это была статья нашего клиента 1С-Битрикс
Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
Поскольку категорий много, обозначу основные:
Охарактеризовать штуками нагрузку на S3 сложно: она зависит от сценария. Т.е. "жирных" путов пролезет одно число, "мелких" — другое. Причём, что интересно, пропускная способность упирается у нас во фронты и в расчёт MD5+SHA1+SHA256.
Гарантированная обслуживаемая проверенная нагрузка — от 30к RPS и 50Gbps
Нет, существует ещё несколько приватно развёрнутых инсталляций в масштабах на единицы петабайт.
Сорри, это не могу сказать.
Время листинга: 1e9 / 1000 (кол-во объектов в одном листинге) / 300 (кол-во листингов в секунду) = 3333 сек ≈ 1 час.
Лайфсайклы работают "мгновенно", у нас архитектура функций жизненного цикла отличается от амазоновской. Каждый объект имеет timestamp применения lifeCycle и обработка объекта происходит в этот момент.
Тему хилинга можно рассматривать отдельно, но в целом это демоны, работающие на стораджах, выполняющие проверку целостности и рекавери в случае необходимости и сверяющиеся с filedb.
В Tarantool можно совместить супербыструю базу данных и приложение для работы с ними. Вот как просто это делается
Тут вы не правы. Tarantool используется более 10 лет во многих проектах MRG. С производительностью не огребали, с надёжностью тоже. А вот добавление новой функциональности и возможностей, таких, как MVCC, может дать новые точки роста и применения
И да. У вас в комментариях довольно много слов
нормальный. Не поделитесь ли критерием нормальности?В Tarantool можно совместить супербыструю базу данных и приложение для работы с ними. Вот как просто это делается
А можете сказать, что конкретно вам не нравится в документации и какой бы вы хотели её видеть?
В Tarantool можно совместить супербыструю базу данных и приложение для работы с ними. Вот как просто это делается
Столько, сколько транзакций происходит за единицы миллисекунд, которые составляют лаг репликации.
Вы ведь не пытаетесь всерьёз рассматривать однонодовую систему, рассуждая о сохранности данных?
Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
Создаём с нуля высоконагруженное приложение на Tarantool
Если же нужно выполнить breaking change, то выкатка выполняется в 3 этапа:
1. Выкатываем версию, которая поддерживает старое API и новое API. Выкатываем постепенно. Растянутость во времени не мешает, т.к. старая версия всё ещё работает. Если что-то идёт не так, можем откатить.
2. Выкатываем целевой софт, в котором меняем версию на новую. Поскольку поддерживаются обе версии, то проблем с длительностью выкатки нет.
3. Выкатываем версию, из которой просто удаляем роботу со старым API. Тоже ничто не мешает делать это постепенно.
Хитрый Perl-квайн
Всё-таки неправильно разбирать начинать с правой стороны, т.к. парсится программа слева направо. Хотя итоговый разбор — верный.
Кстати, смотреть подобное можно с помощью Deparse:
Курс «Введение в Perl» от Mail.Ru Group
Курс «Введение в Perl» от Mail.Ru Group
Есть такой Perl, который весьма похож на Golang (демоны на AnyEvent + Coro), только с удобной динамической типизацией и прочими удобствами скриптовых языков.
Первый HighLoad Cup: как мы это пережили
По другую сторону баррикад тоже не спали )
Спасибо вам!