Стратегии проектирования для создания приложений с использованием хранилища ключей и значений

Question

Хранилище значений ключа, тип № SQL, как его можно использовать для создания общих функций приложения?

• Хранение информации о пользователе (информации для входа)
• Хранение документы и / или «объекты» по отношению к пользователю или другим объектам

Какова общая стратегия в приложении моделирования, которое использует хранилище «ключ-значение» вместо типичного документа № SQL?

Например, если у вас есть только этот API для взаимодействия с хранилищем данных:

put(String bucketName, String, byte[] value);
byte[] get(String bucketName, String key);
List<String> getKeys(String bucketName, String prefix, int maxKeys);
delete(String bucketName, String key); 

Answer 1

Один ответ на этот вопрос, как описано здесь .

Предназначен для моделирования такой информации:

[key]           [value]
artist:1:name   AC/DC
artist:1:genre  Hard Rock
artist:2:name   Slim Dusty
artist:2:genre  Country

Проблема в том, что если базовое хранилище данных не поддерживает транзакции, то могут отсутствовать данные в наборе . Однако хороший дизайн приложения для конечного пользователя, который понимает, что все данные, хранящиеся, например, объект исполнителя, на самом деле представляют собой несколько сохраненных значений, тогда это не будет проблемой. Ключевым моментом здесь является то, что приложение должно «понимать», что используемая база данных является хранимым ключом-значением, во многом так же, как регистрация DNS, когда каждая запись сохраняется индивидуально, а не пакетно, что будет обычным случаем, поскольку большинство хранилищ KV может Не обрабатываю пакетные операции.