# Voting and how to store

**URL:** https://discuss.aerospike.com/t/voting-and-how-to-store/407
**Category:** Data Modeling
**Created:** [September 16, 2014, 10:52pm UTC](https://discuss.aerospike.com/t/voting-and-how-to-store/407 "2014-09-16T22:52:44Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![ledil](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/ledil/32/42_2.png) [@ledil](https://discuss.aerospike.com/u/ledil)
#### Post date: [September 16, 2014, 10:52pm UTC](https://discuss.aerospike.com/t/voting-and-how-to-store/407/1 "2014-09-16T22:52:44Z")

</div>

hello,

I need to store the relation “voting” for a topic in aerospike. What is the best approach ? This is what Ive done in redis before:

e.g.

userid=13 topicid=44

to see if user with id=13 has been voted for the topic with the id=44 Ive create following rediskey: “44:13” … and with a dummy value. So this is the fasted thing to see if an user has been voted for a topic. I can do this also for aerospike … this is a normal key/value functionality.

Now the other case. How can I see who has voted for topic id =44. For this I can do a redis.keys(‘44:\*’) … a kind of wildcard search. How can I solve this in aerospike, afaik there is no wildcard search … Is it better to store a “json” in the key “44” with all users ? I dont know if areospike is good in large json structures …

Thank you very much, greets

---

<div class="post-metadata">

### Author: ![raj](https://avatars.discourse-cdn.com/v4/letter/r/c0e974/32.png) [@raj](https://discuss.aerospike.com/u/raj)
#### Post date: [September 22, 2014, 6:22am UTC](https://discuss.aerospike.com/t/voting-and-how-to-store/407/2 "2014-09-22T06:22:37Z")

</div>

Ledil,

Depending on the use case there are two ways to solve this in Aerospike.

- If your cardinality of topics is low, i.e when you do query like topics = x you tend to get many rows (\>10 and \< 100000). The best way to solve it to be to create a record like

- If topicid is high cardinality (e.g unique key), along with solution 1 above alternative and possibly higher performance way of doing this would be to have two stores (2 sets in same namespace or 2 namespaces).

HTH

– Raj
