Лучший способ смоделировать миллионы существующих чеков в Aerospike?

Выросший из Redis для некоторых структур данных, я ищу другие решения с хорошей производительностью диска/SSD. Недавно я обнаружил Aerospike, который, кажется, лучше всего подходит для среды SSD.

Одной из самых требовательных к памяти структур является около 100 000 наборов Redis, каждый из которых может содержать до 10 000 строк. Каждая строка содержит от 10 до 30 символов.

Эти наборы в основном используются для проверки существования/уникальности.

Как лучше их смоделировать? Обычно я вижу 2 варианта: * смоделировать набор Redis как Aerospike lset * модель каждое значение в наборе отдельно.

Помимо этого выбора, 100 000 наборов Redis используются в качестве разбиения на ключи. Из соображений локальности, вероятно, имело бы смысл иметь подобное разделение/пространство имен в Aerospike. Однако я почти уверен, что понятие «пространство имен» в Aerospike не используется для такого разделения ключей. Каким будет правильный способ (если есть) сделать это в Aerospike, или это не нужно?


redis data-modeling aerospike
person Geert-Jan    schedule 28.10.2014    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Aerospike самостоятельно создает разделы для балансировки нагрузки и обеспечения высокой доступности. Пространство имен является синонимом базы данных в традиционном смысле и НЕ раздела данных. Данные в пространстве имен секционируются и хранятся в кластере. Вам, как пользователю, не нужно беспокоиться о размещении данных.

Я бы сопоставил набор Redis с Aerospike «lset» (один к одному). Aerospike должен заботиться о местоположении данных для данных в данном «lset».

person DB Guy    schedule 28.10.2014

arrow_upward
5
arrow_downward

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

Использование lset имеет свои преимущества. Он дает функциональность, аналогичную Redis, где вам не нужно писать свою собственную функциональность. Но в то же время у него есть и свои недостатки. Так что выбирать следует исходя из своих требований. Все операции над одним набором будут сериализованы. Таким образом, если вы ожидаете, что чтение/запись в набор будет распараллелено, lset может вам не подойти. Кроме того, проверка существования в lset фактически прочитает всю запись и вернет true false. У Aerospike есть существует API для обычных ключей, который будет возвращать true/false на основе индекса в памяти, что намного быстрее.

Для этого варианта использования вы не сможете разделить их на «наборы» aerospike. Вам нужно 100 000 комплектов. Но на данный момент Aerospike поддерживает только 1024 комплекта.

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

  • если ваш фактический ключ — key1, и вы хотите, чтобы он перешел в set1, вы можете установить свои пюреобразные клавиши как set1_key1.
  • когда вы хотите найти наличие key7 в set5, найдите наличие set5_key7

Если вы выберете эту модель, вы максимально используете распределение данных Aerospike и балансировку нагрузки. Проверка существования будет самой быстрой, поскольку ввода-вывода не будет.

person sunil    schedule 29.10.2014
comment
Благодарю. Что касается вашего третьего варианта, то на самом деле это будет просто сброс каждой пары «ключ, значение» (100 000 * 10 000 = 1 000 000 000), верно? Просто чтобы быть уверенным, не является ли это запредельным количеством ключей? То есть: я могу представить, что Aerospike хранит некоторую запись в памяти для каждого ключа для индикации? Если это так, требования к памяти только для этого аспекта уже будут намного больше, чем могут выдержать мои будущие узлы. Беспокойство? Кроме того, имеет ли формат <set>_<key> особое значение в Aerospike, например: указание коду сегментирования хранить все пары «ключ-значение» с одним и тем же префиксом <set>_ вместе на одном сегменте? - person Geert-Jan; 29.10.2014
comment
Это не запретительное число для ключей, так как aerospike может поддерживать до 2^160 ключей. Aerospike занимает около 64 байт памяти на запись индекса. Таким образом, потребность в ОЗУ только для индекса составляет около 64 ГБ, что не так уж плохо, если вы поместите 3-4 узла. Но это предполагает наихудший случай, то есть 100 КБ * 10 КБ. Если их меньше на самом деле, соответственно и потребность будет меньше. Клавиша ‹set›_‹› не имеет никакого значения для aerospike. для аэроспайка это обычный ключ. Шардинг основан на ключе. А значит, ключи набора не будут вместе. Вы не должны стремиться к этому, если у вас нет другой причины. - person sunil; 29.10.2014