On 2/18, Flux successfully completed an overhaul of our content database structure. This was a large two-month project that consisted of moving our content databases from a distributed architecture, where each database contained only a subset of data based on community ownership, to a new model where all databases contain all data but perform specific functions – either read or write. As a result, you’ll notice that your Flux sites and widgets are responding much faster and you are enjoying a significant reduction in server errors and timeouts. There will also be less maintenance downtime, fewer restrictions on retrieving metadata in lists, and the improvements allow Flux to better improve content-specific platform functionality.

Content Database Restructure Benefits to Flux Sites and Developers:

o   Faster response time for pages and DAAPI.

o   Significant reduction in server errors and time-outs.

o   No longer necessary to stop the production databases and sites to perform weekly database back-up and restore to staging.  

o   Redundancy – since all databases maintain a full copy of content data via replication, if one database has a problem it can be easily taken offline and replaced.

o   Retrieving lists of content metadata.  Previously there were restrictions preventing full metadata being returned when accessing lists of content.  This limitation no longer exists, so all metadata available when requesting a single content item is now also available when requesting lists.

o   A large amount of refactoring of internal code was performed during this phase.  The result is that it is much easier to maintain and enhance content-specific functionality in future.

Questions about the Flux content database restructure? Click here to start a new discussion thread.