Как вы справляетесь с денормализацией / вторичными индексами при разделении баз данных?

Question

Скажем, у меня есть таблица "message" с 2 вторичными индексами:

• "recipient_id"
• "sender_id"

Я хочу разделить таблицу «message» на «receient_id». Таким образом, чтобы получить все сообщения, отправленные определенному получателю, мне нужно запросить только один шард.

Но в то же время я хочу сделать запрос, который запрашивает все сообщения, отправленные определенным отправителем. Теперь я не хочу отправлять этот запрос всем частям таблицы «message». Один из способов сделать это - продублировать данные и создать для таблицы «message_by_sender» значение «sender_id».

Проблема этого подхода заключается в том, что каждый раз, когда сообщение отправляется, мне нужно вставить сообщение в таблицы «message» и «message_by_sender».

Но что если после вставки в «message» вставка в «message_by_sender» завершится неудачно? В этом случае сообщение существует в «message», но не в «message_by_sender».

Как мне убедиться, что если сообщение существует в "message", то оно также существует в "message_by_sender", не прибегая к двухфазной фиксации?

Это должно быть очень распространенной проблемой для тех, кто осматривает свои базы данных. Как вы справляетесь с этим?

Answer 1

В этой проблеме нет "серебряной пули".Некоторые параметры:

1. Использование очереди сообщений для публикации изменений.В конце концов изменения будут внесены в разные разделы.
2. Наличие триггера на разделах таблицы сообщений, который создает в таблице строку "необходима запись индекса".Что-то еще будет периодически сканировать это и создавать индекс.

Возможно, вы захотите прочитать эту запись в блоге о распределенных транзакциях в Google App Engine: http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engine. В основном, если вы этого не сделаетехотите 2-фазный коммит или Paxos или что-то в этом роде, тогда вам нужно жить с какой-то в конечном итоге непротиворечивой моделью.

-Dave