New Delhi Salesforce News and Updates: Week #52

Every e-commerce application is going to need caching. For some of our customers, millions of shoppers may look at the same product information and, if you have to request that information from the service every time, your application will not scale. This is why we built the Commerce SDK with caching as a primary consideration from the start. Here we will discuss how to implement a custom caching solution based on what we learned, demonstrate how to move to a distributed cache, and explore what our customers will see when they start using our new Commerce SDK.

---

The Design of Strongly Consistent Global Secondary Indexes in Apache Phoenix — Part 1

Phoenix is a relational database with a SQL interface that uses HBase as its backing store. This combination allows it to leverage the flexibility and scalability of HBase, which is a distributed key-value store. Phoenix provides additional functionality on top of HBase, including SQL semantics, joins, and secondary indexing.

Secondary indexing, which enables efficient queries on non-primary key fields, is central in many use cases. At Salesforce, we saw this to be the case and recognized that some use cases demand a higher level of data consistency for secondary indexes than what was offered in Phoenix. We set out to redesign global secondary indexes to meet the strong data consistency demand.

---

The mutable tables allow existing rows to be updated many times, and updating an existing data table row may change a secondary key on this row. If this happens, we need to remove the old index row for this secondary key and insert a new index row with the new key. As the following illustration shows, changing the city for Alice from Seattle to Utah requires simply updating the city column value for Alice’s row on the data table however, it requires multi-row updates on the index table.

---