Минимизация несоответствия между таблицами в денормализованных базах данных, таких как Cassandra

#cassandra #nosql #consistency #denormalization

Вопрос:

Cassandra (и BigTable и т. Д.) Рекомендует денормализованную базу данных, в которой таблицы создаются на основе ожидаемых запросов. Документ Cassandra использует этот пример:

 hotels_by_poi:   poi_name (Key)
                 hotel_id (Cluster key)
                 name
                 phone
                 address

hotels:          hotel_id (Key)
                 name
                 phone
                 address
 

Таким образом, имя, телефон и адрес денормализованы между hotels_by_poi и hotels . Что меня интересует, так это как реализовать этот метод:

 update_hotel_info(hotel_id, name, phone, address) {
    updateHotel(hotel_id, name, phone, address);
    updatePoisByHotel(hotel_id, name, phone, address);

}
 

Возможно, ошибки первого метода или ошибки сервера, на котором запущены два метода, между первым и вторым методами обновления. Поэтому данные не синхронизируются. Не делая ничего другого, это даже в конечном итоге не согласуется.

  • Возможно ли создать несколько таблиц для возможной согласованности денормализованных данных, которыми они обмениваются?
  • Это то, о чем люди беспокоятся на практике? (например, если все службы 5 9, то целостность составляет 4 9, довольно хорошо.)

Ответ №1:

Идея состоит в том, чтобы обернуть обновления связанных таблиц в BATCH инструкцию CQL, как я объяснил здесь — https://community.datastax.com/articles/2744/.

Даже если вы не использовали пакеты CQL, идея заключается в том, что в случае сбоя любого из этих методов у вас должна быть обработка ошибок, которая (например) повторит запрос, чтобы убедиться, что они успешны. Ваше здоровье!

Комментарии:

1. Спасибо, 1. Я пока не буду «соглашаться», потому что, вероятно, существует несколько подходов к решению этой проблемы, особенно потому, что одна из рекламных объявлений Cassandra заключается в том, что это дешево, что это отменяет.

2. Я не совсем понимаю, как «это отменяется». Не могли бы вы поподробнее, пожалуйста? Запись дешева, как вы сказали, поэтому запись дублированных данных дешева, и мы делаем это, потому что это оптимизирует чтение. Ваше здоровье!

Ответ №2:

Как упоминал @Erick, либо используйте пакет для поддержания согласованности, либо, если вы можете работать на стороне клиента, повторяя неудачные вставки/удаления. Например

 update_hotel_info(hotel_id, name, phone, address) {
    updateHotel(hotel_id, name, phone, address);
    updatePoisByHotel(hotel_id, name, phone, address);
}
 

Вы можете повторить update_hotel_info попытку, если какая-либо из операций вставки/обновления не удалась . Таким образом, вы получите быструю запись и сможете использовать дешевые записи Кассандры.