Да, к сожалению нам удаётся поддерживать в максимально активном состоянии не все коннекторы.
Видимо в случае 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. Тоже ничто не мешает делать это постепенно.
Я не понял, как у вас сочетается репликация и wal_mode=none.
У вас какая-то кастомная репликация поверх tarantool?
Да, есть.
И кворумный кластер есть.
Только сейчас уже поздно.
Нет смысла на сегодняшний день использовать Rabbit для стриминга.
И как raft-cluster помогает вам горизонтально масштабироваться?
fringe и matter, а не fringes и matters :)
Ну и можно было бы ссылки на старые доклады про S3 добавить
https://habr.com/ru/companies/vk/articles/513356/
https://www.youtube.com/watch?v=O0iIADHgBVc
Ну да, я как-то так и спросил :)
Да, к сожалению нам удаётся поддерживать в максимально активном состоянии не все коннекторы.
Видимо в случае 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 сделать:)
Начнём с того, что мемкэш — это кэш. А тарантул — надёжная персистентная бд
Думаем насчёт поддержки WSL2. Не буду прям обещать когда будет, но думаем.
Хотя впрочем...
Про это была статья нашего клиента 1С-Битрикс
Поскольку категорий много, обозначу основные:
Охарактеризовать штуками нагрузку на S3 сложно: она зависит от сценария. Т.е. "жирных" путов пролезет одно число, "мелких" — другое. Причём, что интересно, пропускная способность упирается у нас во фронты и в расчёт MD5+SHA1+SHA256.
Гарантированная обслуживаемая проверенная нагрузка — от 30к RPS и 50Gbps
Нет, существует ещё несколько приватно развёрнутых инсталляций в масштабах на единицы петабайт.
Сорри, это не могу сказать.
Время листинга: 1e9 / 1000 (кол-во объектов в одном листинге) / 300 (кол-во листингов в секунду) = 3333 сек ≈ 1 час.
Лайфсайклы работают "мгновенно", у нас архитектура функций жизненного цикла отличается от амазоновской. Каждый объект имеет timestamp применения lifeCycle и обработка объекта происходит в этот момент.
Тему хилинга можно рассматривать отдельно, но в целом это демоны, работающие на стораджах, выполняющие проверку целостности и рекавери в случае необходимости и сверяющиеся с filedb.
Тут вы не правы. Tarantool используется более 10 лет во многих проектах MRG. С производительностью не огребали, с надёжностью тоже. А вот добавление новой функциональности и возможностей, таких, как MVCC, может дать новые точки роста и применения
И да. У вас в комментариях довольно много слов
нормальный. Не поделитесь ли критерием нормальности?А можете сказать, что конкретно вам не нравится в документации и какой бы вы хотели её видеть?
Столько, сколько транзакций происходит за единицы миллисекунд, которые составляют лаг репликации.
Вы ведь не пытаетесь всерьёз рассматривать однонодовую систему, рассуждая о сохранности данных?
Если же нужно выполнить breaking change, то выкатка выполняется в 3 этапа:
1. Выкатываем версию, которая поддерживает старое API и новое API. Выкатываем постепенно. Растянутость во времени не мешает, т.к. старая версия всё ещё работает. Если что-то идёт не так, можем откатить.
2. Выкатываем целевой софт, в котором меняем версию на новую. Поскольку поддерживаются обе версии, то проблем с длительностью выкатки нет.
3. Выкатываем версию, из которой просто удаляем роботу со старым API. Тоже ничто не мешает делать это постепенно.