Aerospike: Как обрабатывать максимальное количество наборов Ограничение 1023 для пространства имен

Я использую Aerospike 3.4. сообществ. Известно, что аэроспейс поддерживает только 1023 набора на пространство имен. В моей ситуации я могу преодолеть этот предел. Один из способов, которыми я мог бы справиться с этим, может включать в себя имя набора с ПК и все в одном наборе. В этом случае, как я могу перебирать записи в определенном наборе. В этом подходе могут возникнуть другие проблемы. Может ли кто-нибудь помочь с этим ограничением на 1023?Aerospike: Как обрабатывать максимальное количество наборов Ограничение 1023 для пространства имен

Спасибо заранее.

источник

2015-03-14 Carbonrock

Это похоже на проблему моделирования данных. Не могли бы вы объяснить свое использование и моделирование данных, которые вы используете? –

Используя один метод установки, который вы упомянули, вы также можете сохранить имя набора в другой ячейке и создать дополнительный индекс в этом бункере. Это будет использовать больше ОЗУ, но повторение по «набору» будет быстрее, чем фактический набор. – kporter

@Anshu, В настоящее время каждый набор будет иметь от тысячи до lakh записей с идентификатором электронной почты как PK с «n» количеством ящиков, таких как дата создания, дата обновления, рейтинг, баланс, местоположение и т. Д., Количество ящиков меняется на запись записать. Каждый набор связан с клиентом. Такими клиентами могут быть тысячи. Пожалуйста помоги. – Carbonrock

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

источник

2015-04-07 18:06:10

Спасибо за ваш ответ. Это то, что я точно сделал. Перенос данных из старой модели данных в новую модель данных. Один из запросов, который мне нужно уточнить, - это также набор поддерживающих наборов, таких как действия, подписки, победители и т. Д. Даже эти настройки на одного клиента, поэтому я заканчиваю тысячами клиентов. Я переместил все в один набор вместе с «пользователями». Это прекрасно? ИЛИ У меня могли быть разные наборы для действий, подписки и победителей. Пожалуйста, предложите. Благодарю. – Carbonrock

Это то, что я точно сделал. ПК как пользователи: client_id: электронная почта для пользователей, победители: client_id: электронная почта для победителей, подписки: client_id: электронная почта для подписки. Все они в одном наборе. Это прекрасно? ИЛИ У меня могли быть разные наборы для действий, подписки и победителей. Пожалуйста, предложите. – Carbonrock

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

Aerospike: Как обрабатывать максимальное количество наборов Ограничение 1023 для пространства имен

ответ

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