В предыдущей статье о Vinyl я рассказывал об архитектуре LSM-движка Tarantool. Восемь лет, прошедшие с момента с написания статьи, показали, что Vinyl сразу получился идеальным и менять его не нужно :). Если серьёзно, сегодня я расскажу о тех изменениях, которые мы внесли в алгоритм в форке Tarantool от Picodata, и неизбежно коснусь более глубокой проблематики работы LSM-деревьев, а конкретнее – работы планировщика слияний (compaction scheduler).
Рубрика «LSM-дерево»
Как мы пересобрали сборку мусора в Vinyl
2026-04-09 в 8:23, admin, рубрики: Compaction, LSM tree, LSM-дерево, picodata, tarantool, vinylДоставка миллиардов сообщений строго один раз
2017-07-05 в 5:45, admin, рубрики: api, Go, LSM-дерево, rocksdb, segment, UUIDv4, Анализ и проектирование систем, векторные часы, высокая производительность, однократная доставка, подтверждение доставки, Разработка систем передачи данных, Системы обмена сообщениями, метки: Kafka, Segment, UUIDv4, векторные часы, однократная доставка, подтверждение доставки
Единственное требование ко всем системам передачи данных состоит в том, что нельзя потерять данные. Данные обычно могут поступить с опозданием или их можно запросить заново, но их никогда нельзя терять.
Чтобы удовлетворить этому требованию, большинство распределённых систем гарантирует по крайней мере однократную доставку. Техники обеспечения «по крайней мере однократной доставки» обычно сводятся к «повторам, повторам и повторам». Вы никогда не считаете сообщение доставленным, пока не получите чёткое подтверждение от клиента.
Но как пользователю по крайней мере однократная доставка — это не совсем то, что я хочу. Я хочу, чтобы сообщения доставлялись один раз. И только один раз.
Читать полностью »