Я рассматривал возможность использования cockroachdb для записи данных в 3-й нормальной форме с гарантиями ACID. Таким образом, все записи будут перенаправлены на cockroachdb.
Все чтения могут быть точечным поиском на основе ключа строки для Кассандры. Я считаю, что такая настройка чтения устранит необходимость в повторном кэшировании, поскольку Cassandra сама по себе выполняет быстрое чтение. Таким образом, таблицы Cassandra будут денормализованы на основе путей доступа.
Может быть синхронизация на основе событий от вставки / обновления / удаления внутри нормализованной схемы cockroachdb для вставки / обновления / удаления в денормализованную схему cassandra.
Вопрос 1:
Подходит ли такое разделение чтения и записи допустимому сценарию использования cockroachdb? Намерение состоит в том, чтобы уменьшить количество соединений и иметь быстрое чтение, а также запись. Cockroachdb становится единственным источником правды, получая также данные о происхождении событий. А другие базы данных, такие как cassandra и elasticsearch, становятся проекциями запросов, которые в конечном итоге синхронизируются.
Вопрос 2:
Подходит ли эта установка для финансовых транзакций, где N отчетов должны выполняться атомарно? Насколько я понимаю, предположим, что существует N операторов SQL, которые выполняются транзакционно внутри схемы 3NF cockroachdb. После этого чтения происходят из Cassandra / ElasticSearch, которые еще не будут синхронизированы из-за задержки синхронизации. В этом сценарии возможной согласованности, если пользователь отправляет другую команду для достижения такого же результата с другой машины параллельно, это перейдет к обработчику команд, который будет искать в cockroachdb. Я думаю, поскольку CockroachDb совместим с ACID, мы гарантированно аннулируем команду на этапе проверки команды после поиска в cockroachdb. Я верю, что этот таракан будет генерировать исключение оптимистичной блокировки, поскольку одна транзакция, записывающая в ту же таблицу, уже выполняется. Итак, вопрос в том, должны ли мы в таких сценариях также читать из CockroachDB вместо Cassandra / ElasticSearch?
Вопрос 3
Последний вариант использования, который я имел в виду, заключался в том, чтобы cockroachdb выполнял роль, которую искровый кластер будет делать с кассандрой в отношении агрегаций. Мы можем выполнять агрегацию внутри cockroachdb, в котором есть все данные, и хранить их в предварительно агрегированных таблицах в cassandra. Хотя ElasticSearch также может выполнять агрегацию, возникает вопрос - правильно ли этот вариант использования звучит при использовании для агрегации cockroachdb вместо elasticsearch?
