I generally warn against saying “I have a few super cool use cases so I’m redoing my entire data model to be compatible with this DB that does that thing”. Instead, put all your data in a normalized DB. Write only the parts of that data that are useful into Aerospike. In a format that is most useful for Aerospike. With enough info to show your map or other “realtime” stuff and the key from the relational DB. Then on click or interaction go back to the relational DB. Basically, you would write a key into Aerospike with bins for locations. Friend sets are fine, but even then, will you ever show 100000 friends? Or 10? Query aerospike for just the relation list. Query the relational for the detail. With paging you’re only ever asking for 10-25 at a time. The extra step is likely not meaningful.
If you ever say “but I need to show a user X thousands of results from Aerospike and join them into the relational DB” then that’s a smell and you’re likely doing something else wrong.
If you need to count friends. Count the IDs in AS. Counts don’t have the detail. Counting the IDs is fine.