2013-03-07 5 views
5

Использование Riak Я хочу последовательно добавлять данные таким образом, чтобы я мог получать все данные, которые я добавлял время от времени. Думайте о журналах, если я выбираю увеличивающиеся строки журнала и передаю их на riak, в какой-то момент я хочу восстановить все, что я добавил.Как добавить данные в ключ Riak в сильно распределенной среде?

Я думал об этом, создав для этого новый ковш, затем добавьте ключи, определенные последовательным номером или штампом даты и времени, и добавьте в него контент, затем используйте list keys API и восстановите нужные мне данные. Проблема заключается в том, что API-интерфейс списка неэффективен и рекомендуется производство. Что мне нравится в этом подходе, так это то, что данные не имеют проблем с параллельной записью (без блокировок/etc), поскольку все ключи независимы.

Другой подход - использовать один ключ, открыть его и добавить к нему, но Я очень обеспокоен проблемами параллелизма/блокировки. Это действие будет выполняться в распределенной среде и, безусловно, будет плохим выбором

Вопрос: любые другие способы сделать это в Riak? Любой добавочный режим для ключа?

ответ

10

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

В Riak также нет функции добавления, что означает, что вам необходимо сначала прочитать, а затем записать запись, чтобы обновить ее и добавить новые записи журнала. В зависимости от того, как вы организуете и координируете свое письмо, это может указывать на результат параллельных обновлений одной и той же записи, которые необходимо учитывать при разработке решения.

Предполагая, что записи, которые вы собираете, например. записи журнала, можно рассматривать как набор, метод, который я бы рекомендовал, - это время-бокс. Когда время бокса, вы агрегировать данные на основе периода времени. Если мы, например, предположим, что мы собираем журналы для набора серверов (именованный сервер в этом примере), мы можем создавать записи с ключами на основе идентификатора сервера и идентификатора даты и времени, например. начало периода измерения. Нам не нужна полная метка времени, достаточно, чтобы мы могли идентифицировать запись. Запись записей журнала записей для сервера3, охватывающая период между 14:15 и 14:20 в 2013/03/07, может быть названа «server3_20130307_1415». Соответственно, следующий 5-минутный период будет называться «server3_20130307_1420». Если на какой-либо период нет данных, запись не будет создана.

Это позволяет вам автоматически знать ключ для записи, охватывающей определенный период, и позволит вам получать записи, основанные исключительно на ключевом доступе, который масштабируется и работает очень хорошо. Естественно, вам необходимо настроить период времени, охватываемый одной записью, в зависимости от объема данных, которые вы генерируете, поскольку обычно вы хотите сохранить размер объектов в Riak ниже 1-2 МБ. Также стоит рассмотреть возможность сжатия данных на уровне приложения, если каждый период будет иметь множество данных, чтобы получить ниже этого рекомендуемого размера.

Если вы хотите иметь доступ к более крупным кускам данных без необходимости извлекать потенциально большое количество записей, вы можете периодически собирать записи. Вы можете, например, прочитайте все записи за час и напишите агрегированные данные в новую запись с именем «server3_20130307_14», которая охватывает весь период 14: 00-15: 00. Поскольку вы знаете ключи, это прямолинейно и легко реализуется как пакетное задание.

При использовании этого подхода вы, как обсуждалось ранее, должны рассмотреть возможность одновременной записи. Лучший способ сделать это, на мой взгляд, разрешить братьям и сестрам (установите «allow_mult» в true и «last_write_wins» на false для ведра с использованием свойств ковша [1]). Это приведет к тому, что Riak сохранит все версии записи в случае одновременных обновлений, и вместо этого вам нужно будет разрешить любых братьев и сестер, созданных на вашем прикладном уровне, после чтения записи с братьями и сестрами. Хотя это добавляет немного сложности, это гарантирует, что вы не потеряете никаких данных.

Как мы предполагали, записи журнала в этом случае могут рассматриваться как набор, вы можете объединить наборы всех братьев и сестер через объединение единиц, а затем обновить объект (с правильными векторными часами), чтобы разрешить братьев и сестер ,

[1] http://docs.basho.com/riak/latest/references/apis/http/HTTP-Set-Bucket-Properties/

+0

спасибо. отличная информация! – gextra

+0

как насчет добавления функции добавления-записи в Riak? Не может быть так сложно. Я все равно проверю – senorcarbone

+2

Функциональность Append-write быстро становится довольно сложной в беспроблемной, в конечном итоге последовательной системе, особенно когда это хранилище ключей, которое не предполагает, что ваши данные находятся в каком-либо конкретном формате. Тем не менее, существует работа по внедрению CRDT (https://github.com/basho/riak_dt), которая позволит пользователю создавать типы данных, которые могут быть автоматически разрешены в случае конфликтов, что может обеспечить тип поведения вы запрашиваете. –

Смежные вопросы