У нас довольно много сервисов потоковой обработки, и у них разные профили взаимодействия со стейтом. Ну и еще NDA есть, и конкретики не расскажешь. Поэтому далее несколько разрозненные аргументы, почему у нас так как есть. Почему одна таблица? * Среди всех стейтов может быть длинный хвост стейтов маленького размера и из-за этого суммарный размер ключей начинает нас волновать. Если делать несколько таблиц, то придется многократно хранить ключи и платить за это. (Это я не высасываю из пальца, несколько лет назад реально размышляли на такую тему) * В одном сервисе нам критически важны быстрые лукапы по ключам, одна таблица тут помогает. * В плоскую структуру наши стейты не разложить - получится неадекватное число колонок, а при разделении на небольшое число таблиц / колонок от работы с документами уйти не получится.
При этом у нас не везде одна таблица. У нас есть раздельные таблицы с одним множеством ключей там, где это необходимо/выгодно.
Про выбор БД, тут есть особенности разработки больших сервисов внутри больших IT компаний, брали YTsaurus, так как в нем был нужный функционал для обеспечения exactly once, его использовали ранее в отделе, и с командой YTsaurus можно взаимодействовать и заказывать фичи и улучшения :)
Не все строки обновляются одинаково часто, если взвесить по частоте обновления то с наивным алгоритмом одна запись была бы 10кб в среднем. Ну и экономим мы не астрономическое время (операции делаем батчевые, пытаться уменьшать летенси одной операции у нас не возникало необходимости), а cpu time, запись на диски, чтения с дисков, место на дисках, сеть. А эти штуки заметно уменьшаются.
У нас довольно много сервисов потоковой обработки, и у них разные профили взаимодействия со стейтом. Ну и еще NDA есть, и конкретики не расскажешь. Поэтому далее несколько разрозненные аргументы, почему у нас так как есть.
Почему одна таблица?
* Среди всех стейтов может быть длинный хвост стейтов маленького размера и из-за этого суммарный размер ключей начинает нас волновать. Если делать несколько таблиц, то придется многократно хранить ключи и платить за это. (Это я не высасываю из пальца, несколько лет назад реально размышляли на такую тему)
* В одном сервисе нам критически важны быстрые лукапы по ключам, одна таблица тут помогает.
* В плоскую структуру наши стейты не разложить - получится неадекватное число колонок, а при разделении на небольшое число таблиц / колонок от работы с документами уйти не получится.
При этом у нас не везде одна таблица. У нас есть раздельные таблицы с одним множеством ключей там, где это необходимо/выгодно.
Про выбор БД, тут есть особенности разработки больших сервисов внутри больших IT компаний, брали YTsaurus, так как в нем был нужный функционал для обеспечения exactly once, его использовали ранее в отделе, и с командой YTsaurus можно взаимодействовать и заказывать фичи и улучшения :)
Не все строки обновляются одинаково часто, если взвесить по частоте обновления то с наивным алгоритмом одна запись была бы 10кб в среднем. Ну и экономим мы не астрономическое время (операции делаем батчевые, пытаться уменьшать летенси одной операции у нас не возникало необходимости), а cpu time, запись на диски, чтения с дисков, место на дисках, сеть. А эти штуки заметно уменьшаются.