Typically you'd store these types of things in the standard ECS scene as usual with the data in one or more components. Where I'm thinking you might be hung up a bit is that the ECS isn't there to give you things like efficient collision detection or frustum culling off the bat. It's there to give you a very flexible way to store, access, transform, manage, and organize your game state. If it's a very efficient ECS implementation, it's generally optimized for sequential loops over components for algorithms that typically won't be better than linear-time in complexity.
Usually, if you want to do efficient collision detection in those, for example, you'd build a spatial index on the side like a loose quadtree for 2D cases or a spatial hash. These data structures typically don't own the memory of the game objects. Instead, they usually store links to them (references, pointers, or indices) with a layer of indirection along with something like an axis-aligned bounding box. It tends to actually improve efficiency in these cases to have that layer of indirection even when the engine is not an ECS and can store game objects directly since if you imagine a search query involving linear probing in a spatial hash, just storing a link (but keys, of course, by value) can substantially reduce the stride to get from one entry in the hash table to the next while allowing more entries in that hash table to fit in a cache line if we avoid having to store an entire entity or component's data by value.
As for where to store these data structures used to accelerate searches, I'm not sure what is idiomatic. ECS specs tend to be pretty loose with respect to details like this, and I'm sure a variety of solutions exist. What I tend to do in cases where the data structure is accessed by multiple systems is to just store or directly associate with the scene, like:
// logarithmic search
entity_or_component_refs = scene.quadtree.find_intersection(...);
You could store such a structure in a component but I find it a bit clumsy since, in many cases, it would convolute systems if they can't safely assume that there's going to be only one for the entire scene, and typically an ECS is designed around storing a variable number of components of each type unless your engine specifically handles such cases.
In cases where the data structure is only used by one system, like a physics system, I tend to relax the strict separation rule of data in components and logic in stateless systems and just store the data structure as a private member of the system object. I think that's still reasonably idiomatic since most ECS implementations I see do allow systems to store some state (including specs from what I can gather). What I would do is try to avoid storing what constitutes the central program state in a system, like the type of state that gets serialized, since that blurs responsibilities. Yet I'd exclude something like a spatial index or physics cache from that category, as it is really just an implementation detail used to help make one or more systems execute more efficiently.