The idea of an ECS architecture is to avoid inheritance-like calls in components.
As you have read already, components are data containers. Any "updating" of a component should be handled by the appropriate sub-system.
As far as caching/performance goes, there is a simple-ish way to avoid cache misses:
Use the observer pattern for each component: Each subsystem contains a cache friendly vector/array of observers, which copy data from the actual component, whenever it's data changes(via notification).
In such a way the component data is always available to the cache with no additional RAM fetches.
Having Logic and Data in the same object/class/structure is considered bad practice, and allows hackery that is likely to cause as many issues as it solves.
Restrict each subsystem to only read from, and change, a small subset of total data available (A motion system, which updates position according to velocity, should not be able to read/change character data, for example). By separating logic and data, you simplify your code, and restrict the upper limit of complexity, making it much easier to debug.
Now whilst the following is not a direct answer to your question, it does address some misconceptions that you seem to have:
You mentioned in a response to another answer that you wish to retain "the convenience of writing OOP code (having the logic and data in the same place)" :- This goes against one of the core tenets of OOP SOLID design: The Single Responsibility Principle.
OO Design is all about separating and minimizing concerns, and dependencies within a given software module. The convenience of OO code is that of maintenance and being extensible, not that of writing a megalithic (and thus, difficult to maintain, and impossible to extend) class to store all your game entity code.
Such a class also violates the Open/Closed Principle, in so far that it will require significant modifications over the course of the project's life, as you add more and more functionality and data storage to it. Additionally, if you attempt to create a family of entity like objects, you run the risk of the "deadly diamond" scenario.
A true ECS architecture avoids these issues completely.
By favouring data component composition over inheritance, and separating logic concerns into subsystems, you can create a simple game entity class, whose only concern is the storage, and retrieval of components, with no regard to component type, allowing the construction of any type of entity, just by adding new components, or omitting others, in new patterns.
No new logic or sub-classes necessary.
And if that wasn't enough to convince you: Because each subsystem only cares about a small part of the logic for each entity, it is very easy to write, debug and test.
This means fewer difficult-to-diagnose bugs in the long term, which will mean your coding experience will be more productive and enjoyable.