The cloud-native version of SAP IQ aims to reduce the storage and compute costs by storing data directly on object stores while benefiting from the greater elasticity and scale-out properties that are offered. In the cloud-native version of SAP IQ, the buffer manager has gone through a significant re-design for two major reasons. First, RAM is more expensive on the cloud; therefore, a buffer manager that relies exclusively on RAM would not have been a viable solution. Second, on object stores, read and write operations are generally associated with higher latencies. To counteract the impact of higher latencies without utilizing more RAM, we have extended SAP IQ's buffer manager with a second layer of cache, namely, the Extended Cache Manager (ECM). The ECM relies on fast solid state drives (SSDs). In this paper, we describe our experience with the design and implementation of the ECM, in particular, the design choices we had to make to overcome the fact that, when compared to object stores, SSDs have a much more limited I/O bandwidth.

Changes to robotic systems as they are updated or upgraded often affect the flow of control and sensor data. Developers and users spend a significant amount of time tracing the impact of these changes that could otherwise have negative impacts on the robot's performance and behavior. Changes to the rates at which data is published from sensors, controllers, and other parts of the system are particularly subtle and difficult to detect. These rate changes, even if minor (e.g. lowering the frame rate of a camera), can propagate throughout the system and have broad impacts. In this work, we develop and implement an approach to help identify the set of components whose rate may be impacted by a system change. The approach builds on the insight that certain code patterns render component's outgoing data rate independent of the component's incoming data rate. We use that insight to reduce the number of components reported as affected by the change to minimize the number of components that must be reevaluated by the developer. A study of an implementation of the approach on three ROS systems shows that it can reduce the size of the impact set by up to 41% in cases when the changes have broad data impacts. The analysis is performed at compile time and only adds a third more to the compilation time.