Кассандра для хранения информации об оплате - PullRequest
5 голосов
/ 20 октября 2011

Я пытаюсь создать высокодоступное приложение для корзины покупок. Приложение будет иметь такой большой объем, что я рассматриваю возможность использования cassandra вместо mysql для базы данных.

Теперь в системе корзины покупок большинство действий с базой данных должны быть согласованными на 100%, тогда как другие не должны быть согласованными.

Пример 100% согласованного действия: Сохранение подтверждения оплаты. Сохранение списка купленных предметов.

Пример вещей, которые не требуют 100% последовательных действий: Сохранение адреса клиента (если на момент оплаты в базе данных не было сохранено ни одного адреса, предположите, что он был потерян, и спросите клиента еще раз). Другие подобные вещи.

Теперь, если я использую кластер серверов в том же регионе (Amazon EC2), существуют ли какие-либо серьезные препятствия для выполнения всех транзакций как максимально согласованной транзакции. Будет ли это обеспечить идентичность надежности, чем MySQl реляционной базы данных. Помните, что здесь мы имеем дело с финансовыми операциями.

Являются ли мои данные в целом "безопасными" на Кассандре. Под этим я подразумеваю полный неожиданный сбой питания, случайный сбой диска и т. Д. И т. Д.

Ответы [ 2 ]

8 голосов
/ 21 октября 2011

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

В списках рассылки пользователя Apache Cassandra есть несколько хороших тем о транзакциях и решении этой проблемы.

Кассандра сама по себе не подходит для транзакций:

Чтобы обойти это, вам нужно «нечто», которое может использовать Cassandra в качестве хранилища данных, которое управляет транзакциями выше уровня данных.

Резюме ... Вы не можете гарантировать финансовые операции только с Кассандрой

3 голосов
/ 21 октября 2011

Существует множество различных способов определения согласованности . Если под «максимальной последовательной транзакцией» вы подразумеваете чтение и запись в ConsistencyLevel ALL, то это обеспечит последовательность в том смысле, что ваши чтения никогда не будут возвращать устаревшее значение, и долговечность в том смысле, что ваши записи будут храниться в все узлы перед возвратом.

Однако это не то же самое, что транзакции . Кассандра не поддерживает транзакции. Он не обеспечивает согласованность между различными строками, как это делает MySQL. Например, предположим, что вы добавляете товар в корзину и обновляете общую стоимость в корзине. Индивидуально каждая операция будет храниться последовательно и длительно. Однако может быть окно времени, в котором вы можете увидеть одно изменение, но не другое. В реляционной базе данных вы можете сгруппировать их в транзакцию, чтобы вы могли видеть только оба или ни одного.

Что касается безопасности, Cassandra сохраняет все ваши записи на диск в журнале фиксации, прежде чем делать что-либо еще, так же, как реляционные базы данных используют журналы транзакций. Так что это так же безопасно в отношении системных сбоев. Что касается сбоев узлов, если вы пишете в CL.ALL, то вы никогда не потеряете данные, пока выживет один узел в каждом наборе реплик. Что касается сбоя диска, это вопрос вашей базовой аппаратной установки, например, RAID.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...